Baustelle/Sperrung

Das ist aber auch die einzige Anwendung, die sowas in Echtzeit umsetzt :slight_smile:

Dann kann es bei Apps wie Magic Earth mit unregelmäßigen Updates 3-4 mal im Jahr halt passieren, dass die Daten einen Tag vor deiner Löschung gezogen werden, zwei Wochen später in einem Kartenupdate überhaupt erst in die App reinkommen und dann vier Monate drin bleiben. Die Auswertung von :conditional ist da noch sehr in den Kinderschuhen, vorsichtig ausgedrückt.

Deshalb ist es AFAIK Konsens, keine temporären Sachen zu mappen, die kürzer als 6 Monate gelten. Schadet mehr als es nützt.

Wenn eine Conditional restrictions ein Enddatum hat, ist dieser Eintrag nach dem Enddatum opsolet und sollte ohne Probleme gelöscht werden können. Das könnte sogar automatisch passieren. Beim BOT wäre nur das Problem, dass einige wenige Mapper den Grund der Conditional restrictions in einer NOTE oder ähnlichem beschreiben. Damit würde der BOT wohl Probleme haben.

Ich dachte bisher, wir mappen nicht für Anwendungen, sondern dass, was da ist (OTG) und Sinn macht. Für mich macht es Sinn eine Straßensperrung, und wenn sie noch so kurz ist, zu mappen. Woher soll ich wissen, ob es irgendeine Anwendung gibt, die mit bestimmten TAGS von OSM nicht klar kommt.

Conditional restrictions gibt es schon seit 2019. In 3 Jahren sollten alle Anwendung einen TAG nutzen, wenn er für diese Anwendung Sinn macht oder ignorieren. Und wenn eine Anwendung nur alle 6 Monate einen Datenabgleich macht, sollte diese Anwendung den TAG Conditional restrictions halt nicht verwenden.

Finde ich nicht richtig. Wer hat nicht schon einmal erlebt, dass die zugesagte Bauzeit verlängert wurde?
Zumindest meine Erfahrung hat gezeigt, dass das Ende einer Baustelle / Sperre nicht unbedingt mit dem Enddatum der Conditional Restriction übereinstimmt.
Respektive kommt man um eine kurze Internetrecherche in Richtung “A81 Baustelle Kreuz Hegau” und kurze Prüfung der Medien zu einer Baustellenfreigabe nicht immer herum. Ein Bot könnte diese Prüfung (noch) nicht übernehmen. Teilweise reicht auch ein kurzer Check auf der offiziellen Baustellen-Webseite des Landes, ob die Baustelle noch vorhanden ist.
Meine in Beitrag #p871937 verlinkte Overpass Abfrage berücksichtigt nur Einträge aus 2021 und hat damit etwas weniger false-positives, aber eben nicht immer.

Doch, gerade dann sollte eine Anwendung (mMn) diese Informationen nutzen. Und ich finde Conditional Restrictions äußert wertvoll. Mein festinstalliertes Autonavi bekommt nur alle 6 Monate neue Karten. Wenn eine, nur für ein paar Wochen, gesperrte Straße nur mit “access=no” gesperrt wird, habe ich diese Sperre 6 Monate lang in meinem Navi. Hab ich so in meinem Nachbarort drin, mein Navi schickt mich immer um den Ort herum.
Eine Conditional Restriction für die Zeit, gibt den Verkehr für die auswertende Anwendung dann wieder frei, wenn das Datum zu Ende ist. Unabhängig davon wie alt die Daten sind.

Leider nutzen den Tag noch äußert wenige Anwendungen. Ich habe noch keinen großen Vergleichstest gemacht, aber aktuell ist mir nur OsmAnd bekannt, der die :conditional-Tag teilweise beachtet. Siehe https://github.com/osmandapp/OsmAnd/pull/7302
BRouter bspw. kann es noch nicht, siehe https://github.com/abrensch/brouter/issues/193

Das ist jetzt Äpfel mit Birnen vergleichen, oder ähnlichem :confused:
Ein Objekt, welches eine definiertes Ende hat, verliert datentechnisch zu diesem Endzeitpunkt immer seine Gültigkeit. Daher ist es auch egal ob dieses Objekt weiterhin im Datensatz vorhanden ist oder nicht. Das Objekt löschen dient doch nur der Übersichtlichkeit für den menschlichen Datennutzer. Wenn die reale Beschränkung kürzer oder länger ist muss dieses händisch im Objekt angepasst werden.

Verstehe ich das richtig, dass Dein Navi die “Conditional Restriction” auswertet, und nach dem Gültigkeitsverlust des entsprechenden Datenelements keine Sperrung mehr anzeigt? Wenn ja, gibt es für Dich mit diesem Gerät doch keine Probleme. Oder?

