[Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Christian Müller cmue81 at gmx.de
Mo Jul 9 21:51:13 UTC 2012


Am 09.07.2012 21:47, schrieb Frederik Ramm:
> Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
> nicht.

Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
Elementen nur noch in der Relation auftauchen.

Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
verbundene Nodes, versehentlich verschobene, etc.

Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
Überlegung "falsch" mappt, wird denjenigen die Lust am Mappen verderben.

Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
der gleiche geografische Sachverhalt eben vielfältig modelliert werden
kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
gesucht, wie es Knoten und Weg nunmal sind?

Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
nur nicht vom Menschen.

Wenn wir schon so radikal sein wollen und so einen tollen Leitspruch wie
"vermeide Relationen" gebären wollen, warum dann nicht gleich auch auf
die Struktur "way" verzichten.  Eigentlich reicht es doch, wenn wir
alles auf dem Node taggen.  Mapper machen nur Fehler, wenn sie sich mit
der Komplexität eines way's auseinandersetzen sollen.  (..)



Weiterhin spielt die Arbeitsweise beim Mappen in diese Problematik.  Ich
würde weder diejenigen verprellen, die strukturiert arbeiten und sagen:
"Ich lege mir Bundesstraßenrelationen an, weil mir dann die Pflege
dieses Netzes einfacher fällt.", noch diejenigen, die in einem weißen
Gebiet unstrukturiert alles mögliche anlegen und von Relationen gar
nichts wissen und sie aufgrund des Datenstandes evtl. gar nicht brauchen.

Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
die Argumente derjenigen aufgreifen, die meinen

    "man könne den Verlauf der Bundesstraße auch programmatisch anhand
des ref= zusammenbauen und braucht die Relation gar nicht"

und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
kann:

    - versehentlich Relation beschädigen
    - versehentlich ref löschen

Es ist unwahrscheinlich, das beides zeitgleich passiert.  Gäbe es
hingegen eine explizite Relation nicht, würde ein Fehler durch ein
fehlendes "ref" Tag am way nicht auffallen - allein auf die Heuristik
"alle Wege, die sich einen Knoten teilen" zu bauen, ist weltfremd und
idealisiert imho viel zu stark.  Hier wünscht sich der Informatiker die
Welt herbei, wie sie sein sollte.  Beispielsweise ist der Verlauf von
Landesstraßen heute vielfach in Teilabschnitten durch Bundesstraßen
ersetzt worden und dadurch fragmentiert.  Weiterhin sehe ich nicht ein,
weshalb, nur weil es für Routing und Rendering abkömmlich ist, auf den
exotischeren Anwendungsfall "wieviele Goethestraßen gibt es in X"
verzichtet werden sollte, wenn er mit etwas Grips und gutem Willen in
der DB ohne viel Zauber und Zusatzarbeit modellierbar ist.  Die Fragen,
die sich hier viele stellen, ist doch eher, wieviel Relation ist gut? 
Wie kann vermieden werden, dass die Nutzung von Relationen, die spatiale
Verwendbarkeit einer Auswertung auf einfacheren Ebenen wie Punkt / Weg
schadet?


Gruß
Christian






Mehr Informationen über die Mailingliste Talk-de