OSM-Router, seltsames Verhalten von CloudMade-Router

Hallo,

ich habe eine Frage zum Routen mit OSM-Daten.

Auf OSM-Routenplanern im Internet (z.B. http://maps.cloudmade.com oder http://www.openrouteservice.org) werden Abbiege-Restriktionen scheinbar leider völlig ignoriert. Lediglich Einbahnstraßen werden berücksichtigt.

An einer Stelle kann ich mir das Ergebnis aber überhaupt nicht erklären.
http://www.openstreetmap.org/?lat=51.256613&lon=6.780247&zoom=18&layers=B000FTF
Es handelt sich um eine in beide Richtungen befahrbare Straße (L 56 Ulmenstraße) von der eine Einbahnstraße abzweigt (Esperantostraße).
Es existiert ein Abbiege-Verbot: Man darf nicht von Norden kommend von der Ulmenstraße in die Esperantostraße nach links abbiegen.
Das ist in OSM abgebildet mit einer Abbiegerestriktion only_straight_on:

  • Rolle from: nördlicher Teil der Ulmenstraße
  • Rolle via: Knoten Ulmenstraße/Esperantstraße
  • Rolle to: südlicher Teil der Ulmenstraße

Mit dem CloudMade-Router gibt es an dieser simplen Abzweigung völlig abstruse und für mich nicht nachvollziehbare Ergebnisse:

Beispiel Route mit Startpunkt Ulmenstraße nördlich der Abzeigung, Zielpunkt Ulmenstraße südlich der Abzweigung:
Der Router glaubt, es sei verboten, die Kreuzung in diese Richtung zu überqueren. Stattdessen wird für die zehn Meter Strecke eine Stadtrundfahrt vorgeschlagen:
http://maps.cloudmade.com/?lat=51.256476&lng=6.779498&zoom=17&directions=51.25662416077218,6.779937744140625,51.25616086049716,6.779969930648804&travel=car&styleId=1

In Gegenrichtung (also mit vertauschten Start- und Zielpunkten) klappt das Überqueren der Kreuzung:
http://maps.cloudmade.com/?lat=51.256476&lng=6.779498&zoom=17&directions=51.25617764682052,6.780002117156982,51.256637589696034,6.780002117156982&travel=car&styleId=1

Warum glaubt der Router, es sei verboten, die Abzweigung von Norden nach Süden zu überqueren?
Ist die Abzweigung falsch kartiert?
Sind die beteiligten Wege falsch kartiert?
Ist die kartierte Abbiege-Restriktion Ursache des Fehlers?
Spinnt der Router?

Ich bin hier völlig ratlos. Leider macht dieser blöde Fehler das Routing ausgehend von Startpunkten in Unterrath(Großmarkt) in vielen Fällen völlig unbrauchbar. Die Ulmenstraße ist das wichtigste “Ausfalltor” in Richtung B7/B8. Diese virtuelle OSM-Sperre ist sehr ärgerlich.

Ach ja:
Auf meinem Navi (Garmin etrex VISTA HCx, mit all_in_one-OSM-Karte) werden Abbiege-Restriktionen aus OSM im Allgemeinen scheinbar korrekt und nachvollziehbar ausgewertet. (Jedenfalls meistens.) Die besagte Abzweigung wird mit dem Navi aber auch nicht korrekt behandelt: Das Überqueren der Abzweigung von Norden nach Süden ist nur mit Einstellung ‘Fahrrad’ möglich. Mit Einstellung ‘Auto / Motorrad’ ist das Überqueren nicht möglich.

Eine Bitte habe ich noch: Bitte startet jetzt keine vorschnellen Versuche mit testweise ummappen der Abzweigung. Die Auswirkungen auf den Router stellen sich erst nach Wochen ein. Die Methode ‘Ändern, Auswirkung auf das Ergebnis beobachten, wieder Ändern, …’ würde Monate dauern.

Die letzten Änderung an den beteiligten Objekten habe ich am 18.9.2009 durchgeführt.
Ich bin mir nicht sicher, ob die heutigen Ergebnisse von CloudMade noch auf ältere Daten zurückzuführen sind.
Auch wenn die Anzeige der Karte in CloudMade aktuelle Daten zeigt, die Daten für das Routing von CloudMade können trotzdem uralt sein. Die Tatsache, dass für das Routing andere Daten als für die Hintergrundkarte verwendet werden, kann man an folgendem Effekt sehen: CloudMade zeigt manchmal Routen an (dicke blaue Striche), die teilweise nicht zur angezeigten Hintergrundkarte passen.

Das Routing mit dem Navi habe mit der OSM-all_in_one-Karte vom 28.9.2009 getestet. Hier sollten die letzten Änderungen vom 18.9.2009 also drin sein.

Es liegt die Vermutung nahe, dass ein Fehler in den kartierten Daten die Ursache ist, da das Problem mit zwei unterschiedlichen Routern auftritt.
Ich kann aber in den Daten keine Fehler finden. Was habe ich da falsch kartiert?

moin,

sieht für mich richtig aus, aber habe noch nicht mit Abbiege-Restriktionen gearbeitet.
Das gleiche passiert auch ein Stückchen weiter südlich: http://maps.cloudmade.com/?lat=51.252783&lng=6.78174&zoom=17&directions=51.253320526331336,6.78057074546814,51.25446876765532,6.780281066894531&travel=car&styleId=1

Edit: dort nicht nur von S nach N, sondern azch von O nach W
PS: bei deinem Beispiel wird man mit dem Rad um den Friefhof und dann auf einen primary_link geroutet, ist das erlaubt?

Stimmt. Und hier auch:
http://maps.cloudmade.com/?lat=51.254076&lng=6.779879&zoom=18&directions=51.25395172686549,6.780753135681152,51.253904722868995,6.779744625091553&travel=car&styleId=1

In allen drei Fällen ist eine Restriktion only_straight_on im Spiel. In allen drei Fällen wird diese als no_straight_on also exakt als das Gegenteil interpretiert.

Kann ich nicht nachvollziehen. In meinem Beispiel schlägt CloudMade mit dem Rad eine Route rund um den Nordfriedhof vor. Das ist erlaubt. Auch wenn die Route abstrus lang ist.
Zu Fuß wird eine Route durch den Nordfriedhof vorgeschlagen. Das ist erlaubt aber ebenfalls abstrus lang. Das kann aber daran liegen, das CloudMade Straßen mit access=destination völlig ignoriert. Das halte ich für eine extreme Macke von CloudMade.
Access=destination bedeutet kein Verbot für Fußgänger. Aber das ist ein anderes Thema.

war nicht schnell genug mit dem Edit

Hier noch zwei Beispiele:
http://maps.cloudmade.com/?lat=51.243972&lng=6.78645&zoom=18&directions=51.243609690021025,6.787233352661133,51.2442275913119,6.786621809005737&travel=car&styleId=1

http://maps.cloudmade.com/?lat=51.244792&lng=6.787952&zoom=17&directions=51.24587976486,6.789700984954834,51.2452551696424,6.790130138397217&travel=car&styleId=1

Alle diese fünf Fälle haben Restriktionen mit only_straight_on. Alle diese Restriktionen wurden von mir kartiert.
In allen diesen Fällen wird das ‘only’ aus only_straight_on von CloudMade als ‘no’ ausgelegt.
Mit Ausnahme des Ausgangsbeispiels werden alle anderen Beispiele mit dem Navi korrekt behandelt.

Jetzt bleiben zwei Möglichkeiten:
i) Ich habe Restriktionen mit only_straight_on nicht verstanden.
ii) Der Entwickler von CloudMade hat Restriktionen mit only_straight_on nicht verstanden.

