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

Di Jul 10 13:44:12 UTC 2012

Hi,

Am 10.07.2012 08:33, schrieb Sarah Hoffmann:
> Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
> ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
> Multipolygon) nachweinen würden?

Es ist deine Ansicht, dass dies die drei einzigen sind, die wirklich 
gebraucht werden.  Du kennst das Wiki, Leute haben sich über Jahre 
Gedanken darüber gemacht, wo deren Meinnung nach Relationen sinnvoll 
sind.  Ich denke nicht, dass Du intensiv genug geforscht hast, um deren 
Arbeit mit ein bisschen m.E. zu entkräften.  Ich persönlich habe in 
letzter Zeit waterway, bridge, site Relationen genutzt.

Speziell bei den waterways erhältst Du z.B. keinen eindeutigen Strang 
von Quelle zur Mündung.  Auch eine Relation garantiert da nichts, aber 
wenn ich mir vorstelle, dass ich mir einen Hauptflusslauf erstmal Weg 
für Weg über Overpass oder einer lokalen DB ziehen müsste, mit einem gut 
möglichen overhead von 2/3 falschen Positiven, kommt mir das Grauen.  
Z.B. gibt es viele gleich benannte Nebenarme, Fahrrinnen, Schleusenarme, 
etc. - ich verlasse mich auch nicht auf die Relation allein, verwende 
sie aber als Ausgangspunkt.  Weiterhin siehst Du z.B. am Rhein-Delta, 
dass ein Tag-Matching+Node-Verbindung nutzender Algorithmus versagen 
wird, denn in den Niederlanden heißt der Rhein schonmal Rijn und fließt 
über Waal, Lek, etc. ab.  Das sind nur ein paar der Spezialitäten, die 
mir hier anwendungsspezifisch einfallen, es gibt sicher 'zig andere, 
aber nicht jeder hat die Zeit und die Muße auf dieser Liste gegen den 
Minimalismus anzukämpfen.

> Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
> Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
> immernoch der häufiger gebrauchte ist.

Ja, aber er ist die klar schlechtere Approximation gegen eine 
gewissenhaft gepflegte Relation.  Im Prinzip sollte das Fallback-Methode 
sein.  Ich stimme zu, dass es für viele Relationstypen Nachholbedarf bei 
der Spezifikation gibt, um etwa einen ähnlich guten Dokumentationsgrad, 
wie bei den MPs zu erreichen.

> Relationen sind wesentlich leichter versehnlich kaputt zu machen als 
> Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern 
> und man nicht sofort sieht, dass man da etwas ändert. 

Mit der von Dir erstellten Cycling-Map (Kompliment übrigens) weißt Du 
doch, wie man sie sichtbar macht.  Ich finde nicht, dass die 
"Unsichtbarkeit" ein Argument gegen Relationen ist und finde umgekehrt, 
dass z.B. auch nicht verbundene Nodes wenn sie Nahe beieinander oder 
aufeinander liegen, schwer identifizierbar sind.  Zudem werden die 
Routen auch in Editoren visualisiert, das kam auch nicht über Nacht.  
Visualisierungen für andere Relationen werden auch kommen, je nach Bedarf.

> Wenn du dir zuviel dieser "Freiheiten" herausnimmst, schränkst du 
> gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen 
> sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht 
> darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach 
> wie möglich zu halten, damit es für alle verständlich bleibt. 
> Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
> Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
> in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
> ein bisschen lästig, aber normalerweise kann man die Tags einfach 
> ignorieren, frei nach dem Motto 'leben und leben lassen'. 

Das ist total subjektiv.  Verlege ich den Weg mit 15 kryptischen Tags, 
ohne mir deren Inhalt anzuschauen, entstehen Fehler in evtl. größerem 
Maße, als wenn jemand Relationen bricht, die ein anderer nachpflegt.  
Natürlich bedeutet das alles Aufwand, der vergrößert sich aber ohne 
Relationen nur.  Ich bin der Auffassung, dass in Gebieten mir hoher 
Datendichte und evtl. auch vielen Relationen es unabdingbar ist, dass 
sich ein Mapper Gedanken macht, /was/ er /wie/ ändert.  Ob er da, für 
den Fall er macht sich keine Kopf, 15 Relationen bricht oder 15 
kryptische Tags dorthin verlängert, wohin sie nicht gehören, spielt eine 
untergeordnete Rolle.  Es geht immer zu Lasten derer, die gewissenhaft 
arbeiten.  So ist das nunmal - wie sagtest Du:  das ist kein technisches 
Problem, sondern ein menschliches..

