Ich findes es einfach nur recht Unglücklich das Tags aufgrund der RIchtung des Weges eine Bedeutung haben.
Klar hatten wir soetwas in der Vergangenheit auch und es funktioniert auch… siehe die Oneways.
Ich mag aber auuch an die Zeiten erinnern als Flächen noch im Uhrzeigersinn ausgerichtet seinen mussten damit sie angezeigt werden.
Bisher sind wir auch weitesgehend ohne Richtungsbasierte Tags ausgekommen. Wenn wir die Benutzung von diesen Massiv ausweiten wollen dann sollte das Konzept stimmig sein. Und schlussendlich sollte es auch eine Gewisse Einsteigerfreundlichkeit bleiben…
Betrachten wir mal eine Sinple Bundestraße aus den Augen eines Einsteiger:
Die besteht aus namen,ref,highway und villeicht noch maxspeed. Das ist für jemaden der grade frisch eingestiegen ist sehr gut zu verstehen und er kann das einordnen. Je komplizierter wir es ihm machen sei es durch relationen oder tags desto schwieriger wird er es haben.
Nach meinen Glauben (und ich habe nicht die weisheit mit dem löffel gefressen) ist es für jemanden deutlich leichter 3-4 Relationen zu ignorieren wenn er seine oben angeführten Basistags wiederfindet. Dann kann er sich sagen so den Schmarn mit den Relationen versteh ich nicht aber immerhin weis ich warum die Straße auf der Karte diesen namen trägt und so angezeigt wird.
Ich persönlich sehe das deutlich schwieriger von den Einsteiger zu durchschauen wenn seine “Basistags” in einer Wolke von Tags verschwunden ist und er sich diese erst raussuchen muss. Bestes beispiel sind dafür die place tags. Da wird auf der Karte ein name angezeigt und hinter der node stehen 15 verschiedene Tags. Klar die werden alle benötigt und sind sinnvoll … schrecken aber in meinen augen auch erstmal ab…
Der EDITOR müßte beim Drehen von Wegen die Tags einfach mitdrehen (also left zu right für Fußwege, forward vs. backward und was es sonst so gibt). Dann passiert da nichts mehr, auch wenn man mal nicht aufpaßt.
Dennoch finde ich beide Wege: Relationen oder forward/backward nicht wirklich gelungen und beide haben - wie schon erwähnt - bei der Bearbeitung große Probleme.
Eine Lösungsidee ist mir aber in den Kopf gekommen:
Trennung von Ways und speziellen Eigenschaften/ Zuordnungen mit sogenannten Layers.
So stelle ich mir das vor (klar es ist nicht schnell umsetzbar, aber dennoch eine “Vision”):
Straßennetz (physische Wege) werden angelegt
zu dieser Basisebene gehören dann Eigenschaften wie die Bodenbeschaffenheit oder andere physische Eigenschaften
in einer weiteren Ebene kann man dann Städte einzeichnen
in weiteren: Postleitzahlen, Stadtteile, Stadtgebiete (Wohngebiet, Geschäftsgebiert, Industriegebiet…)
darauf baut ein zusätzliche Layer auf: z.B. Layer: Straßenverkehrsordnung
dieser enthält dann die Beschreibung von Maxspeed-Angaben, Vorfahrtsregeln, Straßenschilder, Angaben wie: Maximale Höhe, Breite, Gewicht, Straßenname (denn ein Straßenname kann sich während eines physikalischen zusammenhängenden Weges ändern) …
weiter wird in dieser Ebene ggf. mehrere Tracks (2 getrennte Spuren, ggf. seperate Fuß- und Radwege) zusammengefasst
In Editoren könnte ich mir das so vorstellen:
Man wählt die Ebenen aus, die man bearbeiten möchte.
zuerst legt man die Wege an
ein anderer kann dann die Straßen-Ebene vornehmen und dort die Verkehrsregeln und Schilder eintragen
wobei alle Änderungen vom Editor relativ von der Basisebene (relativ zu den Nodes) gespeichert werden
wird in der Basisebene ein Node verschoben, bleibt dennoch der Maxspeed-Abschnitt konstant
Solch ein Modell spiegelt meiner Meinung nach die Wirklichkeit besser wieder. Denn man unterscheidet zwischen den verschiedenen Ebenen, die oft auch gar nichts miteinander zu tuen haben (z.B: PLZ mit Landschaft).
Weitere Vorteile dieses Konzepts:
einfach in der Bearbeitung → verschiedene unabhängige Ebenen
übersichtlicher und intuitiver zu bedienen (es sind keine 20 Tags auf ein Track und der Track wird nicht von 2-5 Relationen umfasst)
im Editor wird nur das für mich Wesentliche angezeigt → auch weniger Ladezeit, Traffic
Ich bin mir bewusst, dass das nicht so einfach umzustellen ist, aber ich denke, dass OSM vielleicht irgendwann darauf hinauslaufen wird, weil es sonst einfach viel zu Komplex wird.
In manchen Städten stürzt mein Browser fast ab, weil bei geringeren Zoomstufen so viele Elemente existieren.
jOSM fragt ja beim drehen nach, ob die Tags gedreht werden sollen. Ein Automatismus ist nicht gut, da nicht bei jedem Drehvorgang mit richtungsabhängigen Tags ein wechsel gewünscht ist.