Angenommen es trifft i) zu: Was ist an den von mir kartierten Restriktionen falsch?

only_straight_on bedeutet doch einfach nur, dass man nicht abbiegen darf, bzw. nur geradeaus fahren darf. Da gibt es doch eigentlich nicht viel falsch zu verstehen.

Ziemlich eindeutig ii). Möglicherweise sind die noch auf dem Stand von letztem Jahr, als es nur Verbotsrelationen (no_-Semantik) gab und eine Prüfung eines weiteren Tags (restriction=) nicht erforderlich war - was aber kein gutes Licht auf ihre Software wirft.

Womöglich betrifft das dann auch andere only_, denn für einen Router ist der Teil des Wertes nach dem no_ oder only_ eigentlich egal. Es gäbe also kaum einen Grund, geradeaus als Sonderfall zu behandeln.

Ach tatsächlich? Die only_-Sematik ist neueren Datums als die no_-Sematik? Das wusste ich gar nicht (bin erst seit ein paar Monaten dabei). Das könnte tatsächlich das seltsame Verhalten erklären. Es wird grundsätzlich bei allen Restriktionen nur ‘no’ angenommen. Enttäuschend.

Als Würg-around könnte man jetzt nur noch no_*-Restriktionen verwenden. Unschön. Abgewandeltes Mantra: Wir mappen nicht für Router…

