Kurioses

Sorry wg. des fehlenden Links:

http://www.openstreetmap.org/#map=17/49.03590/8.70044

@mueschel
Warum routen dann Mapzen und OSRM direkt (wie ich es eigentlich auch erwartet hätte) und nicht so umständlich wie GraphHopper?
Die obere Schranke ist übrigens auch nur für Fußgänger durchlässig.

GraphHopper nimmt das Tagging wörtlich (insbesondere das “Impliziert: access=no” der Barriere), dann darf er dort nicht durch und routet dich so nahe wie es geht an den Marker heran.
OSRM und Mapzen interpretieren an den Daten herum und vermuten, dass Autos da schon durch dürfen. Bei einem barrier=bollard hingegen routet keiner der drei einfach so hindurch.

Für Autos routet tatsächlich GraphHopper nachvollziehbar. Leider gilt das nicht für Fahrradfahrer: da wird man - bei gleichen Markern wie in meinem ersten Beispiel - über den Fußweg nordöstlich des Parkplatzes geführt. Das man da schieben müsste, davon erfährt man nichts…

Edit: habe mal die lift_gates auch für Autos/Motorräder freigegeben, denn sonst bliebe der Parkplatz vermutlich ziemlich leer :wink:

Hi Geofreund, warum nimmst du nicht einfach motor_vehicle=yes oder direkt vehicle=yes? Oder gibt es da eine Zugangsbeschränkung für mopeds und Fahrräder?
Ich denke übrigens, dass der wesentliche Faktor für den Umweg die Parkplatzfläche mit access=customers sein dürfte. Wobei ich hier auch Mepzen und OSRM recht geben würde: Wenn man den Parkplatz als Ziel wählt, ist man warscheinlich auch ein Kunde, der dort parken darf.

Nebenbei: Wieso wird der Parkplatz plötzlich nicht mehr gelb gerendert? Den hat seit zwei Jahren keiner mehr angefasst. Eben war eine Kachel noch gelb, nach einem Neuladen ist jetzt alles grau.

Grüße

Update Carto: https://forum.openstreetmap.org/viewtopic.php?id=60483

Danke für den Link, empfinde ich persönlich als krassen Rückschritt, zumal man die Farbe offensichtlich nicht anderswo braucht.

Wohlgemerkt aber auch der erste nach einer langen Reihe sehr guter Updates :slight_smile:

Wo steht denn, dass barrier:lift_gate access:no impliziert? Bei “durchlässigen” Barriers ist die Annahme IMHO falsch, daher macht OSRM (und wohl Mapzen auch) das im Fahrzeugprofil meiner Meinung nach richtig, Graphhopper hingegen falsch:

Im Carprofile von OSRM findet man

barrier_whitelist = Set {
      'cattle_grid',
      'border_control',
      'toll_booth',
      'sally_port',
      'gate',
      'lift_gate',
      'no',
      'entrance'
    },

welche “durchlässige” Barrieren sind und somit für das Routing kein Hindernis darstellen.

Für eine Quelle wg. implizitem access:no wäre ich dir dankbar.

Gruß, Frank

Wie wärs mit access=customers? Bis auf hgv dürfen da wohl alle durch. Werde mir das noch mal genau vor Ort anschauen müssen.

+1

Wiki-Page Barriers:
"Each barrier has its own accessibility defaults. Use tag access=* to override them.

Barriers with undocumented default access imply access=no. This default restriction prevents softwares from routing through undocumented barriers (and generating a potentially unsafe route). "

Das Wiki ist mal wieder nicht einheitlich:

Die englische Seite wurde am 16.12.2016 von Richard Fairhurst geändert.

[1] https://wiki.openstreetmap.org/wiki/DE%3AKey%3Abarrier
[2] https://wiki.openstreetmap.org/wiki/Key%3Abarrier

Die Aussage auf der deutschen Seite macht wenig Sinn, wenn auf den einzelnen Seiten andere Werte vorgegeben sind. Im Text der englischen Seite steht das, was ich eins über dir geschrieben hat. Man sollte also den Text im Kasten der Aussage im Fließtext anpassen.

Danke. Hm - dann nehme ich alles zurück und behaupte das Gegenteil.

Wie du in deinem Beispiel gezeigt hast, kochen verschiedene Auswerter aber auch ihre eigenen Süppchen. Und ich habe den Verdacht, dass die ein oder ander Wiki-Seite hin und wieder auch mal klammheimliche Änderungen zu diesem Thema erfährt. Ich habe es mir deshalb zur Angewohnheit gemacht, bei jedweder Barrier immer explizit Access-Tags zu vergeben.

Das ist sicher erstmal keine schlechte Idee, zumindest bis jemand auf die Idee kommt, mal zu definieren, welche Werte wann als default angenommen werden und sich das dann auch durchsetzt. lift_gate und fence braucht sicher unterschiedliche Defaults.

Man könnte ja bei jedem barrier=* access=no generell als default sehen - egal welche. Dann macht es auch Sinn die einzelnen erlaubte anzugeben.

naja, bei barrier=bollard access=no als default zu setzen würde wahrscheinlich jedes Fußgänger und Fahrrad Routing zunichte machen :wink:

Wenn - dann könnte foot (bicylce) schnell ergänzt werden.

Dass ihr das macht glaube ich euch sofort und halte das auch für Sinnvoll. Allerdings steht ihr beileibe nicht für die gesamte Mapperschaft und es wird immer Mapper geben, die gar keine access Tags vergeben. Nicht zu reden von den unzähligen barriers, die jetzt schon existieren. Daher sollten die default-Werte möglichst nach Logik vergeben werden:

barrier=entry ist logischer Weise erstmal ein access=yes

barrier=bollard dient in erster Linie dem Fernhalten vom motorisierten Verkehr und lässt in der Regel nur Fahhräder und Fußgänger zu.

Ein barrier=lift_gate kann man in der Regel durchfahren, meist nach Bezahlung o.ä. Viele lassen sich auch zu Fuß umgehen (z.B. in Parkhäusern) Daher machen hier explizite default-Werte wenig Sinn. Wenn es eine Zugangsbeschränkung gibt, dann findet diese sich eh meist noch an den highway=service, den amenity=parking o.ä. Sonderfälle wie die Schranken an der Leverkusener Brücke haben in der Regel eh ein umfangreiches access-Tagging, was default-Werte überflüssig macht.

Auch bei einem barrier=border_control macht access=no als default-Wert wenig Sinn.

Ein barrier=gate hingegen ist oft verschlossen oder privat, daher hier erstmal access=no.

Die Liste könnte man noch ewig fortsetzen.

Sinnvoll wäre aber sicher eine Auflistung der default-Werte, z.B. auf der Wikiseite zu den Barrieren.

Grüße

Das macht die Sache mit den default-Werten so schwierig… Jeder hat eigene Erfahrungen und hält andere Dinge für logisch. Ich finde, barrier=lift_gate kann in der Regel nie durchfahren werden, ausser man arbeitet beim Forstamt und hat den Schlüssel.