Barriere / Tor - Komoot, läßt Routing zu

Ein ähnliches Thema hatten wir schon im Sommer vorigen Jahres: Fahrradfahrer hatten ihr Lieblingsrouterprogramm bemüht und dieses führte sie über den Notweg des Hindenburgdammes. Ursache war, dass der Weg nicht mit den Access-Parametern wie “nicht zu Fuß” oder “nicht mit Rad” gestaltet war. Obgleich ja Tore vorn und hinten gemappt waren. Letzteres sollte doch ausreichen.

Das gleiche Problem habe ich nun wieder mit dem Eichenhof in Löpten (LDS). Auch dort ist eine Barriere ohne explizite Zugangs-Berechtigungen. Ich habe nun KOMOOT darauf aufmerksam gemacht. Wir mappen nicht für den Renderer, aber bei solch krassen Fehlern könnten wir diese ja schon aufmerksam machen.

Ich habe komoot schon 2014 das erste mal auf einen absurden Fall hingewiesen, wo statt der Autobahnbrücke ein paralleler Feldweg mit 2 verschlossenen Toren genommen wird, der den Autobahnzubringer kreuzt. Letztes (oder vorletztes?) Jahr habe ich sie nochmal daran erinnert, passiert ist aber nichts, außer dass die Bugreports nicht mehr öffentlich sind.
Ich finde das aus mehreren Gründen wirklich komisch, weil es zum einen nicht schwer zu fixen ist, kein eigenartiger Sonderfall, der das Routing wo anders verschlechtert, und eigenartigerweise aber auch das Routing von komoot im Allgemeinen trotzdem gar nicht so schlecht ist.
https://www.komoot.de/plan/tour/cCAgQAxoKCOKezg8QlvTmLRoHCOH5ARCOGQ/@48.0297575,16.3616037,15z

Na ja, wenn keine access-Tags angegeben sind, muss der Router halt raten ob das Tor immer dicht ist oder zB von Fußgängern geöffnet werden kann.

In OSM sind die Daten m.E. richtig, allerdings fehlt der access=no (private) an dem Wegstück zwischen den Toren.

@bestensee
Und ein gate eintragen ohne access=* sollte m.E. nicht sein. genau wie an anderen barrier=. Der way sollte auch die access= bekommen. Wir machen es doch auch bei Geschwindkeitsangaben und anderen “Verboten” an Straßen.

Das sehe ich ähnlich. Ein Tor ist ja dazu da, dass es geschlossen ist. Es kann natürlich auch offen sein und jedermann darf rein.
Gibt es nicht eine Möglichkeit, statt die Zugangsberechtigungen zusätzlich zu bemühen, dies direkt in das Popup-Menü für Barriere einzubauen. Immerhin ist in dem Menü für Barriere in JOSM auch die Möglichkeit Fahrrad / zu Fuß anzuklicken. Obwohl diese nicht angeklickt sind, sind diese frei routbar. Dann sind diese Menüpunkte in JOSM irreführend, so wie es jetzt ist. Es wäre schön wenn das konkretisiert werden könnte.

Es gibt zwar default-Werte, aber das sind eher Empfehlungen. Wenn die konkreten Berechtigungen bekannt sind, würde ich die auch immer dran schreiben, dann herrscht Klarheit für alle.

Geschwindigkeitsbegrenzungen, Fahrverbote usw. gelten auf der gesamten Strecke ab dem Schild.
Absperrungen (ohne Schild) sind nur am jeweiligen Ort ein Hindernis. Wer durchkommt. z. B. weil er einen Schlüssel hat oder Eintritt bezahlt hat, darf sich dahinter frei bewegen bzw. muss sich den dort folgenden Regeln unterwerfen, da können ja auch wieder Schilder stehen oder weitere Hindernise folgen.

Bernhard

Wenn sie blau wird der Wert nicht gesetzt. Ist er weiß heißt es “no” - hat er einen Häckchen ist es “yes”.

@Bernhard
“Schlüssel hat oder Eintritt bezahlt hat, darf sich dahinter frei bewegen bzw. muss sich den dort folgenden Regeln unterwerfen, …”

Dann sollte der way die Berechtigung “privat” oder “customers” haben.

“access = private” eher nicht.
Andernfalls kann man nach der Barriere im Zoo, Park, Campingplatz, umzäunten Wohnviertel, Nationalpark, usw. nicht mehr routen.

Bernhard

Ich denke ein Router sollte um das verbotene Gebiet herumrouten. Sobald sich der Startpunkt im verbotenen Gebiet befindet sollte der Router vom Startpunkt aus routen. Sollte das Ziel im verbotenen Gebiet liegen sollte der Router rückfragen, ob man an das Ziel (für Berechtigte) oder an den Rand möchte (normale Person).

