Ich hab mal einen Ischju aufgemacht: https://github.com/osmandapp/Osmand/issues/4051
–ks
Harald: Danke für’s Korrigieren der Links!
kreuzschnabel: Danke für das Issue!
Der Fehler bei dieser speziellen Straße muss übrigens zwischen der Stelle mit letzten Aufforderung zum Wenden und der Abfahrt Externsteine liegen, denn danach wird die B1 verwendet und es erfolgt keine Anweisung zum Abbiegen oder Wenden mehr. Und das ist, soweit ich weiß, der Teil der B1, der noch von der alten B1 stammt, die quer durch Horn ging statt dran vorbei. Kann es sein, daß da etwas durcheinander geraten ist?
Übrigens gibt es bei Bielefeld auch so eine seltsame Streckenführung von Osmand. Wenn man von der Steinhagener Straße kommt und ein Ziel erreichen will, daß direkt an der B61 (Gütersloher Straße) liegt, wählt Osmand diese Route:
(Als ich das Bildschirmfoto machte, stand ich an der Ampel, daher wird die Route erst ab dort angezeigt.)
Vermutung: http://osm.org/way/28872858 hat maxweight=50, während http://osm.org/way/139014958 dich ohne Gewichtsbeschränkung über den Trüggelbach bringt.
–ks
Die Strecke ist einwandfrei gemappt – abgesehen von einigen Eigentümlichkeiten wie unnötigen motorroad=no und oneway=no. Außerdem finden sich da massenhaft meine speziellen Freunde, nämlich Wendeverbote eines Ways auf sich selbst (mit derselben ID in from: und to:). Aber die sind auch nicht so angelegt, dass sie das Weiterfahren verböten (das kann dabei nämlich passieren).
Die Fortsetzung der B1 nach Nordost ist motorroad=yes. Das bestärkt mich in meinem Verdacht, dass er das für ein access-Tag hält.
–ks
Wir haben den Schuldigen!
Relation 4543816, einer meiner Lieblinge, diese Wendeverbote an Einzelways mit demselben Member in to und from. Hier lief was schief, und im to war nach einer Bearbeitung nicht mehr derselbe, sondern der folgende Wegabschnitt – was von OsmAnd trotz technischem Fehler (der via-Node ist kein gemeinsamer Node von to und from) ausgewertet wird, in diesem Fall halt als no_straight_on.
Das ist jetzt schon der zweite Fehler dieser Sorte innerhalb von drei Wochen. Ich beginne langsam zu vermuten, dass ein Editor da Käse macht, indem er bei der Aufteilung so eines Ways, der gleichzeitig to und from ist, einen der neuen Teile ins from und den anderen ins to steckt.
Diese Relation wurde, sorry to say, von User:Galbinus in https://www.openstreetmap.org/changeset/39600517 mit iD 1.9.5 zuletzt bearbeitet, wobei der from-Weg ausgetauscht wurde:
Es muss unbedingt untersucht werden, ob iD das in solchen Fällen standardmäßig macht. Wenn ein Way gleichzeitig to und from ist, und dieser Way wird geteilt, muss anschließend immer noch derselbe Way in to und from sein (also alte oder neue ID).
Im Issue habe ich vorgeschlagen, dass OsmAnd solche technisch invaliden TRs besser ignorieren sollte.
–ks
PS: Damit wäre auch klar, wieso der Fehler in umgekehrter Fahrtrichtung nicht auftritt. Ich bin nämlich vor drei Monaten da langgefahren, und OsmAnd hat mir brav die B1 angewiesen 
Gerade ausprobiert, an genau diesem Way: Ja, iD macht das falsch. Wenn ich einen Way, der in einer TR to und from gleichzeitig ist, teile, ist anschließend der am via andockende Way im from und der andere im to.
Das Dumme ist, dass der Mapper kaum eine Chance hat, das zu merken, weil iD in der Relations-Ansicht nur allgemeine Bezeichnungen der Members angibt, die für beide Teilstücke gleich sind (hier: „Schnellstraße B1“), und keine OSM-ID, und die Members auch nicht in der Zeichenebene hervorhebt, wenn man mit der Maus drübergeht.
Wo kann das gemeldet werden? Dieses Verhalten muss bei iD schnellstens abgeschaltet werden.
Abgesehen davon, dass die TR damit technisch defekt ist (via ist nicht mehr am to) und OsmAnd sie beim Routing einklich ignorieren sollte. Das hab ich auf Github für OsmAnd gerade vorgeschlagen.
–ks
Ich nehme an, die Tickets für den iD-Editor können unter folgender Adresse eingepflegt werden:
https://github.com/openstreetmap/iD/issues
=> grüner Knopf “New issue”
Das ist für mich wieder so ein typisches Beispiel, wo eine total verrückte Komplexität entsteht, ohne dass ich darin einen wirklichen Sinn sehe. Auf den allermeisten grösseren Strassen - meistens Bundesstrassen - ist wenden verkehrstechnisch gesehen unsinnig. Und die Information dass ich bei spurgetrennten Strassen nie gegen die Fahrtrichtung auf die Spur einbiegen darf, ist auch banal.
Dass ich dazu an jeder doofen Kreuzung Abbiegeverbotsrelationen anlegen soll - die ja auch noch kompliziert zu warten und fehlerkritisch sind - finde ich sehr unbefriedigend und frage mich schon ewig, ob es da nicht ein viel einfacheres Vorgehen möglich wäre.
Das verlangt doch keiner von dir. Ich persönlich stimme dir zu, ich finde diese Wendeverbote mit gleichen members im to und from erstens totalen Quatsch, zweitens ein Zumüllen der Datenbank und drittens technisch defekt (deshalb ändert das iD wohl auch auf Verdacht beim Teilen).
Aber wenn andere Mapper das gern so machen, sollen sie. Ich habe hier mit User:Mah schon endlose Diskussionen geführt, der davon überzeugt ist, dass es Router gibt (zeigen konnte er mir allerdings noch keinen), die ihre Fahrer an den Enden von OSM-Ways wenden lassen, wenn man das nicht ausdrücklich verbietet, und man bei jeder Teilung solche TRs an die Enden setzen muss. Das Wiki sagt das nirgends, und ich sehe auch sonst keinen Grund dafür.
Da wird auch niemand eine TR anlegen. Abbiegen in Einbahnstraßen gegen die Fahrtrichtung muss in keinem Fall ausdrücklich verboten werden.
–ks
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.