Osmand mag die B1 nicht...

Leider sind deine Bilderlinks kapott. Versuch’s mal mit pic-upload.de, da kriegst du gleich den fertigen BBCode zum Reinpasten mit Vorschau 🙂

--ks

die Gesamtstrecke

einer der vielen Aufforderungen zum Abbiegen

die Aufforderung zum Wenden

@kreuzschnabel: sein dienst hätte/hat es auch gekonnt, nur muss man halt wissen, dass man hier BBCode einfügen kann 😉

Bestätigt – die B1 wird tatsächlich gemieden. Auch im normalen PKW-Modus ohne Beschränkungen und mit Startpunkt direkt auf der B1 verlässt er sie an der nächstbesten Möglichkeit:

Mit Beschränkungen wie angegeben fährt er bei mir zwar nicht über Langeland, aber über Altenbeken und Feldrom.

Mal die Ways der B1 auf unsinniges Tagging abchecken.

--ks

Am Tagging der Strecken fällt mir nur ein „motorroad=no“ auf. Sollte OsmAnd das als motor_vehicle=no stehvermissen?

--ks

Ich bin den Bereich zwischen der Ausfahrt Schlangen/Kolhstädt und Horn (Paderborner Straße) mal durchgegangen. Ich konnte keinen Fehler finden.

kreuzschnabel wrote:

Am Tagging der Strecken fällt mir nur ein „motorroad=no“ auf. Sollte OsmAnd das als motor_vehicle=no stehvermissen?

--ks

Das ist mir auch aufgefallen, und an einer Stelle "oneway=no"

Aber was da noch alles mit ref=B 1 an der Straße dranhängt an abgehenden/zuführenden links, mannomann … und teilweise sogar in der B-1-Relation drin ist :-/

--ks

Wenn’s tröstet – MapFactor Free Navigator ermittelt, auch mit OSM-Karten, eine deutlich sinnvollere Strecke:

Der LKW-Modus reicht in der Free-Version zwar nur bis 3,5 t, aber OsmAnd spinnt ja sogar ohne jede Fahrzeugbeschränkung schon rum. Damit würde ich den Fehler eindeutig bei OsmAnd suchen.

--ks

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.)

Wolfgang_PB wrote:

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:

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

Wolfgang_PB wrote:

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?

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 🙂

kreuzschnabel wrote:

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).

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.

Skinfaxi wrote:

Dass ich dazu an jeder doofen Kreuzung  Abbiegeverbotsrelationen anlegen soll - die ja auch noch kompliziert zu warten und fehlerkritisch sind - finde ich sehr unbefriedigend

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.

Und die Information dass ich bei spurgetrennten Strassen nie gegen die Fahrtrichtung auf die Spur einbiegen darf, ist auch banal.

Da wird auch niemand eine TR anlegen. Abbiegen in Einbahnstraßen gegen die Fahrtrichtung muss in keinem Fall ausdrücklich verboten werden.

--ks

kreuzschnabel wrote:

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.

🙁

AB-inf-x-chg-AB wrote:

Ich nehme an, die Tickets für den iD-Editor können unter folgender Adresse eingepflegt werden:

Haben wir. Danke.

--ks

kreuzschnabel wrote:

Wir haben den Schuldigen!

Danke - hatte ich auch hier schon bemängelt.

http://forum.openstreetmap.org/viewtopi … 47#p651347

@Skinfaxi:

http://www.openstreetmap.org/directions … 21/16.4599

Hier ein Beispiel. wo die TR noch fehlt(e) -> jetzt korrigiert. Also doch notwendig?

geri-oc wrote:

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 … w_tmpign=1

https://www.keepright.at/report_map.php … r=78139465

EDIT:
https://www.keepright.at/report_map.php … w_tmpign=1

(kurz verschieben um Marker zu sehen)

Galbinus wrote:

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?

https://ahorn.lima-city.de/tr/

Galbinus wrote:

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.

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...

Galbinus wrote:

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.

kreuzschnabel wrote:

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).

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.

SimonPoole wrote:

kreuzschnabel wrote:

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).

Wie willst du denn sonst, z.B. ein Wendeverbot an einer Ampel an einer nicht richtungsgetrennten Strasse modellieren?

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

kreuzschnabel wrote:

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.

Nö, das macht überhaupt keinen Sinn.

kreuzschnabel wrote:

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.
--ks

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 … 89/6.11451

Trockennasenaffe wrote:

kreuzschnabel wrote:

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.
--ks

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 … 89/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.

Galbinus wrote:

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

Galbinus wrote:

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.

1. keep_right arbeitet mit Daten - derzeit von 2017-07-07 - also "alten"
2. ich habe selbst versucht ein Wendeverbot in iD zu erstellen - du kannst zwar via angeben - aber wie wählst du from - to?

Galbinus wrote:

Hat jemand gute Tipps für mich?

http://osmose.openstreetmap.fr/de/byuse … tem=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

luschi wrote:

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

Noch mehr? ---> http://overpass-turbo.eu/s/qks

Leute, ich kann Eurem Fach-Denglisch zwar nicht folgen, aber ich bin beeindruckt von der Energie, mit dem Ihr den Fehler angeht. Danke! 🙂

Wolfgang_PB wrote:

Leute, ich kann Eurem Fach-Denglisch zwar nicht folgen, aber ich bin beeindruckt von der Energie, mit dem Ihr den Fehler angeht. Danke! 🙂

Ich glaub, wir sind schon etwas woanders. Der Mappingfehler ist jedenfalls weg, mit dem August-Update sollte dein Osmand wieder vernünftig fahren. Und die Software, die den Fehler da reingebaut hat, ist auch schon gefixt, der nächste Bearbeiter macht es nicht wieder kaputt.

