[Talk-de] Reit- und Wanderkarte - Fragen

[Frederik Ramm]

Hallo,

Nop wrote:
>> der Relation Analyzer wertet auch nur die Ways in einer Relation aus, 
>> und in meiner Superrelation sind ja (momentan) nur 2 Relationen enthalten:
>> http://www.openstreetmap.org/browse/relation/49759
>> Diese wiederum bestehen dann nur aus Ways.
> 
> Da haben wir schon mal den ersten Nachteil einer solchen Relation. Otto 
> normaluser wird jetzt annehmen, die gibts nicht.

Wenn wir immer nur Sachen einfuehren wuerden, die existierende Software 
bereits kann, waeren wir noch nicht besonders weit. Das ist maximal ein 
Nachteil am Relation Analyzer, kein Nachteil an der Relation.

> Ein Aspekt ist die Gruppierung. Da hab ich ja gar nix dagegen. Aber 
> versetz' Dich mal in die Lage einer Software, die nur die Daten sehen 
> kann. Und stell' Dir mal vor, es gibt mehrere Superrelationen, in denen 
> Deine Etappen drin sind. Wie erkenn' ich jetzt, welche gemeint ist, wenn 
> ich z.B. die ganzen Etappenstrecken aufsummieren will?

Ist das denn wirklich ein so haeufiger Fall?

Ich kann mir ja vorstellen, dass es z.B. in Nordrhein-Westfalen irgendwo 
einen "Rhein-Ruhr-Wanderweg" gibt, den wir als Relation modellieren, und 
dass es ferner einen "Paris-Moskau-Wanderweg" gibt, der diesen Weg als 
eine Etappe enthalten koennte. Das Problem, das Du hier fuerchtest, 
wuerde entstehen, wenn es nun mehrere internationale Wanderwege gaebe, 
die alle den "Rhein-Ruhr-Wanderweg" als eine Etappe enthalten. Und mit 
"internationale Wanderwege" ist ja nicht gemeint, dass es mehrere 
Wandermoeglichkeiten gibt, sondern wirklich benannte, gewartete, 
ausgeschilderte Wege mit einer Organisation dahinter. Ist das wirklich 
ein Fall, der so haeufig auftritt, dass wir unser Modell danach 
ausrichten muessen?

> Ein anderer Aspekt ist die Vererbung. Der ist tückisch,

Nein, der wird nur staendig von Dir als tueckisch dargestellt, weil Du 
dich weigerst, pragmatisch an die Sache ranzugehen. Anstatt eine Loesung 
zu bauen, die in 99% der Faelle das richtige tut und in 1% der Faelle 
Schrott ausgibt, willst Du lieber gar keine Loesung. Mich wundert, wie 
Du es mit der Einstellung ueberhaupt zu einer so guten Wanderkarte 
gebracht hast ;-)

> denn Du kannst 
> beliebig viele Tags von beliebig vielen Relationen auf beliebig 
> unterschiedlichen Wegen erben.

Zunaechst einmal haben wir das bei Ways ja jetzt schon, ohne dass 
irgendjemand jammert: Ein Way kann sowohl zum Wanderweg "gelbes Kreuz" 
als auch zum Wanderweg "roter Kringel" gehoeren. Ob es da Vererbungen 
gibt und welcher Art die sind, entscheidet der Nutzer der Daten, das ist 
im System gar nicht festgelegt. Wenn man wollte, koennte man genau die 
gleichen Vererbungsprobleme, die Du hier konstruierst, auch fuer diesen 
Fall konstruieren.

Ausserdem tritt die von Dir gefuerchtete Verwirrung ja fruehestens dann 
auf, wenn eine Wanderweg-Relation Teil von mehreren unterschiedlichen 
Superrelationen ist, ein Fall, den ich, wie gesagt, fuer sehr selten halte.

Ich schlage vor, Du gehst bis auf weiteres einfach mal davon aus, dass 
eine Routen-Relation Teil von 0 oder 1 Superrelationen ist. Dann loesen 
sich alle Deine Probleme in Luft auf. Und wenn wir dann so Spezialfaelle 
bekommen, in denen das nicht mehr reicht, dann schauen wir, wie wir die 
loesen.

> Und ich spiel halt so lange Advocatus Diaboli, bis auch der Fall n>1 
> durchdacht ist. :-)

Derlei Advokaten haben wir hier im Projekt oefters. Vorangebracht haben 
sie indes wenig.

> Also: Woran soll mein Programm erkennen, welche Superrelation die von 
> Dir gemeinte ist, wenn es deren mehrere gibt?

Nimm die erstbeste.

Wenn Du partout damit nicht zufrieden bist, dann weise Deine 
Wanderrouten-Erfasser an, einen Rueckwaerts-Link von der Sub-Relation zu 
der gewuenschten Super-Relation einzubauen, und verarbeite das Konstrukt 
nur, wenn die Pointer beiderseitig konsistent sind. Zirkulaere 
Referenzen sind erlaubt. Ich vermute zwar, dass es einige Software gibt, 
die dabei maechtig auf die Nase fallen wird, aber dann hast Du 
wenigstens was zu lachen ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"