Eine berechtigte Frage.
Ich kenne mich vor Ort nicht aus, aber ich würde an der Stelle denken, das ich in den Ort hineinfahre, eben weil auch das linke Schild das aussagt.
Man fährt von Schulenburg nach Engelbostel rein. Zwei aneinander grenzende geschlossene Ortschaften. Daher auch meine fixe Idee mit direction=both. Dann weiß man, dass auf beiden Seiten des Schildes maxspeed=50 gilt im Unterschied zu einem klassischen Zeichen 310.
Hier die andere Fahrtrichtung: https://www.mapillary.com/app/?pKey=kD4lpb3ItnYqnGVb03OSrA&focus=photo&lat=52.44243690120118&lng=9.66984048638642&z=17
in dem Beispiel war ein Ortsschild am Übergang von 2 Ortschaften, direction=both heißt, dass dort in beide Richtungen des Nodes (sic!) Ortschaften beginnen. Wenn irgendwo auf der Welt an einem Schild 3 Ortschaften zusammentreffen wird es komplizierter und das Schema versagt 
Die Schilder auf den Weg zu setzen hat den Vorteil, dass sie vom Router erkannt werden und in der Wegbeschreibung ausgegeben werden können. Ist sicher nicht so wichtig wie z. B. bei Stopp-Schildern, aber ich finde es konsequent, dass überall gleich zu machen.
‘direction=both’ klingt perfekt, wenn man in beide Richtungen einen Ortseingang hat. Im Gegensatz zu ‘oneway=both’ besteht dort kein Widerspruch in sich, der Vergleich passt m. E. deswegen nicht.
Dann muss man aber auch die Namen richtungsbezogen angeben, dann man wird nicht in beiden Richtungen den selben Ort haben:
name:forward=A-Dorf
name:backward=B-Stadt
Hervorragende Idee! Meiner Meinung nach muss der neue JOSM-Check auch für city_limit ausgeführt werden. direction=forward/backward ist am Wegende einfach nicht (sauber) definiert. Genauso übrigens für Suffixe :forward und :backward, die sollten an Wegenden genauso wenig erlaubt sein. Checkt JOSM das?
Zu den Ortsschildern selbst gibt es, denke ich, zwei “saubere” Lösungen. Beide haben ihre Fürsprecher in der weltweiten Community und in diesem Thread, beide haben ihre Vor- und Nachteile.
- city_limit neben der Straße, mit direction in Himmelsrichtung oder Grad. Hat den Vorteil, dass man das Schild dort mappen kann, wo es OTG steht. Allerdings ist die Zuordnung Schild-Weg u.U. schwierig, man denke z.B. an einen Kreisverkehr innerorts, mit Ortsausgang an einer (oder mehreren) Zufahrtsstraßen. Ob Schilder rechts oder links von der Straße stehen, weiß man als Kartengebraucher nicht zuverlässig. In DE mögen Schilder (beinahe) immer rechts stehen. In GB und anderen Ländern mit Linksverkehr stehen sie, vermute ich, beinahe immer links. Und dann gibt es natürlich die Ausnahmefälle wie in diesem Thread schon angesprochen. In NL sind beinahe alle Ortsschilder doppelt verhanden, links und rechts. Sollen wir die dann doppelt mappen? Das kann es doch auch nicht sein.
- city_limit auf der Straße, mit direction=forward/backward. Das darf dann nicht am Wegende sein, also da wo sich (normalerweise) maxspeed ändert. Stattdessen setze ich einen separaten Node direkt davor/danach, vielleicht einen Meter weit weg. Das kann man als “Verrenkung” betrachten, das verstehe ich. Aber es kann keine Missverständnisse geben. Jeder, sogar Kollege Computer, weiß sofort, welcher Weg betroffen ist. Man muss nicht wissen, ob in diesem Land Ortsschilder rechts, links oder sonstwo stehen.
Vor- und Nachteile, wie gesagt.
Das hab ich auch im Wiki so dargestellt, auf deutsch und englisch, im Nachgang zur Diskussion hier im August. Kann durchaus sein, dass der Text verbesserungswürdig ist. Das höre ich gern (bzw. lese es direkt im Wiki, wie auch immer).
Schade und verwirrend finde ich, dass die beiden Methoden direction unterschiedlich definieren: auf dem Weg zeigt direction stadteinwärts, neben dem Weg stadtauswärts. Das ist vermutlich eine dieser OSM-Inkonsistenzen, die historisch so gewachsen ist und jetzt nicht mehr zu ändern ist.
Was im Wiki noch nicht abgebildet ist, ist der Übergang von einer geschlossenen Ortschaft zur nächsten. Das sollte verbessert werden. Ich setze dann city_limit auf dem Weg, ohne direction tag (wird hier nicht gebraucht), dazu name:forward=Stadt A, name:backward=Stadt B. Das geht auch nicht auf einem Kreuzungsnode, siehe oben. Wie man das mit Schildern neben dem highway abbildet, ist mir nicht klar. Zwei separate nodes, name=Stadt A + city_limit=end auf einem, name=Stadt B + city_limit=begin auf dem anderen? Kommt mir unschön vor. Weiß wer was besseres?
Edit: alt_name ist mMn für Situationen, wo zwei unterschiedliche Ortsnamen auf dem Schild stehen. Der erste ist dann name, der zweite alt_name. Kommt in mehrsprachigen Gebieten vor. Ich sehe das z.B. oft in (der niederländischen Provinz) Friesland. In Deutschland vielleicht im Sorbengebiet relevant oder kurz vor der dänischen Grenze? Ist jedenfalls nicht für Ortswechsel gedacht, bilde ich mir ein.
Ja, der Test prüft auch alle Knoten mit Tags, die mit “:direction” enden und die Werte “forward” oder “backward” haben.
Du kannst gerne die latest Version von JOSM ausprobieren und entweder hier oder im JOSm Ticket Feedback geben: https://josm.openstreetmap.de/josm-latest.jar
Warum nicht? Wenn beide ways die gleiche Richtung haben ist doch alles klar. iD wertet das auch sauber aus und zeigt es richtig an. Anders wird ein Schuh draus: Es sollte geprüft werden, dass in so einem Fall beide ways die gleiche Richtung haben und dass sich nur zwei ways in dem Koten treffen.
Ja, das scheint mir auch so.
Je mehr ich darüber nachdenke, desto besser gefällt mir das. Wenn JOSM (und iD?) eine Fehlermeldung auswerfen, sobald einer der Wege gedreht wird, wäre das eigentlich recht stabil. Spart das Gehampel mit extra Knotenpunkten.
Jetzt juckt es mich in den Fingern, mit Overpass zu checken, wie oft city_limit an Kreuzungspunkten hängt und wie da die Wegrichtungen sind. Das erste hab ich schon mal gemacht. Ob da zwei oder mehr Wege aufeinander stoßen: das schaffe ich auch irgendwie. Aber wie kann ich Overpass fragen, ob die zwei Wege in die gleiche Richtung gehen oder nicht? Weiß das jemand? In der Dokumentation finde ich auf die Schnelle nichts mit ‘direction’.
Hallo Gerd, finde es auch klasse, das eine Prüfung für die richtungbezogenen Wegeendpunkte geschaffen wird.
Also ich bin kein Freund davon, das osm-Wegrichtungen geändert werden, falls etwas mit der Richtung vom Endpunkt nicht passt.
Bei so einem Fall bekommt man das dann wohl sowieso nicht hin:
https://www.openstreetmap.org/edit?node=3395700458#map=21/50.93174/11.57985
Ich könnte mir vorstellen anstatt forward/backward zu verwenden tatsächlich ausschliesslich die Gradzahlen von 0-360 ranzuschreiben. Mal eine Frage an die Programmierer. Würde die Variante mit ausschliesslich Gradzahlen dann für die Datenauswerter nicht zu kompliziert werden, also wenn z.B. für ein Stoppschild eine Strafzeit beim Routing verrechnet werden soll, um vorher anhand der Gradzahl zu bestimmen, ob es für die Routingrichtung zählt? Falls das machbar ist, dann könnte man ggf. auch in umgekehrter Denkweise eine Editorvorlage entwickeln, bei der vom Mapper forward/backward angewählt wird, aber die Editorsoftware stattdessen die entsprechende Gradzahl an den Punkt schreibt?
Ich kann mir Stellen vorstellen, wo mehrere ways durch so eine Stelle gehen “müssen”, z.B. wenn das Ortsschild auf der Gemeindegrenze steht. D.h. man müsste auch noch die Art des ways checken, highway z.B., und vermutlich abhängig von den Node-tags und den way-tags jeweils definieren, auf welchen way sich ein “forward” oder “backward” auf einem Node bezieht. Finde ich nicht so ein Superdatenmodell, hört sich eher so an, als wäre das teilweise ziemlich kompliziert.
Ich habe ja kein Problem damit, einen Punkt in den highway zu setzen, wenn es sich um ein punktförmiges ‘Ereignis’ handelt (crossing, traffic_calming, stop, give_way etc.)
Ich finde es aber unsinnig, eine ab dort gültige Eigenschaft an dem Punkt kennzeichen zu wollen (urban/rural, maxspeed, access).
Und noch unsinniger finde ich es, dann auch noch traffic_sign= statt wie sonst highway= als key für einen Punkt im highway zu verwenden …
traffic_sign ist das Schild - und das gehört wie alle anderen traffic_sign an den Standort des Schildes.
traffic_sign sollte reine Mapperinformation bzw. Stadt/Landschaftsmöbiliar (3D-Rendering) bleiben - taggt meinetwegen highway=city_limit wie die anderen punktförmigen highway-nodes, wenn es unbedingt sein muss.
Denn was nützt es, wenn ein Router während der Fahrt auf den Ortsein- oder -ausgang hinweisen kann (*) - aber bei Fahrtbeginn nicht unterscheiden kann, wo er sich befindet …
Edit: (*) Das kann er auch anhand des Wechsels der highway-Eigenschaften - genauso, wie er vor Höchstgeschwindigkeitswechseln warnen kann.
Das Ortseingangsschild begründet keine administrative Boundary. Denn dann dürfte es ja innerhalb des Gemeindegebietes keine solchen Schilder geben.
das wäre halt ziemlich kompliziert bis unmöglich, innerorts/ausserorts automatisch aus den city limit Schildpositions-Daten rauslesen zu wollen, zumindest bei Großstädten und unter der Annahme, dass man weder alle Schilder erfasst hat noch dass es überhaupt an jedem Weg in jedem Fall ein Schild gibt. Als man das maxspeed source urban etc. eingeführt hat war die Situation, dass man überhaupt nicht zwischen innerorts und ausserorts unterscheiden konnte weil einige Leute kein maxspeed=50 taggen wollten wo es nicht explizit ausgeschildert war.
Das sollte auch nicht der Sinn sein, dazu gibt es ja die Merkmale an den Kanten. Die einzige Anwendung die mir einfällt ist, die Ortseingangs- und -ausgangsschilder in die Wegebescheibung / Routingansagen als Information aufnehmen zu können. Sind halt markannte Ortsmarken, die bei der Orientierung helfen. Die Richtungsangabe ist dann wichtig, um zwischen Orteingang und -ausgang unterscheiden zu können.
Die selben Fragen ergeben sich übrigens bei Signalen bei der Eisenbahn. Dort gelten oft ab dem Signal andere Geschwindigkeiten, so dass im Anschluss oft eine neue Kante beginnt.
Bei der Bahn ist es aber sehr selten, dass am Standort des Signals eine Weiche ist, so dass dort mehrere Kanten beginnen. Zudem sind die Kanten vor und nach dem Signal in der Regel gleich gerichtet. Wenn hier JOSM validiert, dass Signale mit Richtungsangabe nicht am Kantenende stehen dürfen, wird es beim Eisenbahnmapping dauernd klingeln.
Signale werden nahezu immer auf das Gleis gemappt und nicht daneben, (im Gleis liegt eigentlich nur der zugehörige Magnet, der Züge ggf. zum Zwangshalt bringt). Signale wären beim Routing über Gleise essentielle Ortsmarken, die auszugeben sind. Darum ist das gut so, dass sie in OSM nicht neben den Gleisen stehen.
Das wurde hier zwar schon diverse Male erklärt, warum das nich so schwarz-weiss ist, aber näxter Versuch:
Ich werfe da mal Kilometertafeln (zur Vereinfachung: an Autobahnen) in die Runde. Das sind “Schilder”, die eindeutig 2 OTG- Regeln besitzen, und in OSM in aller Regel eine von diesen Regeln verletzen.
Man kann die Tafel OTG dorthin packen, wo sie OTG steht, oder dorthin, wo sie OTG gilt. Hier gibt es auch nicht die Ausnahme wie bei traffic_sign&Co, sondern es ist immer falsch richtig.
Ansonsten vielleicht die Beiträge nochmal lesen, die nicht so falsch/richtig werten, sondern das Problem als Problem behandeln.
Danke für die Beiträge, das Thema scheint ähnlich umstritten wie das Radwegemapping, wenn auch weniger komplex. Ich denke, ich werde den Test in JOSM noch mal ändern, so dass er nur mit “Invalid usage” (ungültige Verwendung) warnt, wenn ein alleinstehender Knoten mit direction=forward/backward gefunden wird. Für die anderen Fälle denke ich eher an “Disputed usage” (Umstrittene Verwendung).
Beim Reversen von Wegen mit direction=forward/backward Knoten gibt es jetzt auch einen Dialog, der fragt, ob die Richtung umgekeht werden soll, aber da muss eigentlich viel mehr Logik bzw. Text rein, um die zuvor genannten Fälle aufzudröseln.
OT:
Mein persönliches Fazit fürs Mappen ist dann immer: Wenn es so schwer zu verstehen ist und so leicht kaputtzumachen, dann lass ich es lieber ganz. Wenn ich einen Router entwickeln würde, dann sähe ich das genauso. Daten, die mit großer Wahrscheinlich falsch sind, kann man ignorieren.
+1, einfach einen node neben die Straße, keinen direction tag, und fertig
Außer dass dann keiner weiß, wo drinnen und wo draußen ist. Du wirst sagen: aber ich mach das Schild rechts. Und ich werd sagen: aber das stimmt nicht immer. Aber gut, das Thema hatten wir schon.