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.
Laut diesem GitHub Kommentar sollte OsmAnd damit umgehen können: https://github.com/osmandapp/Osmand/issues/1794#issuecomment-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.
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.
Das ist der integrierte Editor iD, der besonders auf Anfänger zugeschnitten ist, einfacher in der Handhabung, aber inzwichen auch zunehmend leistungsfähiger.
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
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=19/47.85613/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.
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.
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.
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.
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
Die Umleitung die ein Router automatisch berechnet muss ja nicht unbedingt mit der ausgeschilderten Umleitung übereinstimmen.
Das ist aber auch die einzige Anwendung, die sowas in Echtzeit umsetzt 
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 
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. 
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.