Graphhopper-Routing - Fahrrad fehlerhaft

nur eine Vermutung: Könnte es sein, dass Graphhopper hier für Fahrrad-Routing den spezifischen bicycle-Key nutzt und sich über das allgemeinere access hinwegsetzt?!

Ich habe hier ähnliche Probleme mit dem Routing, insbesondere weil MapQuest und Graphhopper wohl das access-Tag unterscheidlich auswerten.

Fahrradrouting
- Graphhopper korrekt -> http://www.openstreetmap.org/directions … 10/7.45087
- Mapquest falsch -> http://www.openstreetmap.org/directions … 927/7.4445

Mapquest wertet anscheinend den Tag access=permissive und bicycle=yes als "no".

Fußgängerrouting
- Graphhopper korrekt -> http://www.openstreetmap.org/directions … 10/7.45087
- Mapquest falsch -> http://www.openstreetmap.org/directions … 22/7.45087

Mapquest wertet den access-Tag private als erlaubt aus (permissive auf der vorderen Brücke wird richtig ausgewertet: http://www.openstreetmap.org/directions … 6/7.45111)

Zusätzliche Problemstellung sind private Wege (ist mir so in den Sinn gekommen): Private Wege als Durchgangswege müssten beim Routing als "access=no" ausgewertet werden. Bei privaten Wegen als ZIEL müssten sie als "permissive" ausgewertet werden.
Hintergrund: Will ich z.B. zu einer Hausnummer, die nur über eine als privat markierte Zufahrt erreichbar ist, dann darf ich ja über die private Zufahrt zu dem Haus fahren/gehen/schweben 😄.

EDIT: Auf der Bahnbrücke war foot=destination getaggt, dies habe ich jetzt korrekt zu "permissive" umgesetzt (private Brücke, Nutzung für Fußgänger und Radfahrer erlaubt).

Könnte es sein, dass Graphhopper hier für Fahrrad-Routing den spezifischen bicycle-Key nutzt und sich über das allgemeinere access hinwegsetzt?!

Und wenn er das tut wäre das vollkommen korrekt.
bicycle=* "überstimmt" ein access=no.

Moin !

Und wenn er das tut wäre das vollkommen korrekt.
bicycle=* "überstimmt" ein access=no.

Das sehe ich allerdings nicht so. access=no würde für mich global gelten und wenn ich einen Rad-/Fussweg habe, dann für diese beiden Teile auf jeden Fall.

Gruß Jan

Lübeck wrote:

Moin !

Und wenn er das tut wäre das vollkommen korrekt.
bicycle=* "überstimmt" ein access=no.

Das sehe ich allerdings nicht so. access=no würde für mich global gelten und wenn ich einen Rad-/Fussweg habe, dann für diese beiden Teile auf jeden Fall.

Gruß Jan

Das wiki sieht das anders:

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

Um aber nicht alle Verkehrsteilnehmer, für die der Weg verboten ist, einzeln aufführen zu müssen, verbietet man den Zugang zunächst für alle und erlaubt ihn dann für die Ausnahmen wie folgt:

highway=path
access=no
foot=yes
bicycle=yes

Lübeck wrote:

Das sehe ich allerdings nicht so. access=no würde für mich global gelten und wenn ich einen Rad-/Fussweg habe, dann für diese beiden Teile auf jeden Fall.

Mit dieser Logik würden die meisten Restriktionen nicht mehr funktionieren. Das spezifischere Tag (hier bicycle) überstimmt das generellere (access).
Wie taggst du z.B. eine Anliegerstraße, bei der Busse ausgenommen sind?

chris66 wrote:

Und wenn er das tut wäre das vollkommen korrekt.
bicycle=* "überstimmt" ein access=no.

+1

Das ist auch ein sehr wichtiges Grundprinzip, bitte nicht uminterpretieren.

Die Verwendung von access=no ist eh schon problematisch, weil es pauschal für alles gilt, was kein eigenes access-Tag hat. Dabei werden sehr oft implizit unzutreffende Verbote markiert für Verkehrsteilnehmer, an die der Mapper einfach nicht gedacht hat.

bye, Nop

Nop wrote:

Die Verwendung von access=no ist eh schon problematisch, weil es pauschal für alles gilt, was kein eigenes access-Tag hat. Dabei werden sehr oft implizit unzutreffende Verbote markiert für Verkehrsteilnehmer, an die der Mapper einfach nicht gedacht hat.

Du meinst snowmobile=*? Das wird ja oft vergessen 😄

access=no war eh unnötig. Dass man da eine zeitlang nicht fahren darf, war ja schon vorher durch die temporary:* Tags korrekt ausgedrückt.

Aber leider hat das wohl dein Navi nicht berücksichtigt, insofern kann ich deinen Frust verstehen dass du da einfach access=no drangepappt hast. Wenn das aber alle so machen, ändert sich an dieser Praxis leider nie was.

Es sei denn, die Brücke ist jetzt endgültig gesperrt. Dann nehme ich alles zurück, dann stimmt alles und die temporary-Tags gehören mal weg (stören aber auch nicht wirklich).

Gibt es eigentlich mittlerweile einen Router der temporary und/oder conditional berücksichtigt?

Gibt es eigentlich mittlerweile einen Router der temporary und/oder conditional berücksichtigt?

das wäre eine sehr interessante Frage ...!

Gruß Jan

Ein access=no wird aktuell tatsächlich von bicycle=yes etc überstimmt. Aus den Kommentaren nehme ich an das ist auch korrekt so 🙂

temporary:* wird von GraphHopper noch nicht unterstützt. Hat das tag immer ein 'on' und 'off' date? Und laut wiki muss man dann auch temporary:bicycle etc auswerten, oder?

Do not use temporary:access=no alone because it would not override the bicycle=* tag

BTW: movable bridge wird kommen, gibt nur zu viele dieser kleinen Dinge ... https://github.com/graphhopper/graphhopper/issues/343

Temporary würde ich nicht mehr implementieren, das war noch vor Conditional. Ich würde Conditional diesbezüglich weiterentwickeln. Die Schiersteiner Brücke wurde auch mit conditional getaggt bis ob fehlender Routerunterstützung noch access=no reinkam.

Hmmh, okay ... hast Du ein reales Bsp dafür?

karussell wrote:

Hmmh, okay ... hast Du ein reales Bsp dafür?

https://www.openstreetmap.org/way/31719627

Danke! Und das Datumsformat ist einheitlich oder irgendwo dokumentiert 🙂 ?

http://wiki.openstreetmap.org/wiki/Cond … strictions

Condition ... Time&Date ... Use the standard syntax of the opening_hours=* tag.

Moin !

hier noch ein Beispiel aus dem Anfangsbeispiel aus Lübeck: https://www.openstreetmap.org/way/151585355

Gruß Jan

Aber temporary ist ja deprecated oder 🙂 ?

karussell wrote:

Aber temporary ist ja deprecated oder 🙂 ?

Es ist ein Proposal dass nie richtig Fahrt aufgenommen hat und eine deprecated Syntax hat.

jetzt sollten unsere Sperrungen richtig umgetaggt sein !

Gruß Jan

Ich weiß nicht, ob auch anderen aufgefallen ist, dass Graphhopper Fahrradfahrer auch über Fußwege routet?

Beispiel:

von 49.463857,8.174858
nach 49.466737,8.17327

quer durch den Kurpark, der nur für Fußgänger zugelassen ist.

Ist das so implementiert oder ein Fehler?

Gruß
Geofreund1

Vermutlich ein Kolateralschaden der hochpräzisen OSM-Angaben. So freudig wie in der hiesigen Gegend Parkwege, die zum Radfahren freigegeben sind mit highway=footway getaggt sind, obwohl kein Zeichen 239 am Parkeingang steht, genauso freudig greifen die Router auf diesen Tag zurück.

Die interessante Sache ist, ob das Routing in seinen Berechnungen davon ausgeht, ob abgestiegen wird oder nicht. Man kann Gehwege mit 15 km/h oder 3 km/h gewichten. Grashopper scheint ca 3km/h anzusetzen und geht damit von einem Absteigen und Schieben aus.

Vielleicht wäre es sinnvoll, es in den Anweisungen zu vermerken. Aber Grasshopper routet auch kommentarlos über Treppen.

Nur eine Theorie: Vielleicht nutzt Graphhopper die Option, dass ein Fahrradfahrer auch absteigen und schieben kann und dann durch den Park schneller ist, als wenn er außenherum radeln müsste

Die interessante Sache ist, ob das Routing in seinen Berechnungen davon ausgeht, ob abgestiegen wird oder nicht. Man kann Gehwege mit 15 km/h oder 3 km/h gewichten. Grashopper scheint ca 3km/h anzusetzen und geht damit von einem Absteigen und Schieben aus.

Ich glaube inzwischen eher an einen Bug.

Von 49.467141,8.173914
nach 49.466737,8.17327

fährt Graphhopper mit dem Fahrrad schon mal durch die Agip Tankstelle und macht einen riesigen Umweg, als schneller - mit Schieben - die Abkürzung durch die nahe liegende Einbahnstraße zu nehmen.

Wird nun als Schiebestrecke angegeben. War ein Bug im UI.

Zu dem Problem selbst gibt es einen issue: https://github.com/graphhopper/graphhopper/issues/257

Eventuell habt ihr ja Kommentar / Meinungen dazu? Oft werden ja Fußwege nicht als bicycle=yes getaggt und da macht dann der Fahrradfahrer nen krassen Umweg, daher aktuell die 'Schiebestrecke' als Kompromiss

Moin !

ich muss nochmal nachfragen - ist für eine vorübergehende Einbahnstraße dieses Tag richtig:

oneway:conditional = @ 2015-03-30 - 2017-01-31

...?

Gruß Jan

Auf den ersten Blick:

yes @ (2015-03-30 - 2017-01-31)