Hallo Georg,
ich kann deine Argumente durchaus nachvollziehen.
Ich selber habe auch schon längere Baustellen gemappt. Wenn man sich aber vornimmt, so nah an der Zeit zu mappen, dann soll man da auch konsequent sein. Vor allem wenn klar ist, dass es ein temporäres Objekt ist.
Es kann ja auch passieren, dass der Routing-Anbieter seine Datenbank nur jedes halbe Jahr aktualisiert. Es spielt dann unter Umständen keine Rolle, ob jemand auf die Minute genau die fertige Baustelle wieder austrägt. Ich empfehle deshalb immer: Straßenbaustellen ab einem halben Jahr sind ok, kleinere Baustellen sollte man sich gut überlegen. 
Tagesbaustellen sollte man sicher nicht mappen, aber alles was so einen Monat dauert, macht mMn Sinn.
Dann müssen sich aben die Routing-Anbieter an die OSM Möglichkeiten/Gepflogenheiten anpassen!
PS: bei manchen langfristigen Baustellen steht dran, wie lange sie geplant sind. Vielleicht kann man das in tagging aufnehmen und wenn die Zeit abgelaufen ist, als Fehler in OSMI melden.
@derstefan: Es ist nicht unser Problem, wie häufig der Router oder der Nutzer seine Daten aktualisieren.
Jeder Auswerter kann aus einem highway=construction construction=* ein highway=* machen, so er sich dran stört. Das Problem ist nicht, ob es gemappt werden soll, sondern dass man sich als Mapper, der eine solche temporäre Sache mit einem solchen Ausmaß einträgt dann auch am Ball bleiben muss.
Im vorliegenden Fall sieht es eher so aus, als sei die Behelfsausfahrt übersehen worden. Davor kann auch ein note=“Behelfsausfahrt xy muss auch weg” an der eigentlichen Straße helfen.
In Zürich wurde vor kurzem die Hardbrücke (Hauptstrasse quer durch die Stadt, 1.5 km lang) saniert. Dabei wurde (gefühlt) fast täglich die Routenführung geändert, weil Auf- und Abfahrten zeitweise gespert wurden. Da aber ein Mapper dort tagesaktuell die Bauarbeiten nachführte, konnte ich täglich auf osm.org prüfen, wo ich lang fahren musste, um zu einem Kunden direkt an der mittleren Ausfahrt zu kommen.
Eventuell müssen sich dann halt die Anbieter von Routing-Lösungen anpassen oder (bei langen Update-Intervallten) temporäre Sperrungen ignorieren.
Ich finde die aktuellen Informationen sehr hilfreich.
Habe eben zufällig das Proposal zu temporary:= entdeckt. Diesen Vorschlag finde ich persönlich sehr gut.
Also Beispiel:
Die Baustelle auf der Landstraße wird zu
highway=secondary
temporary:vehicle=no
temporary:date_on=xxx-yy-zz
temporary:date_off=xxx-yy-zz
und der parallel verlaufende Feldweg wird zu:
highway=track
access=agricultural
temporary:access=yes
temporary:date_on=xxx-yy-zz
temporary:date_off=xxx-yy-zz
Alles wird über zusätzliche Tags ausgedrückt und nicht durch verändern von bestehenden, langfristigen Tags. Wenn die Zusatzinformationen mal 2 Jahre stehenbleiben, stört das keinen.
Somit könnte jeder auf die relevanten Tags zugreifen. Papier- und Navikarten-Ersteller sowie und unregelmäßig aktualisierte Renderer auf die Standard-Tags (also abwärtskompatibel, keine Änderungen nötig - das is DER Bonus überhaupt) - und der tagesaktuelle Turbo-Renderer, und online-Router können die temporary: - Tags bevorzugen (sofern innerhalb der on-off-Zeit).
Sollten wir mal das voting anstoßen, haltet ihr das für sinnvoll?
(das einzige Problem könnte sein, dass “DER” Renderer 
ein solcher Turbo-Renderer ist, diesem müsste man angewöhnen die temporary-Tags auch zu benutzen - aber wir taggen ja nicht… )
Super Vorschlag. Und wenn man auf der Online Karte bequem zwischen Dauer- und Temporäransicht hin-und-her schalten
könnte wär’s optimal.
Ich habe es jetzt nicht vollständig durchgelesen, aber auf die Schnelle denke ich, das deckt zu 100% alles ab.
Außer natürlich, daß es aktuell niemand unterstützt.
Natürlich Mappt man nicht für die Renderer oder Auswerter, aber wenn etwas neueres erstmal eine Verschlechterung hervorruft, sollten zumindest Mapnik, Osrm und die Garmin-Leute ins Boot geholt werden, das würde auf jeden Fall für deutlich mehr Zustimmer sorgen.
Alternativ schlage ich eine leicht veränderte Lösung vor (Hab sie noch nicht durchdacht, es kann also sein, daß sie fehlerhaft ist), die in der Endlösung gleich ist, aber in der Übergangslösung keine neuen Bugs hervorruft.
Aktuell:
highway=construction
Neuer Vorschlag:
highway=secondary
highway:temporary:construction
Mein Vorschlag, nur gültig für die ersten 12 Monate und/oder bis ausreichen Unterstützer da sind:
highway=construction
highway:temporary=construction
highway:following=secondary
Damit zeigt Mapnik aktuell alles richtig an, OSRM Routet richtig, die Garmins zeigen alles richtig an. Und wenn “die größten” umgestellt haben, fällt dieser Sondervorschlag weg.
Die aktuelle Vorgehensweise (“mappe so, wie es jetzt gerade ist”) setzt permanente, kurzfristige Aktualisierung der Datenbasis voraus. Welcher Anwender macht das schon (außer Mapnik)?
Alle Auswerter, die auf langfristig konsistente Daten angewiesen sind, haben so nicht die Möglichkeit, den “regulären” Verlauf zu erfahren. Sie sehen nur den aktuellen Baustellen-Zustand. Wenn ein Auswerter technisch in der Lage ist, häufige Updates zu machen und auf tagesaktuelles Routing bzw. Rendering Wert legt, dann soll er die temporary-Tags eben auswerten.
Okay, damit hast Du natürlich recht. Wenn Mapnik mitmacht, hat der Vorschlag keine Nachteile, da fast alle anderen aktuell zu langsam für Baustellen sind.
Diese Baustelle ist anscheinend auch vergessen worden. Hab den Sperrer mal angeschrieben.
http://www.openstreetmap.org/?lat=51.839043&lon=6.88345&zoom=18&layers=M
Edit: Antwort: *Keine Ahnung, ob’s noch gesperrt ist. Wohne nicht mehr in der Gegend,
kann von daher auch nicht nachschauen. *
Ja, ich halte es für Sinnvoll. Hat jemand Erfahrung damit?
Mapnik müsste halt noch lernen, Tiles zeitgesteuert als dirty zu markieren, sonst wird die Darstellung am temporary:date_on und temporary:date_off nicht geändert.
Warum gibt es eigentlich keine vernünftige Baustellen-/Unfall-/Verkehrs-Karte, die über APIs auch von Software angesteuert werden kann? Da ist uns Waze beispielsweise meilenweit voraus. Die haben es geschafft ein gutes Reporting-System mit sozialem Charakter zu etablieren, so dass sie durch gute Algorithmen und viele begeisterte Nutzer einen brauchbaren Kartenbestand in DE (zumindest in meiner Region) aufbauen konnten (sogar ohne Open-Source-Charme sind Leute zum Mappen zu gewinnen).
Wo haben die denn Ihren Datenbestand her? Straßen von 1999 fehlen noch, anderes von 2005 ist schon eingebaut. Waldwege (Schotter unter den Baumkronen) sind als Straßen gezeichnet, Radwege als Einbahnstraßen. Sogar eine Fußgängerunterführung mit Radfahrerspur ist als Einbahnstraße gezeichnet.
Das “da” war auf Baustellen/Unfälle und temporäre Daten usw bezogen nicht auf Kartendaten;)
Die zeichnen glaube ich auch automatisch Straßen ein, wenn viele Leute eine Strecke befahren (also es viele Tracking-Logs gibt).
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) 
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.