Ich würde das nicht von dem Zeitraum abhängig machen (einer will täglich aktualisieren, ein anderer macht es nur jährlich…) sondern davon, wie sehr das Ergebnis vom vorherigen Zustand abweicht: Wenn es nach den Bauarbeiten ganz anders aussehen wird (die vorherigen Daten also auch nicht nützlich wären) kann man es als highway=construction eintragen. Sonst als temporary:= – Wenn eine Anwendung es auswerten will kann sie es, und so schlimm ist in diesen Fällen ein fehlender Baustellen-Hinweis auch nicht.
Das Erkennen, dass es sich um eine temporäre Sperrung handelt, ist erstmal das wichtigste.
Bei meiner Garmin Karte nehme ich, falls die Baustelle innerhalb z.B. des nächsten Monats zuende geht, das access=no
raus bzw. bei hw=construction setze highway auf den construction-Wert.
Wertet das Temporary jemand aus,
oder OFF Topic, wie sieht der aktuelle Proposalprozess aus ?
Ordentlich im Propsal Space abhängen lassen, bis der Einsatz der Technik > 500 Anwender hat ?
Die Abstimmerei hat doch schon nicht funktioniert (oder mich überzeugt) als ich gekommen bin.
Wer war das nur gleich, der eine gewisse Straßensperrung für Kfz als Baustelle partout eintragen musste und sich nachher nicht mehr drum gekümmert hat…?
Ich werte das in meiner Garminkarte aus, in dem ich die temporary-Tags bewusst ignoriere, da ich die Karte recht selten aktualisiere.
Wenn ich sie öfter aktualisieren würde, dann würde ich temporary:* einbauen.
In der Diskussion zu temporary scheint man in England gerade auch so ein aktuelles Problem zu haben. Vielleicht ist ja jetzt - im Gegensatz zu 2010, der Entstehungszeit des Proposals - die Zeit reif dafür. Da war wohl jemand seiner Zeit einfach voraus
Würde ich einen edit-war anzetteln, wenn ich diesen Weg entsprechend dem Proposal, ändere? Ich würde dann ggf. den Mapper zur Diskussion hier einladen (hab noch nichts gemacht)
a) Zum Edit War gehören immer zwei.
b) Anschreiben ist gut.
c) Hab ich in meinem Fall auch nicht gemacht
d) Dem note entnehme ich aber, das die Strasse gar nicht construction ist, sondern nur gesperrt. Daher muss da eh editiert werden.
Baustellen trage ich persönlich nur ein, wenn diese länger Dauern und ich jeden Tag vorbei komme.
Da es sich um diese Straße um eine Vollsperrung handelt und diese mindestens 2 Monate dauert hab ich es eingetragen.
Zudem herrscht wegen dieser Sperrung ein ziemliches Verkehrschaos.
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.
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
Habe das aber jetzt mal gelöscht!
Edit
wenn ich mal mehr Zeit habe muss ich mal im Forum fragen wie andere das reinpinseln.
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.
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…
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).
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.