Verwendung von "disused" bei Straßenbauarbeiten?

Die Prüfung der Buslinien mit dem Tool
http://tools.geofabrik.de/osmi/?view=pubtrans_stops&lon=9.14412&lat=48.94272&zoom=11&overlays=stops_,stops_positions,stops_classic,stops_positions_not_on_ways,platforms_,platforms_nodes,platforms_ways
hat mir „invalid routes“ in meinem Mappingbereich angezeigt. Bei der näheren Prüfung habe ich festgestellt, dass JOSM im Bereich des Bahnhofs Freiberg (Kreis Ludwigsburg) etliche Fehler anzeigt. Ich vermute, dass der Eintrag „disused:highway=residential“ in der Bahnhofstraße, der mit dem Änderungssatz: 53045036 erfolgte, für die invalid Busroute verantwortlich ist.
Ich habe deshalb den Mapper-Kollegen angeschrieben und auch die Frage gestellt, ob das disused richtig ist, falls die Straße wegen Bauarbeiten derzeit gesperrt ist. Er ist der Meinung, dass dies seine Richtigkeit hat, u.a. weil sie wegen Bauarbeiten bis Ende Dezember nicht benutzbar ist und niemand durchfahren kann.
Das disused führt nun u.a. dazu, dass ein Straßenstück auf der Karte nicht mehr sichtbar ist, obwohl tatsächlich noch vorhanden, allerdings im Umbau. Ein Fußweg endet so auch im Nichts. Ich meine, dass man deshalb access oder evtl. construction verwenden sollte. Bin ich da auf dem Holzweg?
Wie ist die Meinung der Experten?

construction ist richtig (als Prefix construction:highway=residential oder als Paar highway=construction + construction=residential).

disused heißt soviel wie leerstehend, brachliegend, gammelt-vor-sich-hin. Kurz vor „abandoned“, das mit „aufgegeben“ übersetzt werden kann.

Edit: Der Klarheit halber würde ich noch access=no dazusetzen.

–ks

Ist jedenfalls eine der ungebräuchlichsten Möglichkeiten ein Baustelle zu kennzeichen und führt dazu dass die Straße aus fast allen Anwendungen verschwindet.

Besser:

hw=construction (längfristige Baustelle)
oder
construction=yes (kleinere Baustelle)
oder
access=no
oder
temporary:access = no

Entweder bitte ganz oder gar nicht. construction=yes ist ein Beispiel für Tagging-Fehldesign. Da bekommt man als Datennutzer einen Way mit highway=primary und glaubt, es handelt sich um eine Bundesstraße. Dass ein disused=yes, welches die Bedeutung eines der zentralsten Keys in OSM umkehrt, prüft fast keiner.

construction=* an Ways impliziert, dass die Straße in irgendeiner Weise nicht befahrbar ist. OSRM verwirft daher z.B. im Pkw-Profil alle Straßen mit construction!=no im Rahmen der Präprozessierung. Bitte verwendet dieses Tag nicht.

Wenn ihr unbedingt das Bedürfnis habt, Sperrungen von weniger als sechs bis acht Wochen zu erfassen, dann verwendet Conditional Restrictions oder verpasst alles mit einem temporary:*-Präfix in Anlehnung an das Lifecycle-Schema.

construction=yes an Straßen, Bahngleisen und ein paar weiteren Sachen wird deshalb im Tagging-View im OSMI als “hidden non-operational tagging” (verstecktes Erfassung des Nichtinbetriebseins) gekennzeichnet.

Viele Grüße

Michael

Leider werden solche Einträge von keinem Router berücksichtigt. In der Tat ist es besser, mit construction oder access=no zu arbeiten. Wichtig ist die zeitliche Überwachung der Sperrungen, damit sich keine “Sperrleichen” einschleichen.

OSRM und/oder Graphhopper haben Code zur Auswertung von Conditional Restrictions. Zumindest sehe ich bei einem der beiden Warnungen im Logfile, dass bestimmte Tags nicht verarbeitbar seien.

Es hat dem Mapper egal relativ zu sein, ob Router etwas auswerten, oder nicht. Wir taggen nicht für das Rendereräquivalent.

Da bin ich leider nicht deiner Meinung. Was nützt es einem Verkehrsteilnehmer, wenn er vor einer Sperrung steht, die ein eifriger Mapper zwar mit temporary eingetragen hat, sein tolles OSM basiertes Navi aber nicht berücksichtigt? Selbstverständlich wollen wir erreichen, dass OSM Navis besser und aktueller sind als andere oder nicht?

Wenn vor Ort eine Sperrung (A20) als Baustelle (construction) eingetragen ist, entspricht es den “Tatsachen vor Ort”. Also sind die Daten richtig …