Danke jedenfalls für die Meldung, sonst wäre das sicher nicht in dieser Weise aufgefallen. Ich hatte, wie angedeutet, vor drei Wochen schon genau so einen Fall, hab das aber auf Unachtsamkeit des Kollegen geschoben (hab mich schon im CS dafür entschuldigt).

--ks

Galbinus wrote:

ok - mit keepright habe ich auch schon gearbeitet. Ich werde mal meine Region durchsuchen und Korrekturen durchführen. Hoffe, dass gelingt mir per iD...

Durch die vorgeschlagene Seite von Kreuzschnabel https://ahorn.lima-city.de/tr/ bin ich auf folgenden Changeset gestoßen.
https://www.openstreetmap.org/changeset/50176018
Da sind trotz Deiner Reparaturen immer noch Fehler vorhanden. keepright und JOSM melden, dass etwas mit der Start und Ziellinie nicht stimmt.

Daniel

thetornado76 wrote:

Da sind trotz Deiner Reparaturen immer noch Fehler vorhanden. keepright und JOSM melden, dass etwas mit der Start und Ziellinie nicht stimmt.

Relation 2852824 ist schlicht überflüssig. Da kann man ja nur straight-onnen, weit und breit keine Abzweigung am via.

--ks

kreuzschnabel wrote:

Relation 2852824 ist schlicht überflüssig. Da kann man ja nur straight-onnen, weit und breit keine Abzweigung am via.
--ks

OK habe ich gelöscht und ein wenig aufgeräumt mit Abbiegeverboten in die Einbahnstraßen an der Kreuzung. Es bleiben im Moment 7 Wendeverbote, die meiner Meinung nach aber auch überflüssig sind.

PS: Mal noch eine Frage am Rande. Wie kann ich in JOSM mir die History einer Relation ansehen? Für Nodes, Ways ist es klar, anklicken und STRG + H.

thetornado76 wrote:

Wie kann ich in JOSM mir die History einer Relation ansehen? Für Nodes, Ways ist es klar, anklicken und STRG + H.

Ebenso, nur vorher Rechtsklick auf die Relation und „Relation auswählen“. Dann werden die members pink dargestellt.
So kriegt man sie auch am einfachsten gelöscht, auswählen und <Entf>.

--ks

kreuzschnabel wrote:

Ebenso, nur vorher Rechtsklick auf die Relation und „Relation auswählen“. Dann werden die members pink dargestellt.
So kriegt man sie auch am einfachsten gelöscht, auswählen und <Entf>.

--ks

Ahhh, besten Dank - hätte ich auch selber drauf kommen können 🙄

Zu den Wendevorschlägen: das unten abgebildete vorgeschlagene Wendemanöver ist schon mit einem PKW oberhalb der Smart-Klasse ein Wagnis. Mit einem 18 Meter langen Gefährt wird es zur Gefahr für die Allgemeinheit!

Auch, wenn der LKW-Modus noch nicht offiziell ist: solche Manöver darf eine Navi-Software gar nicht erst in Erwägung ziehen!

Wolfgang_PB wrote:

solche Manöver darf eine Navi-Software gar nicht erst in Erwägung ziehen!

Das meldest du am besten den Entwicklern der Navi-Software. Wenn da Wenden nicht per Schild oder Fahrbahnmarkierung verboten ist, dann gibt es keinen Grund dafür, es im Tagging zu unterbinden – denn damit würden wir es ja auch dem Smart verbieten, der es laut deiner Formulierung kann.

Und nochmal das Übliche: Ein Navi gibt keine Befehle, sondern bestenfalls Empfehlungen. Ob das so fahrbar ist, ist immer die Entscheidung und Verantwortung des Fahrers!

--ks

kreuzschnabel wrote:

Das meldest du am besten den Entwicklern der Navi-Software. Wenn da Wenden nicht per Schild oder Fahrbahnmarkierung verboten ist, dann gibt es keinen Grund dafür, es im Tagging zu unterbinden

Man sollte eventuell dort ein Wendeverbot eintragen - es ist ja nur eine "einfache" weiße Linie bis zur nächsten Kreuzung. Und Abbiegespuren fehlen auch noch ...

https://www.mapillary.com/app/user/geri … 078&zoom=0

Falls noch jemand im Bereich Horn um die B1 herum geroutet wurde: an dieser Brücke https://www.openstreetmap.org/way/388435287 war vor kurzem noch motor_vehicle=no eingetragen.

Wenn man den Changeset-Kommentaren folgt, hätte das wohl ein bicycle=no werden sollen. Vllt. versehentlich falsch aus einem dropdown ausgewählt.

geri-oc wrote:

kreuzschnabel wrote:

Das meldest du am besten den Entwicklern der Navi-Software. Wenn da Wenden nicht per Schild oder Fahrbahnmarkierung verboten ist, dann gibt es keinen Grund dafür, es im Tagging zu unterbinden

Man sollte eventuell dort ein Wendeverbot eintragen - es ist ja nur eine "einfache" weiße Linie bis zur nächsten Kreuzung. Und Abbiegespuren fehlen auch noch ...

https://www.mapillary.com/app/user/geri … 078&zoom=0

Wahrscheinlich habe ich etwas zu schnell reagiert und mir das Luftbild nicht mehr angesehen (hab im Urlaub gerade dünne Netzanbindung). Wenn die Fahrbahnmarkierungen ein Wendeverbot rechtfertigen, gehört es natürlich getaggt.

--ks