Bei Problemen mit Straßen, die innerhalb eines Monats gelöst werden, arbeite ich nur mit Hinweis-Notes. Ich ändere erst Änderungenen > 3 Monate. Das hängt aber auch etwas von der Wichtigkeit der Straßensperrung ab. Auch wenn man am Ball bleibt, kann die Sperrung, die nur 3 Wochen dauert, mehrere Monate auf verschiedenen Apps bestehen bleiben. Das möchte ich nicht riskieren. Solche kurzen Sperrungen haben (meißt) immer Umleitungen, mit denen man als Verkehrsteilnehmer immer rechnen muss.
Das ist dann aber ein Frage der APPS. Die Daten entsprechen der tatsächlichen Situation. (Ich mache das bei über einen Monat, da ein monatliches Update eines Routers schon mindestens Standart sein sollte.)
Wenn ein Router monatlich am 1. updatet und du eine Sperrung von 2. bis 2. zeitnah mappst, bleibt sie dennoch fast einen Monat zu lang in den Routerdaten ich bin auch eher für die Drei-Monats-Regel.
Ich hatte beide Versionen in meiner Liste im Rahmen des routine-mässigen brouter-suspect-scans, und die erste mit Quellenangabe und Zeitraum war vergleichsweise der pure Luxus. Sowas setze ich auf Wiedervorlage und schau’s mir in 4 Wochen nochmal an.
Ich bin zwar auch der Meinung, dass Edits bzgl. solcher kurzfristigen Phänomene eher schaden, aber jetzt in dem Fall sind ja genug Augen drauf und da passiert nichts, und so ganz blöd ist das ja auch nicht, eine Ampel-Baustelle zu umfahren.
Also einfach bisschen relaxter da rangehen, denn es gibt genug andere wirkliche Probleme im Strassennetz.
Deine Drei-Monats-Sperre bleibt ja dann ebenfalls fast einen Monat zu lang in den Daten.
Da das in jedem überlappenden Update/Ende-Fall gilt - egal wie lange die Sperrung vorher dauerte -, sehe ich da keinen großen Unterschied.
Es hängt immer am Zeitpunkt und Intervall des Auswerters, wie aktuell die Daten nunmal sind.
Danach dürfte man nur mit *:conditional arbeiten - dann umgeht man diese Tücke, hat aber trotzdem richtige Daten.
Die Sperrung wurde durch den Verursacher - fehlerhaft - aufgehoben.
Ich habe heute noch per Revert den kompletten ursprünglichen Zustand wieder hergestellt.
Das ist richtig, aber der Eintrag wäre im verzögerten Router dann wenigstens zwei Monate lang korrekt, während deiner maximal zwei Tage korrekt wäre (z.B. am 2.5. eingetragen, am 1.6. Kartenupdate → Baustelle im Router, am 2.6. Baustelle beendet und in OSM weggenommen, bis 30.6. Baustelle noch im Router). Da ist bei mir der Richtigkeitsanteil etwas höher, obwohl der absolute Versatz gleich ist.
Wie ich woanders schon mal angedeutet habe, fände ich es generell sinnvoll, solche Informationen komplett Diensten wie HD-Traffic (oder meinetwegen auch einer separaten freien Datenbank, die online abgefragt werden kann) zu überlassen und in der OSM-Datenbank überhaupt nicht zu erfassen. Dann hat der Router mit OSM die grundsätzlichen Geodaten (hohes Datenvolumen) lokal gespeichert und bekommt die aktuellen Nutzbarkeitsdaten dazu (kleines Datenvolumen) übers Netz in Echtzeit. Eine bessere Lösung kann ich mir kaum vorstellen.
ich sehe es auch so, würde das zwar eher nicht eintragen weil sehr kurz, finde es aber nicht falsch, und solange ich das Gefühl habe, das wird dann auch wieder freigegeben sobald es in der Realität befahrbar ist, dann würde ich es tolerieren.
Zur Info: Ich bin heute (13.8.) Nachmittag da durchgefahren: auf ca. 200m einspurig mit Ampelregelung, allenfalls kurze Wartezeit.
Lt. Beschilderung “Belagsarbeiten mit Vollsperrung von Mo 20.8. bis Fr 7.9.”.
Dermaßen kurze Zeiträume sollten mMn nicht in der Karte eingetragen werden, zumal es eine ausgeschilderte örtliche Umleitung gibt.
ich bin auch eher für die Drei-Monats-Regel.