Baustelle/Sperrung

citro wrote:

Habe ich das richtig eingetragen ?

Die Monate sollten nur mit drei Buchstaben angegeben werden, aber das wurde gerade bereits korrigiert.
Aus meiner Sicht stimmt die Angabe (zumindest nach der Änderung). Ob die Router das so überhaupt interpretieren bleibt offen.

Ich habe vor einer Woche eine Sperre eingetragen. Der einzige Router der diese aktuell berücksichtigt ist der BRouter. Deine Route jedoch noch nicht. Eventuell dauert es ein wenig, bis auch der BRouter die Daten erhält und diese verarbeitet.

@mcliquid

Vielen Dank, ein anderer User hat sich dort schon gemeldet und korrigiert.

Da hätte ich noch die Frage: wie trägt man das genau ein, wenn nur eine Fahrtrichtung gesperrt ist ?

citro wrote:

Da hätte ich noch die Frage: wie trägt man das genau ein, wenn nur eine Fahrtrichtung gesperrt ist ?

Laut Wiki wird einfach noch ein "forward" oder "backward" dazwischen eingesetzt. Also in deinem Fall:
access:forward:conditional = no @ (2022 Aug 11-2022 Sep 30)

Siehe im Wiki: https://wiki.openstreetmap.org/wiki/Con … #Direction
Scheint aber nicht allzu oft verwendet zu werden: https://taginfo.openstreetmap.org/keys/ … l#overview

Übrigens: Wenn sich die Sperre nur auf den KFZ-Bereich erstreckt und zumindest Fußgänger passieren können, dann würde sich statt dem allgemeinen "access" auch ein "motor_vehicle" oder "vehicle" (inkl. Fahrrad) besser anbieten.

mcliquid wrote:

citro wrote:

Da hätte ich noch die Frage: wie trägt man das genau ein, wenn nur eine Fahrtrichtung gesperrt ist ?

Laut Wiki wird einfach noch ein "forward" oder "backward" dazwischen eingesetzt. Also in deinem Fall:
access:forward:conditional = no @ (2022 Aug 11-2022 Sep 30)

Übrigens: Wenn sich die Sperre nur auf den KFZ-Bereich erstreckt und zumindest Fußgänger passieren können, dann würde sich statt dem allgemeinen "access" auch ein "motor_vehicle" oder "vehicle" (inkl. Fahrrad) besser anbieten.

heißt dann das zB: vehicle:conditional no @ (2022 Aug 11-2022 Sep 30) ?
Könnte das Osmand als Sperrung erkennen ?

Danke

citro wrote:

heißt dann das zB: vehicle:conditional  no @ (2022 Aug 11-2022 Sep 30)  ?

Das wäre dann für alle Fahrzeuge (inkl. Fahrrad, Mofa, etc.) und von der Syntax her korrekt. Es fehlt das =-Zeichen, aber ich denke das kommt vom kopieren.

citro wrote:

Könnte das Osmand als Sperrung erkennen ?

Laut diesem GitHub Kommentar sollte OsmAnd damit umgehen können: https://github.com/osmandapp/Osmand/iss … -640900734
Bei meiner Sperre (vor einer Woche eingetragen) wird dies jedoch noch nicht berücksichtigt. Leider ist in GitHub kein Pull Request verlinkt um zu prüfen ob das wirklich implementiert wurde bzw. wie.

@mcliquid

das = Zeichen ist aber in der Eingabemaske bei OSM sonst nirgends drin, wahrscheinlich nur hier als Beschreibung hinzugefügt ?

citro wrote:

das = Zeichen ist aber in der Eingabemaske bei OSM sonst nirgends drin, wahrscheinlich nur hier als  Beschreibung hinzugefügt ?

Das kommt auf deinen Editor drauf an. Um einen Text korrekt beispielsweise in JOSM einzufügen als Tagging, benötigt es das =-Zeichen als Trennung.

citro wrote:

Eingabemaske bei OSM

Das ist der integrierte Editor iD, der besonders auf Anfänger zugeschnitten ist, einfacher in der Handhabung, aber inzwichen auch zunehmend leistungsfähiger.

citro wrote:

das = Zeichen ist aber in der Eingabemaske bei OSM sonst nirgends drin

in der Standardeinstellung siehst Du unter Eigenschaften eine tabellarische Darstellung ohne =. Hinter "Eigenschaften" befinden sich zwei Buttons, dort kann man von Tabelle auch zu Text umschalten, und da steht dann auch das = drin. Mit = wird es m. E. in der Syntax der Datenbank gespeichert.

Vielen Dank für Eure Mühe

Mammi71 wrote:

Mit = wird es m. E. in der Syntax der Datenbank gespeichert.

Etwas OT, nur zur Info: Ziemlich sicher nicht.
Das vor dem "=" ist im DB-Sprech der Schlüssel/key, das danach der Wert/value. Nur die werden gespeichert.
Das "=" wird vom Anzeigeprogramm je nachdem hinzugefügt.

Umgekehrt wird aus Eingabemasken das Paar Schlüssel/Wert per "=" bestimmt, wenn so vorgesehen. Das ist aber nicht der Fall, wenn nur Schlüssel oder Wert allein erwartet werden.

Hallo, kleiner Nachtrag.
Die o.g. Sperrung funktioniert jetzt mit OsmAnd im Routing

Nochmal eine Rückmeldung:

Eine einseitige Sperrung der Franziska-Hager-Straße beim Lidl-Parkplatz nimmt Osmand nicht an (im integrierten Editor)

https://www.openstreetmap.org/edit#map= … 3/12.34829

vehicle:backward:conditional no @ (22:00 Aug 11-2022 Sep 30)

Vielleicht habe was falsch gemacht

access:forward etc. sehe ich nicht erwähnt im github, wohl aber oneway:conditional.
Statt 22:00 meinst du vermutlich 2022.

chris66 wrote:

access:forward etc. sehe ich nicht erwähnt im github, wohl aber oneway:conditional.
Statt 22:00 meinst du vermutlich 2022.

Oh, Danke für's drüberschauen, ist geändert.

oneway:conditional würde hier gehen ? Die Richtung müsste ich noch auch miteinbringen (?)

PS: vehicle:conditional bei einer anderenSperre wird bei Osmand auch nicht erkannt

Da ich das Problem aktuell auch habe, tauchte bei mir die Frage auf:

Kann man in diesem Zusammenhang auch die eingerichtete Umleitungsstrecke erfassen? Und wenn ja, wie?
Im aktuellen Fall wird eine für den Autoverkehr durch einen Poller gesperrte Straße für die Zeit der Sperrung genutzt.

Wetterauer wrote:

eingerichtete Umleitungsstrecke erfassen

Ich denke, da muss man als Verkehrsteilnehmer einfach mal den Schildern folgen. Es kann nicht alles in OSM abgebildet werden.

Selbst eingetragene Sperrungen für ca. 1,5 Monate, wie oben erwähnt, werden in den allermeisten Fällen kaum jemals einen Endnutzer erreichen, da die Updateintervalle vieler Endprodukte zu lang sind. Und leider hängen am Ende die hinzugefügten Tags noch jahrelang an den Wegabschnitten, da sich die meisten Mapper nie mehr um "ihre" Baustellen kümmern.

highflyer74 wrote:

Und leider hängen am Ende die hinzugefügten Tags noch jahrelang an den Wegabschnitten, da sich die meisten Mapper nie mehr um "ihre" Baustellen kümmern.

Man kann immer mal wieder hier reinschauen und aufräumen: https://overpass-turbo.eu/s/1lT1
Daraus könnte man auch eine MapRoulette Challenge machen. In meiner Umgebung achte ich da immer sehr drauf, dass die alten Einträge raus kommen, aber ich finde da braucht es teilweise Ortskenntnis oder sehr viel Recherchearbeit, ob die Baustelle wirklich schon vorbei ist.

@mcliquid

Wenn man eine Straße sperrt und der User hat Live Updates zb mit Osmand wir ja automatisch umgeleitet.
Die Sperren die ich eingetragen habe sind auch zeitlich begrenzt. Ich werde sie auch später wieder löschen

citro wrote:

Wenn man eine Straße sperrt und der User hat Live Updates zb mit Osmand wir ja automatisch umgeleitet.

Die Umleitung die ein Router automatisch berechnet muss ja nicht unbedingt mit der ausgeschilderten Umleitung übereinstimmen.

citro wrote:

Wenn man eine Straße sperrt und der User hat Live Updates zb mit Osmand wir ja automatisch umgeleitet.

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

citro wrote:

Die Sperren die ich eingetragen habe sind auch zeitlich begrenzt. Ich werde sie auch später wieder löschen

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.

mcliquid wrote:

Daraus könnte man auch eine MapRoulette Challenge machen. In meiner Umgebung achte ich da immer sehr drauf, dass die alten Einträge raus kommen, aber ich finde da braucht es teilweise Ortskenntnis oder sehr viel Recherchearbeit, ob die Baustelle wirklich schon vorbei ist.

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.

FraukeLeo wrote:

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.

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.

Wetterauer wrote:

Das könnte sogar automatisch passieren.

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.

Wetterauer wrote:

Und wenn eine Anwendung nur alle 6 Monate einen Datenabgleich macht, sollte diese Anwendung den TAG Conditional restrictions halt nicht verwenden.

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.

Wetterauer wrote:

In 3 Jahren sollten alle Anwendung einen TAG nutzen, wenn er für diese Anwendung Sinn macht oder ignorieren.

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

mcliquid wrote:

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.

Das ist jetzt Äpfel mit Birnen vergleichen, oder ähnlichem 🤔
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.

mcliquid wrote:

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.

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?

mcliquid wrote:

Leider nutzen den Tag noch äußert wenige Anwendungen.

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. 😎 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.

Wetterauer wrote:

Ein Objekt, welches eine definiertes Ende hat, verliert datentechnisch zu diesem Endzeitpunkt immer seine Gültigkeit.

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.

Wetterauer wrote:

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?

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.

Wetterauer wrote:

Ja leider, aber wenn die Entwickler einer Routingsoftware in 3 Jahren keine Umsetzung hinbekommen haben, wird diese Anwendung nicht mehr richtig gepflegt.

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.

Wetterauer wrote:

Ich habe gestern die Sperrung der Landstraße eingetragen und heute wird der Nutzer anders geführt. Leider über einen Feldweg. 😎 Später mehr

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. 🙁 🤔 🙄

Wetterauer wrote:

Wie sorge ich nun dafür, dass OSMAND diese Straße als nutzbar ansieht?

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

Wetterauer wrote:

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)

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

Robert46798 wrote:

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

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

citro wrote:

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

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= … 1/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. 😄

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... 🙁

Sven.