Hallo,
sorry, für die späte Antwort.
Ich bin derjenige, der das Thema damals in RadioOSM angesprochen hat. Ich bin regelmäßig in Karlsruhe und das ist, wie die Teilnehmer der SotM-EU selbst erfahren konnten, EINE Baustelle. Täglich oder wöchentlich ändern sich Verkehrsführungen, oneways werden zu twoways und wieder oneways, Sperrung tauchen auf und verschwinden. Ich fahre meist Fahrrad, aber auf Arbeit mit dem Auto …
Warum eine temporary-Schema? Wir haben doch schon highway=construction!
Ich finde es nicht richtig, das mit construction zu taggen. Die Verwendung von construction ist ein IMHO sehr Mapnik-zentriertes Mappen (wir schimpfen das an anderer Stelle auch als “Mappen für den Renderer”), richtig? Die Karte auf osm.org wird sehr schnell aktualisiert und da ist die Verlockung groß, dass sie aktueller als alle anderen Karten ist. Leidtragende sind die Nutzer, die aufgrund von mangelnden Ressourcen (schwacher Server) oder aufgrund physischer Unmöglichkeiten nicht dauern bzw. häufig Datenupdates holen wollen.
Beispiel 1: Was für einen Eindruck macht es Nutzern gegenüber, die OSM-Daten offline in Navis oder Navi-Apps verwenden? Als OsmAnd-Nutzer bin ich Teil dieser Gruppe. Die ideale App 
, bekommt schon ein paar Tage im Voraus beim letzten Daten-Update gesagt und versteht: “Hey, die Kreuzung am Etllinger Tor kannst du mit dem Fahrrad ab 16.7. (fiktives Datum, halbfiktive Sperrung) nicht überqueren, bis 15.7. aber schon.” Wenn alle die temporären Änderungen nur als construction in Beinahe-Echtzeit eintragen, dann bekomme ich alle Infos verspätet. Die Sperrung dauert bei mir dann länger als real. Das muss nicht sein.
Beispiel 2: Letzten Sommer habe ich auf Arbeit für einen Kunden eine Papierkarte (bunter Hintergrund für einen Übersichtsplan) gerendert. Dass die Gegend nicht so supertoll gemappt war, war nicht so schlimm. Aber gestört hat, dass eine Autobahnanschlussstelle als Baustelle eingetragen war. Die Karte wird beim Kunden jahrelang verwendet werden. Die Baustelle dauert aber höchstens Monate. Ich kann dem Kunden/Chef halt schlecht sagen, das ist OSM, ist halt so. Dann zeigt der an die Wand und sagt, da die Karte von $Propietärverlag macht’s aber … Daher habe ich als einer der ersten Schritte schon meinen lokalen Extrakt in JOSM gedrückt (30 x 12 km ländlicher Raum) und dort korrigiert.
Beispiel 3: Nach dem Elbehochwasser im Juni 2013 (Deichbruch von Fischbeck) war die B 107 zwischen Jerichow und Havelberg und die B 188 zwischen Tangermünde und Landesgrenze zu Brandenburg für den Durchgangs- und Güterverkehr gesperrt. Die Straßen haben eine überörtliche Bedeutung, die Sperrung hat mehrere Wochen angedauert. (Es gab eine täglich aktualisierte Sperrliste auf der Website der Kreisverwaltung) In der ganzen Gegend waren auch noch weitere Landes-, Kreiss- und Ortsverbindungsstraßen bis zu zwei Monate lang gesperrt. Hier wäre eine gute Verwendung für das temporary-Schema gewesen.
Wenn ich bei einer Baustelle das zeitliche Ende weiß, dann könnte ich ja mit Conditional Restrictions arbeiten. Ja, ich könnte. Aber mir fehlt da die Unterscheidung zwischen regelmäßigen, dauerhaften (also wiederkehrenden) Einschränkungen (z.B. jeden Sommer Temp 60, im Winter Tempo 100) und einmaligen, aber maschinenlesbar beschreibbaren Einschränkungen (diesen Sommer Tempo 60).
Was ermöglicht das Schema?
Wie Jan schon angedeutet hat, könnte man RSS-Feeds (oder auch andere Dienste) bauen, die einem Baustellenankündigungen zur Verfügung stellen. Es wären Websites/Dienste/Apps möglich, die nach Eingabe eines Tags die gesperrten Straßen anzeigen oder auflisten. Ich glaube, dass die bestimmt schöner und benutzerfreundlicher werden als manche grausige städtische Website (es mag schöne geben, aber ich denke bei Ämtern irgendwie immer an langsame WMS-Dienste in Websites …).
Herstelle gedruckter Karten, könnte ohne ihre Daten zu patchen, langzeitgültige Karten vertreiben. Navi-Nutzer bräuchten nicht wöchentlich upzudaten, wenn die Mapper schon zwei Wochen vorher das Amtsblatt in OSM übetragen würden …
** Wo liegen die Schwächen? Was sind die Hürden für Datennutzer?**
Kompliziert stelle ich mir das Rendering vor. Entweder man macht es als Overlay und fragt dafür die Overpass-API (oder soetwas in der Art) ab oder man muss täglich/wöchentlich neue Tiles rendern. Letzteres ist ressourcenfressend.
** Wie stelle ich mir das Taggingschema vor?**
Aus dem Jahr 2010 gibt es ein, mittlerweile eingeschlafenes, Proposal dafür. Ich persönlich würde es nicht so 1:1 übernehmen. Die Zeit ist fortgeschritten und wir haben mit den Conditional Restrictions ein Schema, das deutlich besser ist als ein auf date_on=* und date_off=* basierendes Schema. date_on und date_off haben den Nachteil, dass man nicht weiß, wofür das “date” gilt. Das haben wir spätestens dann, wenn zwei unterschiedliche temporäre Änderungen in OSM am selben Way getaggt werden wollen. (z.B. ab 17. Juli maximal 12 Tonnen und ab 30. Juli maximal 3,5 m Durchfahrtshöhe)
Im folgenden meine korrigierten Beispiele von der Wikiseite:
Beispiel 1 – vorübergehende Geschwindigkeitsbeschränkung
Ich schlage ich vor: temporary:maxspeed=50 @ (2010 Dec 01 - 2010 Dec 15)
Beispiel 2 – Sperrung wegen einer Demonstration
Ich würde es eigentlich gar nicht taggen, da es nur einen Tag lang gilt. Trotzdem sähe mein Taggingschema vor:
highway=tertiary
temporary:access=no @ (2011 May 01 08:00 - 2011 May 01 14:00)
temporary:foot=yes @ (2011 May 01 08:00 - 2011 May 01 14:00)
**Beispiel 3 – Austellungspavillion mit vorübergehend anderem Namen **
Ich glaube es wäre besser, das Schema auf Wege aller Art (highway, waterway, railway, Flugplätze) zu beschränken, sonst bekommen wir bald diverse Festival-Gelände in OSM, trotzdem mal mein Vorschlag:
building=yes
name=Pavilion 5
temporary:name=Security Area @ (2010 Oct 25 - 2010 Oct 30)
Beispiel 4 – Behelfsbrücke:
Eine Brücke wird abgerissen und neu gebaut. Währenddessen läuft der Verkehr über eine parallele Behelfsbrücke.
Alte Brücke:
highway=motorway
temporary:access=no @ (2011 Apr 01 - 2011 Sep 01)
Behelfsbrücke:
temporary:highway=motorway @ (2011 Apr 01 - 2011 Sep 01)
Anlehnung ans opening_hours-Schema
Mit meiner Notation habe ich mich ans opening_hours-Schema (OHS) angelehnt, soweit es ging. Es wird nämlich auch bei den Conditional Restrictions verwendet. Das Schema sieht, soweit ich weiß, keine Jahreszahlen vor. Ein Datum wird dort in der Form “May 5” für 5. Mai angegeben. Ich möchte eigentlich mich so wenig wie möglich vo OHS entfernen, damit die Auswertung einfach bleibt (eine Bibliothek für beide Schemata bzw. temporary als abwärtskompatible Ergänzung der OHS-Sprache).
Ein wohl typischer Fehler, den englische User (und zu weit vorausdenkende Deutsche) machen werden, wird das Kommata im Datum sein. Im Englischen wird teilweise May 5, 2014 für 5. Mai 2014 verwendet. Um das zu verhindern, müsste man die Sprache umbauen. Den Bindestrich durch “to” ersetzen und Datumsspannen als “2014-05-09 to 2014-09-15” schreiben. Ich möchte aber abwärtskompatibel bleiben.
Für mich ist die Abwärtskompatibilität ein Muss. Ist es nicht ein typische Problem einiger erfolgloser/-armer und/oder umstrittender Proposals, die sogar “approved” sind, dass sie nicht abwärtskompatibel sind? Ich denke da nur an die Transformatoren-Tags, die ich selber nicht ganz verstehe. Wie ist eure Meinung zur Abwärtskompatibilität?
Wenn die OpenRailwayMap-Community mal groß ist, dann mappen wir jeden Schienenersatzverkehr (nicht mit Busnotverkehr verwechseln!).
Viele Grüße
Michael
PS Habt ihr schon mal eine unfreie Navi-Karte verwendet oder kennt ihr jemanden, der das tut? Ihr lernt die Autobahnbaustellen von vor einigen Jahren kennen (zumindest, dass dort Tempo 80 oder 60 galt).
