Danke - hatte ich auch hier schon bemängelt.
http://forum.openstreetmap.org/viewtopic.php?pid=651347#p651347
Hier ein Beispiel. wo die TR noch fehlt(e) → jetzt korrigiert. Also doch notwendig?
Wo zwei separate Ways sich vereinigen, sind sie IMHO notwendig. Sonst kommt es zu Routings wie im von dir angeführten Fall. Aber diese TRs auf sich selbst finde ich nicht sinnvoll, und ich kenne auch keinen Router, der da ein Wendemanöver vorschlagen würde.
–ks
Sinnvoll oder nicht, da gibt es sicherlich unterschiedliche Meinungen.
Ich stimme jedoch vollumfänglich zu, dass ein guter Router defekte TRs ignorieren sollte.
Da ich in meiner Region im Laufe der Zeit so manche Straße im Bereich einer baulichen Trennung aufgeteilt habe, frage ich mich natürlich, wo überall noch ich Routingprobleme ungewollt und unbemerkt erzeugt habe.
Als ID-Verwender frage ich mich nun, wie ich am besten diese Fehler hier in der Region suchen und ggf. beheben kann. Hat jemand gute Tipps für mich?
Interessanterweise hat mein Garmin-eTrex20 bislang mit den OSM-Karten noch keine Probleme gemacht. Ich wurde z.B. ohne Probleme weiterhin über die B1 geführt, obwohl der Fehler dort bereits in der von mir genutzten Kartengrundlage mit eingeflossen sein muss.
Beispiel:
https://www.keepright.at/report_map.php?schema=101&error=78139465
(kurz verschieben um Marker zu sehen)
https://ahorn.lima-city.de/tr/
Wie gesagt: Hier kommen zwei Fehler zusammen. Erstens ändert iD eigenmächtig und ohne Kenntnis des Nutzers die members der Relation, zweitens wird die dadurch technisch defekte TR von OsmAnd „auf Verdacht“ ausgewertet, indem er einen anderen via-Node annimmt als gegeben ist. Beides sollte nicht sein. Die meisten anderen Router, z.B. der von mir angeführte MapFactor und offenar auch dein eTrex, ignorieren solche defekten TR, was IMHO richtiger ist und ich OsmAnd auch empfehle.
–ks
ok - mit keepright habe ich auch schon gearbeitet. Ich werde mal meine Region durchsuchen und Korrekturen durchführen. Hoffe, dass gelingt mir per iD…
Mache doch nur erst einmal ein paar (mit iD) und verlinke sie hier einmal zum nachschauen. Ich habe keine gute Erfahrung in iD mit diesen TR.
Wie willst du denn sonst, z.B. ein Wendeverbot an einer Ampel an einer nicht richtungsgetrennten Strasse modellieren?
PS: das hat nichts damit zu tun, dass iD da klar ein Bug hat, den muss man halt beheben.
Punkt für dich. Meine erste Reaktion ist zwar, ob wir so was überhaupt modellieren müssen, da ich keinen Router kenne, der solche Wendemanöver vorschlägt. Lieber biegt er ab und fährt einen Rundkurs in anderer Richtung auf die Straße zurück. Aber we map what’s on the ground, und das ist so ein Wendeverbot zweifellos.
Aber schau dir mal die B 1 zwischen PB und Horn an. Da steht an fast jedem Way-Übergang so eine TR, auch fernab jeglicher Kreuzung. Darin sehe ich wirklich keinen Sinn mehr.
–ks
Nö, das macht überhaupt keinen Sinn.
Meine Erfahrung ist, das alle PKW-Router in manchen Situationen das Wenden an einer Ampel vorschlagen. Hab jetzt auf die schnelle nur Beispiele mit getrennten Richtungen gefunden, aber vom Wendevorgang dürfte das ja vergleichbar sein oder nicht? http://www.openstreetmap.org/directions?engine=graphhopper_car&route=50.78959%2C6.11601%3B50.78866%2C6.11566#map=18/50.78789/6.11451
Ist nicht vergleichbar, denn um genau den Unterschied geht es ja.
Wenden von Weg A über Punkt 1 auf (gegenläufigen) Weg B ist für einen Router eine normale Streckenoption und genau das, wofür no_u_turn da ist. In solchen Fällen muss es gesetzt werden, wenn Wenden verboten ist, und deshalb rege ich mich auch immer auf, wenn jemand für eine 5 m lange Verkehrsinsel den Way aufteilt, aber keine TRs an die Enden setzt 
Aber Wenden von Weg A über Punkt 1 auf Weg A in Gegenrichtung – so einen Vorschlag hab ich noch von keinem Router erlebt. Wenn der an solchen Stellen wenden will, dann, wie beschrieben, biegt er lieber ab und fährt einen Rundkurs, um in Gegenrichtung auf Weg A zu gelangen.
–ks
Wenn es auch nicht ganz egal ist was die Router machen, geht es doch eher darum einfach den Sachverhalt festzuhalten.
Man kann leider bei der Bearbeitung im ID-Editor nicht wirklich erkennen, welche Abbiegebeschränkungen bzw. Kehrtwendeverbote richtig angelegt sind und welche nicht. Vor allem, wenn man einen Kreuzungsbereich entsprechend der baulichen Gegebenheiten umgestaltet (baulich getrennte Fahrbahnen, nicht getrennte Fahrbahnen, Anbindung von Einmündungen an der richtigen Stelle, …) können im ID-Editor alle Abbiegebeschränkungen und Kehrtwendeverbote durchaus korrekt angelegt zu sein scheinen, sind es aber - wie ich nun feststellen musste - teilweise doch nicht.
In Kombination mit “keepright” scheint man den Fehlern aber ganz gut auf die Spur zu kommen und das Tool meckert so lange, bis man im Editor die Fehler vollständig korrigiert hat. Und wenn man die eine oder andere Abbiegebeschränkung zunächst löscht und dann mit dem ID wieder neu anlegt. Das, was der ID bei der Neuanlage an Abbiegebeschränkungen neu erstellt, scheint zumindest nach “keepright” dann aber korrekt zu sein.
Ich werde ab heute also bei solchen Veränderungen stets eine Überprüfung mit “keepright” https://www.keepright.at vornehmen.
Wäre es nicht sinnvoller, statt Fehler nachträglich zu überprüfen und zu korrigieren, gleich Fehler vor dem hochladen zu erkennen und zu berichtigen und dazu einen besseren Editor zu verwenden, z.B. JOSM ?
Grüße
- keep_right arbeitet mit Daten - derzeit von 2017-07-07 - also “alten”
- ich habe selbst versucht ein Wendeverbot in iD zu erstellen - du kannst zwar via angeben - aber wie wählst du from - to?
http://osmose.openstreetmap.fr/de/byuser/?username=Galbinus&item=0,3180 findet zumindest Kandidaten, die Du persönlich zuletzt angefasst hast.
Edit: da in Deiner Gegend heute nicht nur Du nachgewischt hast, ist die Liste erst morgen wieder aktuell. Meiner Erinnerung nach gibt’s gg. 1 Uhr immer Updates.
Hier einige, die ich auf die schnelle finden konnte, die von keep_right nicht angezeigt werden, da from, via und to vorhanden sind:
http://www.openstreetmap.org/relation/5324940
http://www.openstreetmap.org/relation/4828559
http://www.openstreetmap.org/relation/4471300
http://www.openstreetmap.org/relation/4063312
http://www.openstreetmap.org/relation/5297158