Wir möchten, dass OSM aktuell ist, aber OSM ist kein Projekt, um kurzfristige Sperrungen wie lang andauernde zu erfassen. Wenn es keine Anwendungen gibt, die Sperrungen vorübergehender Dauer aus OpenStreetMap auswerten, gibt es sie eben nicht. Das ist aber kein Grund, deshalb die Daten falsch zu erfassen!

Bei der Sperrung der A 20 ist jedoch davon auszugehen, dass die Sperrung eine längere Zeit bestehen wird. Dein Vergleich hinkt.

Eine Sperrung, bei der absehbar, dass sie nur wenige Wochen Bestand haben wird, widerspricht jedoch unserem Grundsatz, keine temporären Dinge in OpenStreetMap zu erfassen.

Es ist einfach irrsinnig, von einem Datennutzer zu erwarten, dass er sich alle drei Wochen Updates zieht, und in meine Berufpraxis sind bei manchen Kunden die Updateintervalle einfach länger, weil es äußere Umstände erfordern (z.B. Offline-Anwendungen, vorgerenderte Tiles, Shapefiles oder Tileserver, die in virtuellen Maschinen installiert werden und irgendwann™ gestartet werden und daher nicht den Updaterückstand aufholen können).

+1

*Daher sollten Sperrungen insbesondere von Straßen und Schienen unter sechs (manche Mapper meinen neun) Monate nicht als =construction getaggt werden. Stattdessen sollte das Taggingschema Conditional Restrictions oder ein spezielles Schema für das Taggen temporärer Veränderungen verwendet werden, auch wenn es nicht von allen Routern unterstützt wird.

http://wiki.openstreetmap.org/wiki/DE:Key:construction

Leider wird das temporäre Sperren anscheinend überhaupt nicht unterstützt? Allerdings bin ich mit euch, dass kurzzeitige Sperren nicht erfasst werden sollten. Über die Dauer von “kurzzeitig” könnte man trefflich streiten, da bin ich aber raus.

Das war auch eigentlich nicht das Ausgangsthema. Hier ging es darum, dass eine Straße mit disused gekennzeichnet worden ist und damit offenbar aus der Karte verschwand. Wenn an der (unbenutzbaren) Straße gebaut wird, ist die m. E. richtige Kennzeichnung construction bzw. access=no, was jeder Router verstehen sollte. Dann würde die betreffende Straße auch noch dargestellt. Die Begründung: “Das ist aber kein Grund, deshalb die Daten falsch zu erfassen!” ist haltlos, da ist nichts falsch erfasst.

Das erwartet tatsächlich niemand. Aber wenn unser Datenbestand möglichst aktuell gehalten wird, hat jemand überhaupt die Chance, sich neue, aktuelle Informationen zu holen. Es kann keine Begründung sein, dass die Kunden von Nakaner längere Updateintervalle verwenden.

Das ist ein Problem der Datennutzer. Wenn ein Haus im Herbst abgerissen wird ist es weg. Wenn an der Stelle im Frühjahr ein neues “construction” ist, wird es eingetragen und bei Fertigstellung dann als building=*.
M.E. ist ja gerade der Vorteil von OSM: “aktuellen Daten”.

EDIT:
Kurzzeitig wäre für mich eine Zeitangabe “von - bis” zum Reparieren / Verlegen einer Leitung, Deckenerneuerung.

Sehe ich ähnlich. Wer nur alle 6 Monate aktualisiert, der muss halt damit rechnen, dass seine Daten seit 5,99 Monaten überholt sein können. Das kann genauso dann geschehen, wenn wir sagen, dass nur noch Baustellen ab 6 Monaten Dauer eingetragen werden. Nimm an, ich trage am 13.12. so eine Baustelle ein, am 13.6. ist sie fertig, am 14.6. wird zurückgetaggt, aber der 6-Monats-Nutzer hat dummerweise am 13.6. seine Daten gezogen. Dann hat er die falsche Information auch ein halbes Jahr drin, obwohl es keine kurzzeitige Maßnahme war.

Dreitagebaustellen zu mappen finde ich übertrieben, aber ein 4-Wochen-Aktualisierungsturnus scheint mir beispielsweise bei OSM-Navi-Apps heute Standard zu sein. OsmAnd macht das zuverlässig, danach kann man den Kalender stellen – die deutschen Bundesländer kommen am 4. und 5. neu rein, mit Stand vom Ersten. MapFactor ist etwas unregelmäßiger. Von den anderen weiß ich’s nicht.

–ks

Wenn etwas Altes durch etwas neues, aber anderes ersetzt wird (z.B. Kreuzung durch Kreisverkehr, zweigeschossiges Haus durch ein viergeschossiges), spielt für mich die Dauer der Baustelle keine Rolle. Es handelt sich dann um einen Übergangszustand.