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

Tim Teulings tim at framstag.com
So Jul 8 19:15:00 UTC 2012


Hallo!

> Ich möchte in dem Zshg. auf [1] verweisen - dato hat fast jede
> Bundesstraße ihre eigene Relation, so auch viele Landes-, bzw.
> Staatsstraßen. Auch innerorts ist OSM mit immerhin rund 12.000
> Relationen vom Typ "street" dabei [2], welche gesplittete Wege gleichen
> Namens explizit in Relation setzen.

ich habe mal versucht, eben über "Autobahn-Relationen" dass Autobahnnetz 
vollständig aufzubauen. Das wäre hilfreich gewesen, um eine optimierte 
(aka punktreduzierte) Variante des Netzes für niedrige Zoomlevel zu 
erzeugen. Das ist kläglich gescheitert. Zum einen, weil die bestehenden 
Export Extrakte mit Relationen nicht pfleglich genug umgehen zum 
anderen(die Strategie wäre da für jeden Relationstyp auch möglicherweise 
eine andere), weil die Relationen einfach nicht vollständig waren. Ein 
Qualitätsproblem, welches dazu führt, dass ich Relationen nun nur noch 
für ein paar wenige Zwecke auswerte - für diesen aber eben nicht. Diese 
Arbeit war für meine Ziele umsonst :-/

> - Robustheit
> - ist ein Faktum sowohl als Relation, als auch über Tags an den
> Primitiven gemappt, steigt z.B. die Anzahl der Methoden, die QM-Tools
> verwenden können, um Plausibilität und Konsistenz der Daten zu prüfen
> - am Beispiel der Bundesstraßen wäre z.B. denkbar, dass man das Ergebnis
> einer errechneten Relation (alle ways mit ref=B x) mit gemappten
> Relationen vergleicht, zusätzlich zu den gängigen Tests auf Lücken für
> Route-Relationen
> - im Bezug auf das Tagging entsteht eine Robustheit dadurch, dass es
> unwahrscheinlich ist, dass ein Mapper sowohl auf dem way als auch in der
> Relation versehentlich das gleiche ändert/löscht

Für eine Softwarenutzung irrelevant. Automatisches Auflösen von 
Widersprüchen ist sehr aufwändig und eine Entscheidung hat eine 
offensichtliche 50/50 Chance. Da schenke ich mir die Relation gleich, 
wenn möglich.

> - Wartbarkeit / Datenmanagement
> - existieren sowohl Relation als auch Primitiven, kann der Mapper
> Information gewichten, d.h. bestimmte Informationen redundant halten,
> andere nicht
> - bsp.-weise könnte man sich der Übersichtlichkeit wegen entscheiden,
> auf den Primitiven nur die nötigste Information zu taggen (ref/name),
> während die Relation Zusatzinformation hält (tmc, name:de, name:en,
> name:xyz, ..)
> - damit bleiben die einfacheren und vermutlich häufigeren
> Anwendungsfälle auch ohne Relation-Lookup lösbar

Das Verteilen von Daten zu einem Objekt über mehrere andere Objekte 
macht es Software sehr viel schwieriger diese Daten zusammenzuführen. Es 
sind viel mehr Daten gleichzeitig "in der Luft zu halten". Das bedeutet, 
geringere Performance, mehr Hauptspeicherbedarf. Widersprüche (s.o.) 
können auftreten. Software hätte gerne Datenlokalität. Es gibt schön 
Gründe warum Datenbanken normalisiert sein sollen.

> - Zugänglichkeit
> - Verschiedene Leute verwenden verschiedene Mapping-Methoden. Während
> die strukturierteren Leute sich evtl. gezielt mit einem bestimmten Thema
> beschäftigen (sei es Bundesstraßen, Wasserläufe, Geschäfte, etc.) und es
> demnach begrüßen, wenn sie, statt einem Gebiet, gleich über eine
> Relation die jeweils zu bearbeitenden Daten selektiv in ihren Editor
> ziehen können, um den aktuellen Stand zu prüfen, interessiert diese Art
> des Zugangs den Pionier im relativ datenlosen Gebiet kaum.

Verschiedene Zugänge zu Daten ist für Software OK, da man flexibler 
gegenüber mehreren Lösungsansätzen ist. Dafür muss aber alle Zugänge zu 
allen Daten führen. Das ist bei OSM eher nicht der Fall.

Obige Aspekte spiegeln die Sicht eines Mapper wieder. Die Punkte sind 
aus seiner Sicht nicht falsch. Die Sicht des Mappers ist aber nur eine 
Sicht, die Sicht einer Software und deren Entwickler ist eine andere. Es 
gelten andere Kriterien,die teilweise im Widerspruch zu den Kriterien 
des Mappers sind. Will man nicht nur an der Bearbeitungs-"Useability" 
des Mappers arbeiten sondern auch an der Qualität des 
Software-erstellten Ergebnisses, sind diese Kriterien mehr in Einklang 
zu bringen. Zu viel "Mach es wie du willst" macht es der Software 
schwer, zu viel "Genau nach Schema und mit klarer Definition und nicht 
anders" sorgt dafür, dass die Mapper wegrennen. Haben beide Seiten mehr 
Fingerspitzengefühl und Verständnis für die Bedürfnisse des anderen, 
kann was Tolles daraus werden :-)

-- 
Gruß...
    Tim




Mehr Informationen über die Mailingliste Talk-de