>> 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?
> Geografische Sachverhalte sollte man über Geometrie ausdrücken und
> nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
> wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
> sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
> Sinn? Diese Information ist bereits in der DB, das heisst die Relation
> bringt absolut nichts.

Siehe unten, Beispiel "Liste aller Brücken über die Elbe".  Ich stimme 
Dir zu, dass es Grenzen geben muss, aber das sind 
Einzelfall-Entscheidungen.  In Einzelfällen können Redundanzen durchaus 
nützlich sein, da sind Vor- und Nachteil zu gewichten, Aufwand 
abzuschätzen, Alternativen zu bewerten.  Ob das nun dem einfacheren 
Datenbezug dient, oder um die Küstenlinie von Russland zu prüfen.

Für dein fiktives Beispiel der geografischen Lage von Bushaltestellen 
stimme ich Dir zu - es ist aber eben nicht immer so einfach.  Und 
manchmal skaliert es auch schlecht - warum sollten diejenigen mit viel 
Rechenpower bevorzugt werden?

nur nicht vom Menschen.

> Jetzt wirfst du irgendwelche technischen Begriffe in den Raum ohne
> dir wirklich mal einen Kopf gemacht zu haben, wie das ganze eigentlich
> funktioniert.

Roland führte LUT an, um zu zeigen, dass der Fall wiederholender Tags 
auf Wegen unkritisch ist, weil er in der Masse der existierenden 
Software druchoptimiert wird.  Soweit mir bekannt ist, existiert dafür 
aber eben weder ein einheitliches Package, noch eine API, noch gute 
Dokumentation, noch irgendein Standard, so dass man das im eigenen 
Projekt mal eben so verbauen könnte.  Schau Dir Relationen an:  sie sind 
gut dokumentiert, sie sind Teil der API, ergo finden sie ihre 
Verbreitung auch dorthin, wo sie der Informatiker und 
redundanzablehnende Mensch ablehnt.  Es ist auch eine Frage der 
Verfügbarkeit und Verständlichkeit.  Das Konzept der Relationen ist 
nicht so schwer zu verstehen, wie es auf dieser Liste überwiegend 
dargestellt wird.

>   Redundanz in den Tags ist bisher einfach kein grosses Problem
> gewesen. Die Art und Weise wie Datenbanken das handhaben, ist effizient
> genug. Wir haben ganz andere Ecken, wo wir ernsthafte Probleme mit der
> Effizienz bekommen. In erster Linie bei der Berechnung der Weggeometrien
> und dem Node-Lookup.

Wird auf Relationen verzichtet, entstehen mehr nodes und noch mehr 
ways.  Das ist also eher ein Argument für Relationen, weil Weggeometrien 
je nach Bezug durch Relationen "recyclet" werden.

>> 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
> Du argumentierst hier gerade gleichzeitig, dass wir Relationen brauchen,
> um Redundanz zu vermeiden und um Redundanz zu haben. Was nun?

Ich schließe mich deiner Analyse meiner Argumentation an, denke aber 
nicht, dass das ein Fall ist, der eine Entscheidung für/wider braucht.  
Ja, wir brauchen Relationen um (übermäßige) Redundanz zu vermeiden.  Ja, 
wir können die Redundanz, die durch Überschneidung mancher Tagwerte, die 
sowohl auf dem Weg, als auch in der Relation gesetzt werden, z.B. für QA 
nutzen.

> Beides simple Abfrage und das kleinste Problem für dein QA-Tool. Nutzen der Relation: null.

