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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
