Autonavigation nicht möglich

Hi zusammen,

bitte habt Nachsicht, wenn das vielleicht eine Anfängerfrage ist.
Der Weg auf den Koordinaten 50.88909, 11.13769 kann mit einem Auto befahren werden.

Eine Routenberechnung dorthin ist auf openstreetmap.org auch möglich.
Nehme ich ein Navi auf dem Handy oder bspw. openrouteservice.org funktioniert das nicht.
Das Kartenmaterial dort ist so aktuell wie bei openstreetmap.org selbst.

Link zur fertigen Route

Ich bastele schon etwas an dem Weg dran rum, komme aber zu keinem Ergebnis.

Wer kann helfen?

Danke und Gruß

Welches?

Beide Wege haben ein vehicle-Tagging (vermutlich ist motor_vehicle gemeint) mit Semikola, das wertet nicht jede Software richtig aus.

Bitte nicht am Weg „basteln“, wenn der korrekt getaggt ist. Wenn Router fehlerhaft sind, gleichen wir das nicht durch falsches Tagging aus. OSM bildet die Tatsachen vor Ort ab.

–ks

Um diese Stellt geht es oder? https://www.openstreetmap.org/?mlat=50.88936&mlon=11.13720#map=18/50.88909/11.13769

Bist Du Dir sicher, dass da jeder langfahren darf? Der Mapper, der den Weg eintragen hat, hat vermerkt, dass hier nur Land/Forstwirtschaft und Anlieger lang dürfen.

Also ganz so einfach ist das nicht mit “hier die allwissende community, da die ignoranten Routing Autoren”

Wiki nämlich skeptisch: https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

und empfiehlt irgendwie boolean space tags.

Also wäre es doch erlaubt, diese Situation zu beschreiben mit:

motor_vehicle=destination
forestry=yes
agricultural=yes

Würde ich in BRouter für’s Auto-Routing eine generelle ODER-Regel für semikolon-tags einbauen würde ich ein Minenfeld zünden, wer weiss denn, was da so alles rumliegt. Sowas macht man nicht ohen Not und insbesondere nicht, wenn das Wiki das Semikolon-Tagging eigentlich als deprecated erklärt hat.

Danke erstmal für die Antworten.

Magic Earth (wobei die nicht ständig die Karten aktualisieren) und als Karten-App “Galileo Pro”.

Nein, es darf nicht jeder da lang fahren. “Land/Forstwirtschaft und Anlieger” ist schon richtig.

Ja um diese Stelle geht es auch.
Nennen wir sie Zwischenziel (bei der Routenberechnung ist es unerheblich, ob das der Start ist oder das Zwischenziel).

Es geht viel mehr um diese Stelle bzw. das ist das Ziel

Merkwürdig ist, dass die Routenberechnungen mich über das Zwischenziel führen, jedoch nicht zum Ziel selbst.

Beide Wege haben jedoch - was ich als Neuling beurteilen kann - die gleichen Tags.

Wenn jetzt also diverse App / Programme die Tags unterschiedlich auswerten, warum komme ich dann zumindest bis zum Zwischenziel während beide Orte das gleiche Tagging haben. Bei gleichem Tagging unterstelle ich gleiche Auswertung. Und nicht mal so mal so.

Hab ich auch nicht gesagt. Und ich finde das Vorgehen mit Semikola auch suboptimal. Ich habe nur gesagt, dass wir nicht so lange an einem Weg herumtaggen, bis irnkein Router da wie gewünscht langroutet :slight_smile:

ist nicht dasselbe. agricultural vor dem Gleichheitszeichen bezeichnet eine Fahrzeugkategorie, hinter dem Gleichheitszeichen eine Verkehrsart. Mit agricultural=yes darf man mit Traktor da auch abends zur Party fahren. Mit motor_vehicle=agricultural darf der Bauer auch mit dem Golf zu seinen Feldern fahren.

–ks

Warum das so ist, ist einfach:
liegt das (Zwischen-)Ziel genau auf der Straße, die mit Anlieger getaggt ist, wird dieses Ziel als “Anlieger” interpretiert, damit Anlieger frei und das Routing funktioniert.
Dein eigentliches Ziel liegt aber in einer abzweigenden Straße. Kein Ziel auf dem zu durchfahrenden Weg, kein Anlieger, ergo keine Fahrberechtigung (für den “Durchgangsverkehr”) und kein Routing.

