den Weg von unten nach oben als from-element
den einzigen gemeinsamen Punkt, den beide Wege gemeinsam haben, als via-punkt
den (Teil-)weg (den muss man ja ggf. von Hand da splitten) vom via-Punkt nach RECHTS
und als type dann only_right_turn
Kann diese Definition erstmal als richtig bestätigt werden?
Denn:
Wenn man ein derartiges Abbiegeverbot mit dem an sich ja ganz tollen Plugin von den Skobbler-Leuten neu anlegt, passiert folgendes:
Dazu einfach mal ohne zu speichern zwei Wege neu zeichnen(und benennen, damit man sie unterscheiden kann), die sich wie ein T berühren. Dann die beiden selektieren und das Plugin aufrufen.
Durch die eingebaute Fehlersuche schlägt das Plugin vor, den waagerechten Weg zu teilen den einzigen gemeinsamen Punkt als via-punkt zu übernehmen.
als to-element wird (zumindest nach dem Aufspalten des waagerechten Wegs durch die Fehlerbehebung des Plugins) nicht das waagerechte Teilstück vom via-punkt nach rechts genommen, sondern das nach LINKS!
Reproduzierbar?
Ist diese Verfahrensweise des Plugins nun richtig oder falsch?
Alle Deine Ausführungen sind korrekt. Also auch die Annahme, daß das Plugin einen BUG hat, ist korrekt. (Wenn Dein Text so stimmt, ich habe es nicht ausprobiert). Ich persönlich arbeite hier immer ohne Plugin, das neuste JOSM sortiert die markierten Elemente in den Relations-Editor in der Reihenfolge wie ich sie markiere. Ich markiere also immer erst den FROM-Weg und als letztes den TO-Weg, und kann in dem Fenster dann oben FROM und unten TO eintragen. Ist nicht langsamer als ein Plugin. Wer das Plugin nutz, sollte natürlich ein Bug-Freies Plugin haben.
@chris Das wäre falsch, Turn-Restrictions haben immer “3 Arme”. No-xxx verbeitet einen Arm und erzeugt Straßenschilder mit zwei Pfeilen. Only-xxx erlaubt nur einen “Arm” und erzeugt ein Straßenschild mit nur einem Pfeil.
Aber, jetzt kommt (3)… Mathematisch gesehen ist beides richtig. Eine Routingsoftware wertet no-left und only-right logischer weise genau gleich aus und wird einen nach rechts schicken. Einzig und alleine für das Straßenschild ist entscheidend, was man nimmt. Daher sollte man nicht das falsche nehmen, auch wenn es eigentlich richtig ausschaut.
Ich habe es ausprobiert. Das Verhalten lässt sich reproduzieren und es ist falsch.
Oder zumindest ist es nicht so, wie man es sich wünschen würde. Da das Verhalten bei mir aber nicht davon abhängt, ob ich no_left_turn, no_right_turn oder only_straight_on wähle, schätze ich, dass die Software die Art der Restriction einfach nicht bei der Auswahl des Wegsegments berücksichtigt, sondern immer das erste der durch die Wegteilung entstandenen Segmente auswählt. Dazu passt auch, dass ein Umdrehen des waagerechten T-Strichs das Verhalten genau umkehrt.
Ticket sollte man aber erstellen.
In dem Plugin kann man die Art der Restriction direkt wählen, daran liegts also nicht.
Auf den Fehler mit dem Plugin bin ich nämlich gekommen, als ich mir unter http://osm.virtuelle-loipe.de/restrictions/ mal meine kürzlich angelegten Abbiegeverbote angeschaut habe.
Denn der dortige Restriction-Prüfer zeigt den falschen to-Weg als Fehler an.
Gibt es in eurer jeweiligen Gegend auch derartige Fehler?
Ich verwende “Graph View” in JOSM zum Prüfen der Restriktionen. Zugegeben, die Ansicht mit den weißen Pfeillen und den Minispitzen ist bescheiden, aber besser als nix…
Geht das Routing-Plugin überhaupt noch? Ich wollte es eben mal wieder ausprobieren, aber ich schaffe es nicht einmal, Start- und Zielpunkte zu setzen.
Das Backend für eine Verbesserung des Routing-Plugins kann ich bereitstellen - den Graphen aus GraphView kann man nämlich prinzipiell nicht nur ins Fenster malen, auf dem könnte man auch routen. Damit würde das Routing-Plugin zumindest schon mal all das verstehen, was GraphView kann: Abbiegever- und gebote, Gewichts-/Höhenbeschränkungen, barrier-Nodes etc.
Aber die grafische Oberfläche schreiben und das Ganze pflegen ist mir momentan zu viel Arbeit, da müsste sich schon sich jemand anderes drum kümmern.