Ja leider, aber wenn die Entwickler einer Routingsoftware in 3 Jahren keine Umsetzung hinbekommen haben, wird diese Anwendung nicht mehr richtig gepflegt. “OSMAND” ist doch das beste Beispiel, dass es funktioniert. Ich habe gestern die Sperrung der Landstraße eingetragen und heute wird der Nutzer anders geführt. Leider über einen Feldweg. :sunglasses: Später mehr.
Und Software ohne Routing muss nach 3 Jahren auch damit umgehen können.
Ich weiß, dass die meisten Anwendungen Open Source sind. Aber wenn die Software gepflegt wird, hat wenigstens das ordnungsgemäße Ignorieren Priorität.

Vollkommen richtig, ich meinte nur, dass nochmals ein menschlicher Blick nicht schaden kann, falls die Baustelle weiterhin besteht und die Zeitspanne im conditional verlängert wird.

Wäre die Sperrung im Nachbarort mit einer Conditional-Restriction angelegt worden, gäbe es tatsächlich kein Problem. Aber wie bereits geschrieben, wurde dort damals “access=no” (ohne conditional) verwendet und das hängt nach wie vor in meinen aktuellen Daten. Das nächste Update gibt es erst gegen Weihnachten wieder.

Ich könnte mir vorstellen, dass es eine Sache der Priorität ist. Wir haben Stand heute knapp 228 Millionen highway’s in der Datenbank, wovon momentan “nur” 65.021 einen *:conditional-Tag haben der für KFZ relevant ist (access, vehicle und motor_vehicle).
Daneben gibt es über 300.000 highway=construction, welches kein Enddatum hat.
Kurzum: Ich behaupte, wenn die Nutzung von *:conditional steigt, steigt auch die Priorität bei den Entwicklern von Routing-Software.

Das mit dem Feldweg ist sehr unschön, da er mitten über einen Bauernhof führt. Da er aber nicht als für Fahrzeuge als gesperrt gemappt ist, macht OSMAND eigentlich nichts falsch.

Mein und wohl auch OSMANDs Problem ist aber, dass die, auch offiziell als Umleitung ausgewiese Route im Datensatz mit einem Poller für mehrspurige Fahrzeuge blockiert ist. Der Versuch in JOSM es

barrier=bollard
barrier:conditional=no @ (2022 Aug 11-2022 Dec 20)

zu mappen, ergab die Fehlermeldung Falsche Syntax in barrier:conditional-Schlüssel (1)
Auch würde ich jede Wette eingehen, dass damit auch JOSM nicht umgehen kann.
Wie sorge ich nun dafür, dass OSMAND diese Straße als nutzbar ansieht? Vermutlich muss der Poller für diese Zeit im Datensatz entfernt werden. :frowning: :confused: :roll_eyes:

Wäre hier nicht ebenfalls access:conditional der richtige Weg? Aber eben mit yes und nicht no.

@mcliquid

vehicle:conditional @ no … funktioniert bei Osmand nicht. access:conditional @ no … allerdings schon als Sperrung

Ja barrier:conditional gibt es bisher gar nicht, bzw. nur zwei Mal insgesamt. Das gehört aktuell bei keinem Router zu “access”-Tags.

Ja, aber dafür müsste die barrier=bollard weg, da diese motor_vehicle=no impliziert.

Könntest du den entsprechenden Way mal zeigen?

Was ich im OsmAnd Code gefunden habe, funktioniert access:conditional und motor_vehicle:conditional auf jeden Fall. Zumindest wenn die Syntax im value stimmt.
vehicle:conditional wurde bisher nur im Kontext bicycle-routing erwähnt. Du könntest es mal mit dem Fahrrad-Profil versuchen.
Vielleicht wird vehicle:conditional nur beim Fahrrad berücksichtigt aber nicht beim Auto. Das wäre ein Ticket bei OsmAnd wert.

@mcliquid

ich glaube das war hier der nördliche Teil vom Birkenweg https://www.openstreetmap.org/edit#map=19/47.86271/12.35867 , den habe ich wieder auf access:conditional geändert. Bis die LiveUpdates bei Osmand umgesetzt werden, dauert es manchmal mehr als einen Tag

Ich habe gestern den Poller beseitigt. Habe das Ganze in meinen Kalender eingetragen, damit das Ding am Ende der Sperrzeit wieder da hin kommt.
OSMAND hat heute den Weg über diese Straße korrekt geroutet. :smiley:

Ich bin ja schon lange der Meinung, daß es eine spezielle, auf Baustellen jeglicher Art ausgerichtete Karte geben sollte. Ich selbst fühle mich programiertechnisch nicht dazu in der Lage, ich sehe aber immer wieder, das Baustellen, oder so eingetragen werden, und ich die Befürchtung habe, daß sich dann lange keiner mehr drum kümmert mit all den (Routing)-Folgen… :frowning:

Sven.