Dieses Posting befasst sich mit der Frage, ob die Eigenschaften von Straßen besser durch Relationen als durch Tags erfasst werden könnten.
Bestandsaufnahme: Die Darstellung von Straßen in OSM geschieht momentan derart, dass ein Straßenabschnitt als Way erfasst wird. Manche Eigenschaften werden dabei durch Tags, andere durch Relationen beschrieben. Dabei sind die durch Tags beschriebenen Eigenschaften im Editor schon dann sichtbar, wenn man eine Straße anklickt. Bei den durch Relationen beschriebenen Eigenschaften ist dies erst über Umwege möglich. Daher werden die Relationseigenschaften von vielen Usern nicht wahrgenommen. Um die Eigenschaften Teilwegen zuzuordnen, ist derzeit eine Teilung der Wege erforderlich. Diese Notwendigkeit ist unabhängig davon, ob eine Eigenschaft durch Tag oder Relation dargestellt wird. Dies kann beispielsweise durch Maxspeed-Abschnitte, eine Brücke oder die Endhaltestelle einer Buslinie begründet sein. Insbesondere die Teilung wegen nicht offensichtlichen Relationen führt dazu, dass solche Teilungen von anderen Usern wieder gelöscht werden und die Relationen somit immer wieder zerstören. Unterbrochene oder plötzlich endende Radrouten - insbesondere deren Teile in weniger beobachteten ländlichen Gebieten - sprechen da Bände. Selbst für den Vor-Ort Wohnenden ist das Reparieren schlecht möglich, da er die Quelle der Radroute der original-editierenden Person nicht kennt. Ein anderes Beispiel: ÖPNV-Relationen werden durch die Umkehr einer Straßenrichtung zerstört. Weitere Begehrlichkeiten, wie das Darstellen der für die Routenplanung unumgänglichen durchgezogenen Mittellinie, welche gleichzeitig eine Wende- und Linksabbiegeverbot implizieren würde, ist derzeit nur aufwendig und realitätsfern möglich. Derzeit versucht man, die Funktionalität der durchgezogenen Mittellinie durch autobahnähnliche Trennung der Richtungsfahrbahnen oder durch Wendeverbot + Abbiegebeschränkung darzustellen, was beides eine sehr unbefriedigende und realitätsferne Lösung darstellt. Das Problem der Relationen ist es aber, dass sie beim derzeitigen Zustand von OSM nur schlecht sichtbar sind und vor allem Anfängern Probleme bereiten. Im Bereich des ÖPNV-Erfassung gibt es massive Probleme, die nur durch aufwendige Relationskonstruktionen, wie das Oxomoa-Konzept realisiert werden können, das aber wegen seiner Komplexität auf Ablehnung bei vielen User stößt, sofern man es überhaupt versteht. Entsprechend durchwachsen ist derzeit die Erfassung des ÖPNV, welche derzeit vollkommen uneinheitlich geschieht. Die Verwirrung neuer User ist groß. Nirgendwo können sie sich wirklich orientieren, da die Aussagen gegensätzlich sind. Zusammenfassung der Probleme: 1) Wie kann die versehentliche Zerstörung von Relationen verhindert werden? 2) Wie kann die Zerstückelung der Wege verhindert werden, die aufgrund der Beschreibung durch Tags bzw. Relationen notwendig ist? 3) Wie lässt sich die Erfassung der Eigenschaften teilweise durch Tags, teilweise durch Relationen vereinheitlichen? 4) Wie können dringend benötigte Eigenschaften für die korrekte Routenplanung in OSM gemappt und dargestellt werden? 5) Wie kann realitätsnäher gemappt werden und Ersatzmapping verhindert werden? 6) Wie wird Mapping und Darstellung auch schwieriger Zusammenhänge übersichtlicher, so dass sich hier zukünftig einheitliche Mappingkonzepte implizieren? 7) Lassen sich alle vorbeschriebenen Anforderungen mit einer einzigen Maßnahme erschlagen? Lösungsversuch: Ich nenne diesen Lösungsversuch "Eigenschaftskonzept". Er soll versuchen, möglichst alle oben aufgeführten Fragen mit einem Schlag und dabei mit einem möglichst einfachen Konzept zu bewältigen: Man mappt die Straßen zunächst einmal als Grundgerüst. Jede Straße verläuft grundsätzlich ungeteilt zwischen den zwei nächsten Abzweigungen (bzw Kreuzungen). Eine Teilung der Straße ist also nur noch möglich, wenn eine neue Abzweigung eingefügt wird. Ansonsten ist eine Straße unteilbar. Die Straßen erhalten grundsätzlich keine Tags. Statt mit Tags werden die "Eigenschaften" grundsätzlich nur noch per Relation entlang eines Weges von "hier bis dort" zugeordnet: Von hier bis dort heißt die Straße XY-Straße. Von hier bis dort ist die Straße primary. Von hier bis dort befindet sich eine Brücke. Von hier bis dort ist die Straße Einbahnstraße. Von hier bis dort befindet sich eine durchgezogene Mittellinie. Von hier bis dort fährt die Buslinie XY. Von hier bis dort (und dort) befindet sich eine Abbiegebeschränkung. Jede Eigenschaftsrelation hat eine Richtung. All dies setzt allerdings voraus, dass die Editoren die Eigenschaftsrelationen genau so einfach sichtbar machen, wie bisher die Tags. Statt der Tags werden also bei Klick auf eine Straße alle Eigenschaftsrelationen angezeigt. Der Editor stellt das von "hier bis dort" in der Karte grafisch dar, wenn eine Eigenschaft angeklickt wird. Noch besser: Alle den geklickten Straßenabschnitt betreffenden Relationen werden farblich unterschiedlich angezeigt. Alles wird übersichtlicher und neue, bisher nur schwierig zu implementierende Straßeneigenschaften werden jetzt einer praktikablen Lösung zugeführt. Das Basteln an einer Eigenschaft zerstört keine andere, da sie jetzt unabhängig voneinander sind. Dadurch werden insbesondere schwierig zu recherchierende und reparierende Eigenschaften wie Zugehörigkeit zu Rad- oder ÖPNV-Routen bzw deren Richtung jetzt besser geschützt. Zudem können Relationen im Wesentlichen nicht mehr durch Teilung oder Zusammenfügen des zugrunde liegenden Straßengerüstes zerstört werden. Im Gegensatz zum früheren Modell braucht der Editor jetzt nur noch beim Einfügen oder Entfernen einer Abzweigung darauf achten, dass alle Eigenschaften an der Nahtstelle inklusive Richtung richtig angepasst werden. Die Zerstückelung und Teilung von Straßen wegen der Tags bzw Relationen wird nun vermieden. Relationen lassen wegen der "längeren" Basiswege schneller, einfacher und übersichtlicher zusammenklicken. Gerade kurze Abschnitte, wie beispielsweise Brücken, werden dort leicht vergessen. Lediglich an den Endpunkten der Relation oder beispielsweise bei Bushaltestellen ist wegen der genauen Lokalisierung ein Umschalten auf "Micro"-Erfassung notwendig. Ein neu eingefügter "Micro"-Punkt der Eigenschaftsrelation wird automatisch in den Way und alle anderen Relationen übernommen, selbst wenn dieser von der Relation ausgeschlossen bleibt. Die Eigenschaftsrelation nimmt normalerweise alle Linien als auch Punkte entlang eines Weges auf, um explizit punktförmige Ausschlüsse z.B. an Abzweigungen (oder Kreuzungen) deutlich zu machen. An Kreuzungen kann der punktförmige Ausschluss der Eigenschaft im Renderer durch Unterbrechung ihrer Darstellung im Kreuzungsbereich (Löschen, wo eine andere Straße überlappt) kenntlich gemacht werden. Letztendlich könnte man den Begriff "Eigenschaftsrelation" in OSM durch den suggestiven Begriff "Eigenschaften" verdrängen und der Relation somit den Schrecken insbesondere für Otto Normalmapper nehmen. So würden die bisher teilweise als Tags und teilweise als Relation beschriebenen Eigenschaften einheitlich unter dem Begriff "Eigenschaften" zusammengeführt. Die einheitliche Behandlung fördert zudem die Übersichtlichkeit auch bei ambitionierten Mappern. Ferner wird die Konformität zur Realität besser, da die Dinge nicht mehr über Umwege gemappt werden müssen, sondern näher an der Realität. Ein gutes Beispiel für realitätskonformes Mapping wäre die durchgezogene Mittellinie. Diese lässt sich zudem im Renderer einfach und realitätskonform anzeigen. Sie ist ebenfalls Beispiel für eine unungängliche Eigenschaft bei der korrekten Routenplanung, die mit den bisherigen Mitteln nur aufwendig und undurchsichtig zu implementieren war. Ich hoffe auf möglichst viele Pro- und Contra- Aspekte. Dabei sollte unterschieden werden zwischen: 1) Funktioniert das Eigenschaftskonzept grundsätzlich? 2) Benutzerfreundlichkeit 3) Probleme bei der notwendigen Software z.B. Editoren 4) Probleme bei der Datenbank 5) Probleme bei der Umstellung auf das neue Modell Denn wenn schon genügend Contra-Aspekte für 1) und 2) zusammenkämen, braucht man über 3), 4) und 5) überhaupt nicht mehr nachzudenken. Insofern wäre primär erst einmal eine Abklärung von 1) und 2) sinnvoll. _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