Hier kann ich Dir nicht folgen.  Die Mengen r=(alle member der Relation 
xx) und w=(alle ways mit ref=xx) sollten in einem bestimmten Verhältnis 
stehen.  Mindestens sollte w Untermenge von r sein, es muss aber nicht 
in jedem Fall eine echte sein (je nachdem, ob z.B. eine Landstraße, 
deren Verlauf streckenweise durch Bundesstraßen ersetzt wurde, auf den 
Bundesstraßen mit im ref= erscheint, oder nicht).

> Der einzige Grund, Bundesstrassen in eine Relation zu stecken wäre,
> dass es Wege gibt über die mehrere Bundesstrassen gleichzeitig
> verlaufen. Dann müsste man bei Tags auf unschöne Listen zurückgreifen.
> Soetwas hat es in der Schweiz und den USA, aber in Dt. gibt es das, soweit
> ich weiss, nicht.

Das gibt es auch in Deutschland.  Das ist nach meiner Auffassung aber 
noch nicht einmal der Hauptgrund, weshalb B's als Relation angelegt 
werden/wurden (schließlich ließe sich das ja auch mit mehreren Werten im 
ref-Tag modellieren).

> Weil er mit noch viel weniger Zauber und Zusatzarbeit aus der DB zu
> holen ist. Nehmen wir mal eine osm2pgsql-DB. Dann würde das etwa so
> aussehen:
>
> SELECT ST_NumGeometries(ST_LineMerge(w.way))
> 	FROM planet_osm_way w, planet_osm_polygon p
>   WHERE p.name = 'Deutschland' AND w.name = 'Goethestrasse'
>     AND w.highway is not null
> 	 AND ST_Within(w.way, p.way);
>
> Das war ein 5-Zeiler, den ich in drei Minuten zusammengeschrieben
> habe und der dir eine recht gute Approximation deiner Anfrage geben
> sollte. Ein Stündchen mehr Arbeit und man kann auch noch eine Reihe
> Spezialfälle abdecken. Warum also sollte man hunderte Mapper sinnlos
> Zeit mit Relationen verschwenden lassen, wenn man die gleiche Info
> mit ein bisschen Warten aus der DB bekommt?

Das habe ich schon geschrieben - Stichwort QM-Tools.  Du hast als 
Informatikerin das "kleine Welt"-Problem.  Du denkst Dir diesen 5-Zeiler 
aus und glaubst/hoffst, dass das "eine recht gute Approximation" ist.  
Beweisen kannst Du es nicht, weil Du gar keinen Überblick über alle 
möglichen Fälle der Realität hast und Dir eigentlich auch nur mit Tools 
einen Überblick über die Daten in der DB verschaffst, die wiederum eine 
ganze Menge an Spezialfällen wegabstrahieren.

Du hast einen Vorteil, wenn "hunderte Mapper" Zeit damit verschwenden, 
die Realität im kleinen auf robuste/redundante Weise zu modellieren, 
weil Du mit diesem Plus an Daten (etwas besser) prüfen kannst, ob deine 
Approximationen überhaupt brauchbar sind.

Wie stw schon anführte, ist diese Approximation mehr als schlecht, weil 
viele ways in der DB schon gesplittet sind, nicht immer einen node 
teilen müssen, je nach Straßenausbau oder Luftbildverfügbarkeit 
getrennte Fahrbahnen und teilweise -spuren gemappt sind, etc. pp. (das 
ist aktueller Stand, keine Befürchtung).  Von Jochen wurde weiterhin 
angeführt, dass zur Not die geografische Nähe genutzt werden könne - ein 
Beispiel, das die Grenzen dieses Ansatzes klar aufzeigt, sind die 
Relationen, die Powermapper bilden, um Brücken zu modellieren.  Die 
Realität hält eine Vielzahl von Varianten vor, die einen Mix zwischen 
diesen beiden Extrema bilden:

     - vollständig getrennte, aber räumlich eng aneinandergrenzende, 
physische Strukturen
     - eine physische Struktur, die alle multimodalen Transportwege trägt

Das ist nur ein Beispiel, das mir adhoc einfällt, anhand welchem eine 
Heuristik versagt, zu entscheiden, wie einfache Wege gruppiert werden 
müssen, um eine bestimmte Fragestellung (hier: welche Wege gehören zu 
einer Brücke / which ways make up one bridge) richtig zu beantworten.  
Weitere sind konstruierbar.

