vielleicht is es nur ein Problem meiner JOSM-Installation, aber die Abbiegebeschränkung “no_entry” wird offenbar nicht unterstützt. Normalerweise wird ja ein Icon am “via”-Node angezeigt. Bei “no_entry” würde ich dann das Zeichen “Verbot der Einfahrt” erwarten. Es wird aber nichts angezeigt und beim Upload meldet der Validator, dass mehr als ein “from” gefunden wurde (ignoriere ich, da bei “no_entry” erlaubt).
Ich habe zwar im JOSM-Bugtracker einige Tickets gefunden, komme aber nicht dahinter, warum “no_entry” bislang nicht unterstützt wird.
Mir ist auch schon aufgefallen, dass unter Relation:restriction die Values no_entry und no_exit von restriction=* fehlen. (Bei restriction:* stehen sie drin.) Weiter unten steht auch was zur fehlenden Software-Unterstützung. Mit der JOSM-Entwicklung kenne ich mich aber nicht aus.
Gruß, Hendrik
Habe ich auch gesehen. Wurde 2021 entfernt mit der Begründung
removed no_entry and no_exit, which are rarer, not widely supported, and already discussed below w/ adequate context
Dieses “discussed below” konnte ich aber nicht finden.
Unter “Edge cases” steht:
As of March 2021, the no_entry and no_exit restrictions are not supported by a number of popular OSM tools and routers[6], and it’s unclear if there is any consensus about how these situations should be mapped.[7]
Ist das denn noch so, also speziell Router? Oder gibt es “nur” ein Problem, wenn mehrere “from” existieren.
Ich habe es mal hier getestet.
OSRM und GraphHopper beachten die Beschränkung für Autos und werten auch except aus.
Valhalla beachtet sie nur, wenn man von Osten kommt. Routing.
OsmAnd beachtet sie gar nicht.
Da fällt mir ein, dass ich ein restriction=no_entry bei Aufräumarbeiten aufgeteilt habe, weil JOSM eine Warnung abgib, dass es zwei from-Einträge hat. Dann habe ich im Wiki gelesen, dass es eigentlich so gewollt ist, dass ein restriction=no_entry mehrere Eingänge haben kann (vmtl. weil es so allgemein ist), was weiter zeigt, dass es von JOSM nicht wirklich unterstützt wird.
Ich wollte mal die entsprechenden Stellen im JOSM Code ändern, sodaß zumindest nicht gemeckert würde, habe aber festgestellt, dass man dafür erst mal passende Vorlagen entwickeln müsste. Auf dem Stand scheint es immer noch zu sein: #18014 (Validator marks no_entry and no_exit-restrictions as an error) – JOSM
Es ist ein klassisches Beispiel bei dem man neues Tagging unter dem Tisch eingeführt hat, dass spezielle Behandlung in jedem Editor (mindestens jedem das Geometrieänderungen unterstützt) benötigt.
Und oh Wunder, es wird dann halt auch nicht unterstützt.
PS: in Vespucci funktioniert das Auftrennen übrigens korrekt. Beim Erstellen muss man zusätzliche from Ways händisch zur Relation hinzufügen und die Darstellung in der Relationenmitgliederansicht ist auch nicht super schön.
Editor devs um ihre Meinung fragen? Oder zumindest auf die Diskussion aufmerksam machen. Ja ich weiss, dass es möglicherweise den Leuten nicht klar ist welche Taggingänderungen tatsächlich solchen Input brauchen und welche nicht, aber kann ich auch nicht ändern.
Wieso benötigt eigentlich “no_entry” eine spezielle Behandlung? Grundsätzlich ist das doch zunächst mal ein from → via → to, d.h. ich wähle die (oder eine der) Straße(n) aus, von der ich komme, dann den via-Node und dann die Straße, in die nicht einfahren darf. Wenn dafür eine der Straßen aufgeteilt werden muss, erfolgt das wie bei einer der anderen Abbiegebeschränkungen. Falls weitere “from” benötigt werden, können diese dann ja in einem zweiten Schritt hinzugefügt werden.
Es geht mir nicht ums Erstellen (das ist höchstens ein Nebenspielplatz), sondern darum, dass jeder der OSM editiert ständig indirekt Relationen ändert, z.B. jedes mal wenn man ein Weg aufspaltet oder Wege verbindet.*
D.h. Abweichungen von den 2 breit unterstützten Schema:
standard Relationmitgliedschaft bleibt erhalten für erstellte Teilwege (in der “richtigen” Reihenfolge).
from - via - to nur der am via angrenzender Teilweg vom aufgespaltenen from und to bleibt in der Relation, für via Wege bleiben beide Teilwege in der Relation.
Im vorliegenden Fall sprich mehrere from oder to Mitglieder gibt es bei der naheliegenden Implementation (sprich man ignoriert andere from oder to Wege) vermutlich keine Probleme, aber es ist z.B. definitiv etwas das einen Test des Verhaltens braucht.
* es gibt vermutlich auch so genug Fälle die, vermutlich bei allen Editoren, zu kaputten Relationen führen, z.B. Endpunkte von Wegen umhängen und ähnliches.