5 Wochen Baustelle => Highway Construction oder nicht

Das hier http://www.general-anzeiger-bonn.de/bonn/themen/bruecken-chaos/Jetzt-kommt-doch-die-2-0-Loesung-article1261325.html dürfte auch eine Baustelle werden, die ich bestimmt eintragen würde.

Es ändern sich praktisch alle Bedingungen, maxspeed, lanes, maxweight…

Ansonsten halte ich es so, ich trage alle Baustellen ein, die eine nennenswerte Beeinflussung des Verkehrs erwarten lassen
oder es schon tun.
Zusätzlich tagge ich bei solchen, die ich nicht zeitnah zurücknehmen kann, ein FIXME oder note.
Ein Enddatum der Baustelle setze ich meist nicht, da das 1. auch auf den aufgestellten Plakaten meist nur monatsgenau
angegeben ist und 2. häufig nicht eingehalten wird, sowohl kürzer als auch länger ist vorgekommen.

Bernd

vielen dank für den Hinweis.
Da Baustellen nicht eingetragen werden, zumindest in Freiberg ni, sieht man die auch ni und können schon mal vergessen werden :sunglasses:

Habe das aber jetzt mal gelöscht!

  1. Edit
    wenn ich mal mehr Zeit habe muss ich mal im Forum fragen wie andere das reinpinseln.

Ich auch nicht - ich denke da sind wir uns einig :wink:

Damit der Großteil der typischen offline-Anwendungsfälle mit konsistenten Daten möglich ist, bedarf es 2 Informationen:
a) die “normalen” Tags (via z. B. construction=secondary recht häufig gut gelöst).
b) eine Zusatzinformation “construction ist nur vorübergehend”. Alternativ end_date bzw. start_date - wird leider recht oft weggelassen.

Also bräuchte es nur einer kleinen Zusatzinformation, so dass sich kurzzeitig gesperrte Straßen von echten Neubauten, an einem (definierten) Tag unterscheiden
temporary:= hätte - obwohl wenig abwärtskompatibel - weiter den Charme, dass es noch einen Schritt weiter richtung universell einsetzbar (nicht nur für Straßen) geht

Abwärtskompatibel ist es, wenn man annimmt, dass eine Anwendung im Normalfall den dauerhaften Zustand wissen möchte. Ein Schema, bei dem davon ausgegangen wird, dass eine Anwendung den jeweils aktuellen Zustand haben wollen würde, wäre nach der ersten Annahme nicht kompatibel zu Altanwendungen. Beides zusammen ist also nicht machbar.

Ich halte die erste Annahme für zutreffender: Wenn eine Anwendung das Schema ab einer Version unterstützt, ein Nutzer aber nicht auf diese neue Version aktualisiert hat, kann man wohl davon augehen, dass der Benutzer auch die Daten nicht sehr oft aktualisiert und darum einen dauerhaften Zustand als Datenbasis wünscht. Auch bei Auswertungen wie “wieviele Meter Stadtbahnstrecke gibt es im Landkreis Heilbronn” würde man vermutlich eine vorübergehende Stadtbahnstrecke nicht gezählt haben wollen, oder das explizit berücksichtigen.

Etwas Tuning ist aber noch erforderlich.

Beispiel:
Baustelle mit maxspeed 60 von januar bis july
Vollperrung vom 1.3 bis zum 20.3

Da hat temporary schon seine Grenzen, oder ?

Christoph

Ja, müsste es aber nicht haben. Die Beschränkung kommt von time_on/time_off etc. Solche Tags gab es ja auch jenseits des temporary-Taggings bereits. Dort haben wir erkannt, dass das nicht genügt, und daher Conditional Restrictions erfunden.

Das Problem ist einfach, dass das Proposal von 2010 ist, und noch nicht den offensichtlichen Schritt gegangen ist, die Syntax vom Conditional-Tagging für sein Thema aufzugreifen.

Okay, es ist wieder soweit. Die Baustelle ist wieder gesperrt, diesmal wegen Neubau. Siehe hier. Jetzt habe ich mich an das Conditional-Tagging gehalten. Die Bahnbrücke war bereits vorbildlich gemappt.

Jetzt schaun wer mal,
a) wer das als erstes richtig auswertet / rendert
b) ändert auf access=no, weil a) nicht eintritt

Nebenbei: bei access:conditional=no@(2014-10-14-2014-11-21) habe ich mich wörtlich an das Wiki gehalten; weiß jemand ob das richtig ist? Die vielen Bindestriche scheinen nicht gerade leicht auswertbar zu sein…

Grüße aus der Provinz

Hallo Yggdrasil,

Mir erscheint dieses Tagging nicht mit den Opening-Hours-Spezifikationen kompatibel zu sein, die für Zeitangaben bei Conditional Restrictions verwendet werden. Diese Schema sieht das Minuszeichen als Zeittrenner vor und kennt gar keine Jahresangaben. Es ist eigentlich für wiederkehrende Beschränkungen gedacht. Da aber ein Tag nur einmal jährlich vorkommt, kann man IMHO ruhig auf die Angabe des Jahres verzichten und daher access:conditional=no@(Oct 14 - Nov 21) taggen. Wer nach einem Jahr sein Navi noch nicht upgedatet hat, sollte am besten bei Teleatlas & Co. bleiben.

OT: Meinen Erfahrungen nach unterscheiden Teleatlas und Co. bei ihren Navidaten auch nicht nach dauerhaften Tempolimits und vorübergehenden Tempolimits auf Autobahnbaustellen. Da hört man auch des Öfteren “Bitte beachten Sie die Höchstgeschwindigkeit.”, obwohl die Baustelle schon mehrere Jahre zurückliegt (die Kartendaten wurden auch nie aktualisiert).

Viele Grüße

Michael

Gefährliches Unterfangen, da die Zeit der Beschränkung dann implizit das aktuelle Jahr ist, und wenn die Beschränkung abgelaufen ist, unklar ist ob sie für das Folgejahr gilt, oder abgelaufen ist.

BTW: Die Sperrung für die Haaner Kirmes ist jedes Jahr gleich (um den letzten Montag im September). Ich habe mir noch nicht die Arbeit gemacht, das als jährlich wiederkehrende Beschränkung einzutragen, denke aber, das der Use Case mit zunehmender Routerunterstützung kommen wird, und das nicht nur in Haan. Daher ist es schon gut, die Einmaligkeit einer Ausnahme durch Jahreszahl festzuhalten.