Autobahnpassage A3 Montabaur (O>W) Routingprobleme mit OsmAnd + OSRM

Das hat OsmAnd vor Jahren bei mir reproduzierbar zwei weiter in Limburg-Nord gemacht (von Köln nach Frankfurt, dann ist wegen langer Rechtskurve die Verteilerfahrbahn geometrisch kürzer), wurde ihm aber schnell abgewöhnt (AFAIK hab ich’s auf Github gemeldet). In Montabaur habe ich das noch nicht beobachtet. Längere Strecken fahre ich aber seveso lieber mit MagicEarth.

--ks

Ich bin da normalerweise nicht unterwegs. Es wäre gut, wenn ein zweiter OSM -Kollege mit Navi OsmAnd dies bestätigen könnte. Ich möchte nicht speziell OsmAnd unterstützen, sondern die OSM mit all ihren Navi-Programmen. OsmAnd ist aber sonst schon sehr weit brauchbar.

kreuzschnabel wrote:

Längere Strecken fahre ich aber seveso lieber mit MagicEarth.

Werde es mal checken (auf meinem neuen smartphone S.s8)

Rogehm wrote:

Es wäre gut, wenn ein zweiter OSM -Kollege mit Navi OSMAnd dies bestätigen könnte.

Jo, kann ich. Eine beliebige Routinganfrage, die zwingend an Montabaur vorbei in Fahrtrichtung Köln über die A3 führt, wird derzeit von OsmAnd bei https://www.openstreetmap.org/node/378146 nach rechts auf die Verteilerfahrbahn geleitet und bei https://www.openstreetmap.org/node/378118 wieder zurück.

Kartenstand von heute 06:54 per Live-Abo.

--ks

Hab mal einen Issue aufgemacht: https://github.com/osmandapp/Osmand/issues/7470

Bin zur Zeit im Urlaub und nutze Osmand sehr viel als Fahrrad- und Fußroutingmaschine.

Ich weiß nicht, ob das jetzt schon OT ist, aber Osmand hat noch viel mehr Routingprobleme, z. B. leitet es mich mit Einstellung Fahrrad entgegen der zulässigen Fahrtrichtung durch Einbahnstraßen und über Fußwege (highway=footway), ohne das ein Hinweis erfolgt, man müsse jetzt absteigen. Auch das Routing mit PKW treibt mir zuweilen den Schweiß auf die Stirn, hab' nur gerade kein Beispiel zur Hand.

Geofreund1 wrote:

Auch das Routing mit PKW treibt mir zuweilen den Schweiß auf die Stirn, hab' nur gerade kein Beispiel zur Hand.

Hier gibt's was zum gruseln: https://groups.google.com/forum/?hl=de# … ggXbFoxly8

kreuzschnabel wrote:

Längere Strecken fahre ich aber sowieso lieber mit MagicEarth.

Danke für den Tipp. Installiert. Macht einen guten Eindruck. Den obig beschriebenen Fehler gibt es hier nicht. Die App ist nicht ganz so umfangreich wie OsmAnd, aber die optische Darstellung ist recht gut gelungen. Die Bedienung ist noch nicht optimal. Erst einmal +1 für den Tipp, besser mit MagicEarth zu fahren. P.S. Und Danke für das Issue.

abrensch wrote:

Hier gibt's was zum gruseln

Das ist nicht gut (eingeschränkt). Was, um Himmels Willen, treibt es die Entwickler dazu, Schrankenbarrieren als zulässig für die Autonavigation zuzulassen? Aber manche Ziele sind sonst nicht erreichbar. Eine Warnung würde daher vollkommen reichen. (Habe ich das richtig verstanden? Jede Barriere?)

Rogehm wrote:

(Habe ich das richtig verstanden? Jede Barriere?)

Nicht jede, sondern als Defaultwert für unbekannte Barrieren. Keine Angst, ein normales barrier=bollard ist auch ohne access-Tagging in Osmand für PKW gesperrt.

Trotzdem ist diese Änderung in der Interpretation scheiße. Wie oft habe ich schon ein barrier=yes gesehen für Schranken o.ä., wo der Kollegen einfach kein genaueres Tagging kannte, aber abbilden wollte, dass dort eine Absperrung ist. Wer sagt mir jetzt, dass Osmand da nicht einfach durchfahren will?

--ks

kreuzschnabel wrote:

Rogehm wrote:

(Habe ich das richtig verstanden? Jede Barriere?)

Nicht jede, sondern als Defaultwert für unbekannte Barrieren. Keine Angst, ein normales barrier=bollard ist auch ohne access-Tagging in Osmand für PKW gesperrt.

Hab' mal bisschen gesucht und man muss tatsächlich suchen. Demnach hat sich bei solchen Dingern die Logik geändert:

https://www.openstreetmap.org/node/4936634959
https://www.openstreetmap.org/node/5213123188

Hab' aber gerade gesehen, dass ich bei BRouter auch immer schon nur für eine explizite Liste von Barrieren (gate|bollard|lift_gate|cycle_barrier) die pessimistische Regel benutze.