Vielleicht passt die Scheuklappen-Metapher am besten, um zu 
verdeutlichen, dass "vermeide Relationen" kein brauchbarer Weg ist, wenn 
OSM eine detailgetreue Sicht auf den Planten sein will und bleiben 
möchte.  Indem wir nur in den Tunnel schauen, erhalten wir zwar einen 
guten Überblick darüber, was im Tunnel liegt und haben ein gutes Gefühl, 
was die Datenlage betrifft, hören aber auf, uns Gedanken darüber zu 
machen, was rechts und links davon liegt - im Fall der Relationen: 
welche Bezüge Mensch zwischen geografischen Objekten herstellt.

Ich stimme zu, dass es Grenzen geben muss, bin aber wie stw der Meinung, 
dass das fallbasiert entschieden werden sollte.  Für mich persönlich 
sehe ich z.B. keinen Sinn darin, eine Wikipedia-ähnliche "Liste der 
Brücken über die Elbe" als Relation in OSM zu pflegen.  Dennoch, es ist 
ohne eine solche Relation (momentan) mitnichten wirklich einfach

     - mit seinem Lieblingseditor effizient alle Brücken entlang der 
Elbe zu laden
             - du meintest es sei kein Argument für eine Relation, weil 
dann Mapper X effizient Zugriff darauf hat
             -> dieses Mittel wird beobachtbar genutzt, weil es 
funktioniert und weil Alternativen fehlen
             -> die Bundesstraßenrelationen sind ein gutes Beispiel dafür
             -> Abhilfe kann hier eine stärkere Integration von 
Overpass-Abfragen in die Editoren bringen, das gibt es aber noch nicht

     - eine einfache, in drei Minuten geschriebene Anfrage z.B. für die 
Overpass API zu erstellen, die diese Brücken zurückgibt
             -> imho ist das Konzept der Relationen für die meisten 
Menschen einfacher zu verstehen, als Overpass

     - zu zählen, wieviele Brücken über die Elbe führen - dazu
             - müssten alle gemappt sein
             - alle korrekt getaggt sein (bridge=..)
             - multimodale, evtl. richtungsseparierte Wege der gleichen 
phys. Struktur in bridge-Relationen zusammengefasst sein

Sicher sind diese Aufgaben mit etwas SQL und einer spatialen DB zu 
lösen, für den, der sich auskennt auch in weniger als einer Stunde.  OSM 
ist aber ein Massenprojekt.  Wer tatsächlich daran interessiert ist, die 
Nutzung von Relationen einzudämmen, der sollte sich Gedanken machen, wie 
die Dinge, zu deren Lösung sie momentan herangezogen werden (und dazu 
gehört offenbar eben auch die Verwaltbarkeit von OSM-Objekten in Projekt 
xyz), alternativ und ohne Mehraufwand gelöst werden können - die 
angesprochene stärkere Integration von Overpass in Editoren wäre da ein 
Anfang.

Momentan dürfte die Masse der Mappenden ein Problem damit haben, wenn 
sie sich ihre zu editierenden Daten vorher über eine Overpass-Query 
zusammensuchen oder, noch besser, ein paar Zeilen SQL schreiben soll, um 
einfach einen Wasserlauf oder den Verlauf einer Bundesstraße zu 
erhalten.  Da fällt es dann eben doch leichter, das über eine Relation 
zu organisieren, auch wenn sie theoretisch überflüssig ist und durch den 
DB'ler nicht genutzt wird, weil er sie sich selbst über das 
entsprechende Statement zusammensetzt.

Wie gesagt, ich betrachte das eher als Chance für robustere Daten statt 
als Übel.  Wenn die Relation, die mir ein spatiales DBMS mit 
entsprechendem Statement generiert dem gleicht, was Mapper angelegt 
haben, hätte ich höheres Vertrauen in die Daten, als ohne diesen 
Vergleich, aber nat. bleibt auch das nicht frei von Fehlerquellen.

Gruß
Christian