Also selbst ein access=private (am linken der beiden Tore) stört OSRM hier nicht.
Um Bordsteine hingegen macht er einen ganz großen Bogen. Ich versteh’s net. 
Siehe auch : Note: 2956687 | OpenStreetMap
Guten Rutsch allerseits !!
Das ist halt wieder das ätzende “Wir machen mal irgendwas implizit” - OSRM im default car profile geht davon aus das diese barrier implizit für Autos durchfahrbar sind.
Deshalb bin ich ein freund davon ALLES nur noch explizit zu machen. barrier=* ist per default für keine modalität nutzbar solange nicht access tags es erlauben.
Ist aber ja hier nicht konsens. Also bleibt halt dieser schrott von so subtilen problemen zurück.
55 barrier_whitelist = Set {
56 'cattle_grid',
57 'border_control',
58 'toll_booth',
59 'sally_port',
60 'gate',
61 'lift_gate',
62 'no',
63 'entrance',
64 'height_restrictor',
65 'arch'
66 },
Und die auswertung:
356 if not profile.barrier_whitelist[barrier]
357 and not rising_bollard
358 and not flat_kerb
359 and not highway_crossing_kerb
360 or restricted_by_height then
361 result.barrier = true
362 end
Flo
Ich hab den Bug hier mal aufgemacht:
Und hier der commit mit dem ich jetzt laufe:
Flo
Bitte nicht! barrier=* sind in der Regel physikalische Barrieren und keine rechtlichen! Das unbrauchbare Chaos haben wir schon heute in der Datenbank. Die rechtliche Bedeutung (wie z.B. Privatweg mit Einschränkungen der Benutzbarkeit) sollte meiner Meinung nach an den way.
Von daher halte ich das Vorgehen von OSRM gar nicht so falsch.
1 Like
Das hat doch damit nichts zu tun ob das rechtlich oder physisch ist.
Die Frage bei einem gate, lift_gate, bollard, block ist immer - WAS geht da noch durch?
Und wir haben gerade in verschiedenen Endusern aka Routingengines unterschiedliche Annahmen darüber. Es ist halt maximal inkonsistent. Wie willst du das Lösung anders als es explizit zu machen?
Flo
Wieso gibt es denn unterschiedliche Auffassungen? Eigentlich sollte doch eine simple Tabelle ausreichen?
Ein barrier=bollard oder barrier=block ohne weitere Tags sollte sicher niemals ein foot=no oder bicycle=no bedeuten.
cycle_barrier impliziert auch foot=yes und bicycle=yes (oder meinetwegen bicycle=dismount)
cattle_grid ist (für mich) access=yes
gate, swing_gate oder lift_gate implizieren mMn access=no
Problematischer sind
barrier=debris oder barrier=chain oder barrier=log (kann man als Fußgänger wohl immer drüber oder drunter durch, soll man aber wohl meist nicht)
usw.
Wenn man sich auf eine solche Tabelle einigen kann, dann sollten Router sich auch dran halten.
Dazu auch relevant: ich hatte mir das Thema “fehlende” bzw nicht explizit getaggte access-Tag auf gates hier genauer angeschaut:
(Also da ging es konkret um die Frage, was nehmen Router eigentlich wirklich an, wenn kein Access-Tag auf dem Gate ist.)
Eben! Dafür gibt es z.B. maxwidth:physical. Oder locked=no/yes bei einem Tor.
Wer supported das? Ich spekuliere mal - Niemand.
Flo
Immerhin graphhopper scheint locked=yes auszuwerten: OpenStreetMap
locked ist bereits 67.000 mal in Verwendung.
OsmAnd unterstützt maxwidth:physical:
OsmAnd-resources/routing/routing.xml at master · osmandapp/OsmAnd-resources · GitHub