Ich kann Komoot verstehen, dass sie Tore und access=no ignorieren. Tore in der Natur oder am Waldrand dienen oft nur dazu Tiere zurückzuhalten. Und ab und zu finde ich (nach einem vor Ort Besuch) auch ein falsches access=no weil motor_vehicle=no gemeint war.

ja, ich glaube ich hatte mich dagegen entschieden, weil es mir zu sehr als Workaround erschien und mir keine anderen Router aufgefallen sind, die damit Probleme haben. Eine besonders originelle Variante ist mir jetzt gerade bei skobbler aufgefallen, wenn man das Ziel hinter das erste Tor auf den Autobahnzubringer legt: mit dem Auto durchbricht er das verschlossene Tor, mit dem Rad fährt er dagegen eine große Schleife über die Autobahn (wobei das Ziel natürlich für Radfahrer grundsätzlich nicht erreichbar sein sollte, deshalb dürfte er mich trotzdem nie auf die Autobahn leiten - der Weg mit dem gültigen Ziel hinter den 2 Toren passt dort dagegen wieder)
https://maps.skobbler.de/@48.0294328,16.3612416,18/route/edit-no/by-bike/48.0300875,16.3613677//48.0292839,16.3598549

Aber auch abgesehen von den verschlossenen Toren kann von komoot doch nicht ernsthaft das Queren eines Autobahnzubringers vorgeschlagen werden, noch dazu wo die Brücke darüber direkt daneben ist und man die Straße extra verlassen soll, um diese NICHT zu nehmen

Das Suizid-Routing-Profil habe ich noch gar nicht gefunden. :wink:

Da läuft beim Routing aber einiges schief.

Nach Antwort von Komoot wird barrier erst in einer weiteren Version ausgewertet.
Z.Z. werden Wege mit access=* berücksichtigt. Habe deshalb den track getrennt und mit access versehen.

Danke, in dem Fall ist es sicher gut argumentierbar, dass die paar Meter für alle, die das Tor nicht passieren dürfen, auch keinen Sinn ergeben. Der allgemeinen Aussage, dass ein gate immer auch zu entsprechenden Beschränkungen bei ways führen muss, möchte ich aber widersprechen. Es gibt durchaus bspw. bei eingezäunten Siedlungen öfter mal versperrte Hinter- oder Seiteneingänge, während der Vordereingang öffentlich zugänglich ist. Da kann also höchstens die Verbindung, wo das gate darauf steht, privat sein und nicht einmal das ist völlig korrekt, wenn nicht zusätzlich ein Verbotsschild herumsteht.

Aus meiner Sicht sind barriers in der Regel physikalische Hindernisse, die das Können beschränken,
während access in der Regel vereinbarte Beschränkungen sind, die das Dürfen beschränken.

Bernhard

Die bisherigen Antworten befriedigen mein Problem nicht. Vielleicht ist das hier auch an der falschen Stelle und ich sollte das P. woanders hin posten.
Mal ein ganz einfaches Beispiel: https://www.openstreetmap.org/#map=18/52.22811/13.64038&layers=N
Da haben wir den Wacholderweg zwischen Heideweg und Waldweg. In der Mitte ist eine Barriere. Im Unterschied zu den vorherigen Beispielen ist für den Wacholderweg aber von allen Seiten die Zufahrt erlaubt. Es wurde eben eine verschlossene Barriere errichtet - ist zwar lustig - Schilda lässt grüssen. Und wer nicht 1,50 Hochsprung bringt, läuft eben um’s Karree.
Nun mein Einwand, dass das Objekt Barriere auch Properties für den Zugang / Durchlass etc. benötigt.

Wer realisiert das?

Leider routet nicht nur Komoot sondern auch ORS durch die Barriere hindurch - ist also kein alleiniges Komoot-Problem.
Als Übergangslösung, damit dann weiterhin wie gehabt geroutet werden kann, sollten die schon gemappten Barrieren auch volle Durchgangsrechte bekommen. Das kann man ja bei Notwendigkeit noch editieren. Route in ORS: https://maps.openrouteservice.org/directions?n1=52.228082&n2=13.640658&n3=17&a=52.228641,13.640456,52.227497,13.640842&b=0&c=0&k1=en-US&k2=km

https://www.openstreetmap.org/directions?engine=graphhopper_car&route=52.22867%2C13.64042%3B52.22754%2C13.64076#map=18/52.22818/13.63914&layers=N

macht es doch richtig. Komoot will in der nächsten Version barrier mit access berücksichtigen.

okay, Danke.

Also liegt es dann doch an den Renderern. GraphHopper macht es richtig. KOMOOT zieht nach und OSRM muss dann noch dran arbeiten.
Irgendwann könnte dann noch die Option der Öffnungszeiten und Zugangsberechtigungen kommen. Dann müsste dann auch die Routenplanung auf eine bestimmte Zeit vorgenommen werden. Das macht es nicht einfacher …

So wie es GraphHopper macht, ist aber auf der sicheren Seite, dann kommt man als Wanderer / Radfahrer nicht erst in die Bredouille.