Genau das kann das Problem sein – je nachdem, wie der Router die Beachtung von destination implementiert, kann es Folgen haben, wenn er von einem „destination“-Weg auf einen anderen „destination“-Weg abbiegen muss. Was suboptimal wäre – würde ich Router programmieren, würde ich „destination“ implementieren als „Fahr hier nur dann lang, wenn das Ziel unmöglich anders zu erreichen ist“, und das wäre hier ja gegeben.

Näheres wird dir nur der Herausgeber der Software sagen können, für Magic Earth wende dich vertrauensvoll an support@generalmagic.com. Du wirst innerhalb weniger Stunden von dort erfahren, wie wertvoll dein Feedback ist und dass die nächste Version gaaaanz tolle Fietschers haben wird, und das gemeldete Problem wird auch in drei Jahren noch drin sein.

–ks

Das wäre ja echt blöd. Zumal das ja aber nicht der Realität entspricht.

Wieso geht dann diese Navigation, diese hier und diese?
(alles abzweigende Straßen)

Diese jedoch nicht.

Das OSM Verkehrszeichentool:
http://osmtools.de/traffic_signs/?signs=

Ich habe nun verschiedene Ursachen gehört / hinein interpretiert:

  • falsche Verkehrszeichen
  • falsches Tagging / alle Straßen gleiches Tagging
  • Umgang der Router (wenn damit die Routensoftware gemeint ist)

Daher (nochmal) die Frage …

Du hast an https://www.openstreetmap.org/way/30174009/history erst vor paar Stunden rumgebaut. Vermutlich braucht es einfach eine Weile (edit: Wohl bis zu 2 Wochen), bis ORS das Update verarbeitet hat.

Ich weiß nicht, wie alt die Daten in ORS sind. Vielleicht ist da sogar noch motorcar=no drin. Oder es stört sich an “vehicle=agricultural;destination;forestry”.

In der Nähe ist eine Schutzhütte, diese habe ich auch verschoben.
Diese Aktualisierung ist bereits “online”. Dann sollte die Aktualisierung des Weges doch auch schon online sein, nicht?
“vehicle=agricultural;destination;forestry” habe ich am besagten Weg bereits entfernt.

Routing-Anwendungen akualisieren ihre Daten nicht in dem Maße, wie die Standardkarte selbst. Routing-relevante Änderungen zeigen sich gerne mal erst nach einem Monat. Ich glaube GraphHopper braucht ca. 3 Tage: https://graphhopper.com/maps/?point=50.888978%2C11.129344&point=50.888646%2C11.137755&locale=de&vehicle=car&weighting=fastest&elevation=true&use_miles=false&layer=OpenStreetMap

Sven

 Version 7 vor 1 Jahr
bicycle=yes
foot=yes
highway=track
motorcar=no
mtb:scale=0
mtb:type=crosscountry
surface=ground
tracktype=grade3

Version 14 gestern
highway=track
mtb:scale=0
mtb:type=crosscountry
name=Auf dem Katzenberg
smoothness=very_bad
surface=gravel
tracktype=grade2
traffic_sign=DE:250,DE:1020-30,DE:1026-38
width=3

Hier fehlen die access=*
(laut Link auch in http://osmtools.de/traffic_signs/?signs=250,1026-38,1026-30 )
taxi=yes
vehicle=agricultural;forestry
traffic_sign=DE:250,1026-38,1026-30

Und bei Änderungen allen etwas Zeit geben und nicht ständig etwas ändern. Viel Zeit brauchen auch Renderer und Router.

Dann war es sicher “nur” die Zeit, der ich hinterher renne.
Ja, bei GraphHopper ist es aktualisiert. Dann warte ich einfach mal und gebe den Änderungen mehr Zeit. Sorry für die Aufregung.

Wieso Taxi?
Verstehe ich in dem Zusammenhang nicht.

sorry - hatte 1026 mit 1020 verwechselt

trotzdem sollte dann

vehicle=destination;agricultural;forestry

laut VZ an den Weg.

Bist du sicher das 250 steht und nicht 251 oder 260 (vorher war es 251 - motorcar=*)?

Wiki-Theorie und Mapping-Praxis ist aber auch nicht dasselbe, und ich gehe jede Wette ein, dass man keinerlei Korrelation findet zwischen diesem Deutungs-Detail und den links oder rechts vom “=” getaggten agriculturals.

Steht auch so, wie von kreuzschnabel beschrieben, im Wiki (https://wiki.openstreetmap.org/wiki/DE:Key:access) und seit ich mich erinnern kann, mappe ich dementsprechend.

Auszug aus dem Wiki:

OK, alles klar.

Jupp, es steht die 250 dort. Verbot für Fahrzeuge aller Art.

  • 1026-38,1026-30
    Das stimmt schon so.