Baustellenmapping

Hallo erstmal in die Runde!
Ich möchte ein Teilstück eines Waldweges, welches z.Z. am Anfang/Ende durch jeweils eine Barke gesperrt ist, taggen. Ich fände sowas wie “track temporary under construction” am schlüssigsten, der code ist mir aber noch nicht ganz klar: http://wiki.openstreetmap.org/wiki/Key:construction

ich habe bisher:
highway:construction
tracktype:grade4
access:no
barrier:gate (==Barke?)
check_date:2012-05-06

das Teilstück ist relativ wichtig, kommt man nämlich von der “falschen Seite” kann man geradewegs wieder zurücklatschen (oder die Barke “verbotenerweise” umgehen) :confused:

Danke für jeglichen Tipp…M

Wird der Weg wirklich neu gebaut oder ist er nur abgesperrt ?
Falls letzteres reicht access=no. Die Barken taggst Du als Node mit barrier=irgendwas (weiss nicht was eine Barke ist).

Willkommen im Forum!

Trotzdem zum besseren Verständnis: Das Ding zur Absperrung heißt Bake (http://de.wikipedia.org/wiki/Bake).
Eine Barke ist ein schwimmfähiges etwas http://de.wikipedia.org/wiki/Barke

Weg ist schon lange existent, temporäre bauliche Maßnahmen (Abwasserrohre, Regendrainagen o.ä.)

Verkehrsbaken heißen die Biester wohl richtig ;), barrier=bollard hab ich da jetzt mal getaggt…merci M.

Sonst noch jemand? Habe leider (noch) keine Erfahrung mit proposals, ansonsten würde ich das gerne übernehmen. Keine Ahnung, wen man noch alles fragen sollte / muss bevor der Status gewechselt wird. Wobei ja RFC noch eine Stufe vor dem voting ist. Freiwillige vor…

Und, hat jemand Einwände? Man übersieht Gegenargumente gerne, wenn man etwas selbst für gut hält. Nicht, dass wir etwas “halbausgegorenes” freisetzen. Aber das ergibt sich ja dann während der RFC-Phase.

Das schwerwiegendste Gegenargument ist natürlich, dass es momentan von keinem ausgewertet wird - das kann man aber auch nicht erwarten, alles muss sich erstmal durchsetzen.

Ich habe die letzten Tage noch ein wenig nachgedacht und denke, daß es noch eine Stufe besser geht.


  Vor der Baustelle     Während der Baustelle     Nach der Baustelle  
---------------------x-------------------------x------------------------> [Zeit]
     highway=tertiary                               highway=secondary
     bicycle=yes               bicyle=no                bicycle=no
     maxspeed=50              maxspeed=30               maxspeed=60

Es gibt drei Zeiten. Vorher, Während und Nach. In diesem Fall wird eine Straße ausgebaut. Es gibt drei unterschiedliche Werte, die eingetragen werden müssen. Natürlich können nicht immer alle bekannt sein, aber häufig weiß man, daß etwas unterschiedliches eingetragen werden muss/kann/sollte.

Daher plädiere ich dafür, daß ganze dreistufig zu machen und nicht zweistufig wie in dem aktuellen Vorschlag. Als Ergänzung wäre temporary_thereafter eine Möglichkeit.

In diesem Fall also


highway=minor
bicycle=no
maxspeed=30

temporary_before:highway=tertiary
temporary_before:bicycle=yes 
temporary_before:maxspeed=50

temporary:construction=minor
temporary:bicycle=no
temporary:maxspeed=30

temporary_thereafter:highway=secondary
temporary_thereafter:bicycle=no
temporary_thereafter:maxspeed=60

Alles andere bleibt genau so wie in dem Vorschlag. Aktuelle Renderer zeigen dann die Karte so an, wie sie VOR der Baustelle war. Aktuelle Router Routen so, wie es vor der Baustelle war. Ein Bot könnte nach der Baustelle die Tags automatisch ändern. Und sowohl Renderer als auch Router können die Zusatztags auswerten, wenn sie möchten.

Das hätte einige Vorteile: Damit, daß man drei neue “Zeiten” statt einer neuen “Zeit” einfügt, hat man 100% des Funktionsumfanges vom aktuellen Vorschlag, hat aber den Vorteil, daß man über die “Alten” Tags (Die ohne temporary) die Daten so eintragen kann, daß aktuelle Renderer/Router mit dem aktullen Verkehrsverlauf vor Ort klar kommen können. Über die date_on und date_off Tags könnten Bots problemlos die Baustelle weiter pflegen. Und wenn ein Renderer/Router das Tagging-Schema unterstützt, zeigt er Taggenau alles richtig an. (Sofern die Baustelle dann auch rechtzeitig fertig wird).

Zugegeben, das _before" ist selten notwendig, aber für Leute, die nur 1x im Jahr Updaten anbieten, gibt es dann die Möglichkeit zu sagen “Zeige alles VOR den aktuellen Baustellen an” oder “Zeige alles NACH den aktuellen Baustellen an”

Hallo
Ich fand gut das jemand die Brücken Baustelle A2 Kreuz A7 eingetragen hat so hat Garmin das schön beachtet.
Irgendwann wird es jemand wieder entfernen.
ich selbst habe Köthen und Aken auf Construktion gesetzt voll gesperrt. bis Juli 2012
Klasse

Prinzipiell ein guter Vorschlag, das hat mich zum nachdenken angeregt. Jedoch denke ich letztlich, dass dies aus folgenden Gründen weniger sinnvoll ist:

  • Da nunmal jeder editieren darf (und soll!), sollte das ganze nicht zu komplex werden. Mit 2 Tags (die “normalen” und die temporären) ist das ganze noch recht übersichtlich und auch recht einfach auswertbar. Mehr wird einfach zu kompliziert für die meisten Benutzer. Und wenn es keiner einträgt, wertet es auch keiner aus, folglich trägt es auch keiner ein, folglich…
  • es ist (zum jetzigen Zeitpunkt noch) illusorisch anzunehmen, es wird schon jemand einen Baustellenbot loslassen, der wird mir schon irgendwann hinterherputzen und die Start- und Endezeitpunkte auswerten und daraufhin die Tags anpassen. Mit hoher Wahrscheinlichkeit stehen solche Tags für einen längeren Zeitraum, wenn nicht ewig, genau so in der Datenbank. Besonders außerhalb vielbefahrener Straßen und Großstädte. Und aus dem vorangegangen Grund fasst es auch keiner an.
  • Wechsel von Tags im Voraus einzutragen, halte ich für eine separate Aufgabe, und dies meiner Meinung nach besser über eine Kombination von etablierten Tags zu lösen, z. B. so in der Art (Landesstraße, die zu einer Bundesstraße ausgebaut wird):
    highway=secondary
    temporary:highway=construction
    temporary:date_on=2012-06-01
    temporary:date_off=2012-12-31
    construction=primary
    opening_date=2013-01-01

Ich finde, man sollte sich hier mal mit der 80%-Lösung zufrieden geben, zugunsten der Übersichtlichkeit.