Baustellenmapping

fx99 · 2012-04-10T09:55:47.000Z

derstefan:

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.

aighes · 2012-04-10T10:57:28.000Z

@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.

mdk · 2012-04-10T15:22:03.000Z

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.

Yggdrasil · 2012-05-05T20:33:04.000Z

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… )

chris66 · 2012-05-05T21:09:53.000Z

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.

Dennis_B · 2012-05-05T21:23:54.000Z

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.

Yggdrasil · 2012-05-05T21:45:54.000Z

'Dennis[B:

']Außer natürlich, daß es aktuell niemand unterstützt.

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.

Dennis_B · 2012-05-05T22:18:09.000Z

Yggdrasil:

'Dennis[B:

']Außer natürlich, daß es aktuell niemand unterstützt.

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)?

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.

chris66 · 2012-05-05T23:15:05.000Z

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. *

Dennis_B · 2012-05-05T23:26:02.000Z

Yggdrasil:

Sollten wir mal das voting anstoßen, haltet ihr das für sinnvoll?

Ja, ich halte es für Sinnvoll. Hat jemand Erfahrung damit?

mdk · 2012-05-06T08:49:24.000Z

'Dennis[B:

']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.

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.

kerosin · 2012-05-06T09:53:59.000Z

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).

Dennis_B · 2012-05-06T11:07:49.000Z

kerosin:

Da ist uns Waze beispielsweise meilenweit voraus.

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.

kerosin · 2012-05-06T14:10:54.000Z

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).

Michelinho · 2012-05-10T08:15:43.000Z

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

chris66 · 2012-05-10T08:25:53.000Z

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).

_torsten · 2012-05-10T10:17:47.000Z

Michelinho:

… am Anfang/Ende durch jeweils eine Barke gesperrt ist, taggen…

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

Michelinho · 2012-05-10T15:53:03.000Z

chris66:

Wird der Weg wirklich neu gebaut oder ist er nur abgesperrt ?

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

chris66:

Die Barken taggst Du als Node mit barrier=irgendwas (weiss nicht was eine Barke ist).

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

Yggdrasil · 2012-05-14T19:23:30.000Z

'Dennis[B:

']

Yggdrasil:

Sollten wir mal das voting anstoßen, haltet ihr das für sinnvoll?

Ja, ich halte es für Sinnvoll. Hat jemand Erfahrung damit?

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.

Dennis_B · 2012-05-14T19:57:02.000Z

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”