Baustellenmapping

Hier mal wieder eine typische deutsche Autobahnausfahrt.

Veraltete Baustellenausfahrt die es bereits seit einem halben Jahr nicht mehr gibt, gammelt noch über die Gegenspur:

Was hat es nun gebracht die Baustelle zu mappen, wenn danach für ein halbes Jahr ein eklatanter Fehler drin war, den ich nur durch den absoluten Zufall gefunden habe. Das erinnert mich an das vehicle=no auf einer Bundesstraße, deren Baustelle schon 2 Jahre nicht mehr existent war. Irgendwelches Zeug wird immer schnell eingetragen, aber hinterher kümmert sich keiner mehr drum.

Von den Leuten die mit ihrem Navi nicht daueronline sind und höchstens alle 5 Jahre updaten wollen (wenn überhaupt) mal ganz abgesehen.

+1

Wenn man unbedingt temporäre Sperrungen/Veränderungen eintragen möchte, dann soll man die auch wieder austragen. Wenn man das nicht gewährleisten kann, dann SOLLTE man das lassen!!

+1
Eventuell macht ne Wikiseite Sinn wo solche Temporären Baustellen eingetragen und
nachverfolgt werden können. Nur wer garantiert, dass es auch eingetragen wird…

-/+1

Ich sehe das etwas anders.
Ich bin durchaus ein Vertreter der ‘langfristigen- Baustellen’-Mapper - a la OSM ist aktuell und kann immer nur dem gemappten Zeitpunkt entsprechen; es lebt davon, das Änderungen irgendwann gemappt werden.

Eine vernünftig gemappte Baustelle (*) leitet den Verkehr auch entsprechend - und führt nicht zu so einem ‘falschen’ Routingergebnis.
(Baustellenüberleitungen sind m. E. auch nicht unbedingt als motorway zu taggen, sondern können durchaus aufgrund ihrer Einschränkungen als service getaggt werden - um so eher fällt die Besonderheit auf, wird neugemappt und beim Routing entsprechend berücksichtigt.)

Dieses Routingergebnis beruht m. E. nicht auf der Baustelle an sich, sondern auf dem späteren Ummappen zum Jetzt-Zustand (**) - da entstand m. E. der Fehler, dabei hätte die Baustellenführung entfernt werden müssen.

Ja - aber auch davon lebt OSM und seine Aktualität - zumindest zum Teil - und eben zum Teil auch davon, dass sich dann jemand Anderer drum kümmert.
Denn wenn man den Einwand zu ernst nimmt, dürfte man im Urlaub überhaupt nicht mehr mappen, da man ja höchstens u. U. einmal jährlich wenn überhaupt wieder kommt.
Dann ist der Fehler - nämlich das Nichts oder veraltete POI - noch viel länger in der Karte.

Jeder Eintrag, den ich mache, kann ein temporärer Eintrag sein - wer weiß denn, ob der POI ein halbes Jahr überlebt?
Kannst Du garantieren, dass Du jeden Eintrag quartalsweise überprüfst?
Aber ja, solch temporäre Sachen sollte man schon nach Möglichkeit selbst überwachen - und sei es nur aus der Ferne.
Ich werde ‘meine Baustellen’, z. B.
http://www.openstreetmap.org/?lat=54.14428&lon=10.21342&zoom=15&layers=M
auch nach Möglichkeit überwachen - trotzdem baue ich auch darauf, dass jemand anderes die Veränderung mitbekommt und dann wieder ändert - möglichst, ohne dann solche Routingfehler zu produzieren.

Das OSM-Prinzip ist ja nicht nur, das viele Mapper ihren Bereich mappen, sondern das auch ein Bereich von vielen Mappern gemappt wird.
Ich möchte das weder in die eine noch die andere Richtung einschränken (müssen).

Gruß
Georg

(*) davon gehe ich jetzt mal aus, falls sie es nicht war, war es eh sinnlos - aber die Art des Mappens, nicht die gemappte Baustelle an sich.
(**) Die Richtungsfahrbahnen dürften zur Baustellenzeit ja so nicht existiert haben, zumindest Gegenverkehr und access-Einschränkungen müssen ja existiert haben - korrektes Baustellenmapping vorausgesetzt.

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