Gibt es überhaupt einen WEB-OSM-Routenplaner der Restriktionen unterstützt?
Oder gibt es denn wenigstens einen Offline-Routenplaner auf Basis von OSM-Daten mit Unterstützung von Restriktionen?

Doch. Wenn das Verbot nur für KFZ gelten soll, wäre motor_vehicle = destination
das richtige Tagging.

http://wiki.openstreetmap.org/wiki/DE:Key:access

Aber ich gebe Dir Recht , dass Router das nicht so streng auslegen sollten, da die
Datenqualität in der Hinsicht sehr schlecht ist.

MapSource. :slight_smile:
Da die mkgmap Entwickler sehr fleissig sind nehme ich an, dass dort die Restrictions funktionieren.

Grüße
Chris

Hallo Chris

Selbst bei Zeichen 250 (Verbot für Fahrzeuge aller Art) mit dem Zusatz “Anlieger frei” gilt das Verbot nur für Fahrzeuge, nicht aber für Fußgänger.

Ja richtig, in dem Fall wäre das richtige Tag: vehicle = destination.

Die falsche Verwendung von access=destination kommt zum Teil wohl daher, dass es in Osmarender
mit den blauen Kreuzchen markiert wird.

Alternative wäre, zusätzlich zum access=destination noch ein foot=yes (und evntl. bicycle=yes) zu taggen, dann ist es wieder richtig
und man hat die blauen Kreuzchen. :slight_smile:

Anliegerbeschränkungen für LKW (hgv=destination) kann man übrigens gut in der
Maxspeedmap sehen.

Hi,

…wenn man für die Renderer taggt… :rage:

Viele Grüße
Mathias :wink:

Zustimmung, das Verbot bei diesem Zeichen mit Zusatz gilt nicht für Fußgänger. Aber wie sollte man das kartieren?
Verbietet, wie chris66 sagt, access=destination allein auch Fußgänger?

Wie würdet ihr konkret folgende Situationen kartieren?

i) Zeichen 260: Verbot für Krafträder, auch mit Beiwagen, Kleinkrafträder und Mofas sowie für Kraftwagen und sonstige mehrspurige Kraftfahrzeuge
mit Zusatzzeichen 1020-30: Anlieger frei

access=destination, bicycle=yes
oder
access=destination, foot=yes, bicycle=yes
oder
motor_vehicle = destination

ii) Zeichen 250: Verbot für Fahrzeuge aller Art
mit Zusatzzeichen 1020-30: Anlieger frei

access=destination
oder
access=destination, foot=yes

iii) Zeichen 250: Verbot für Fahrzeuge aller Art
mit Zusatzzeichen1020-12: Radfahrer und Anlieger frei

access=destination, bicycle=yes
oder
access=destination, foot=yes, bicycle=yes

Na ja. Ich hätte genauer fragen sollen: Ich hatte da aber schon offene Software im Auge. Auch für richtige Betriebssysteme verwendbar wäre nicht schlecht. :wink:

Klar, der Router auf dem Navi mit der OSM-all_in_one-Karte verwendet ja auch das Ergebnis von mkgmap. Und damit funktionieren wie gesagt die Restriktionen. Es ist zu vermuten, dass damit auch MapSource mit den Restriktionen klarkommt. MapSource kann ich aber nicht testen.

Allein schon um Missverständnisse vorzubeugen würde ich foot=yes mit taggen.

Oh danke. Kannte ich noch nicht.