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