bin gerade etwas angefressen und wollte mir mal etwas Luft machen.
Hier gibt es eine Baustelle wo die Straßenführung sich fast täglich ändert.
Da mit sich andere dort zurechtfinden habe ich denen erzählt sie sollte bei OSM reinschauen dort würde ich die Aktuellen Straßen ein tragen.
Nun wurde aber von jemand schon der Endstand eingetragen und man kann sich nicht mehr orientieren.
Wieder rausnehmen will ich es auch nicht, weil in ein paar Wochen wird es dort wahrscheinlich so aussehen.
Im Grunde hat hier keiner eindeutig Recht, weil wir zwar im Allgemeinen die Realität abbilden, aber der Umgang mit kurzfristigen/temporären Änderungen ein ungelöstes Problem ist. Für den, der sich jetzt OSM-Daten zur Offline-Verwendung für die nächsten Monate runterlädt, könnte beispielsweise der längerfristige Zustand deutlich hilfreicher sein als der tagesaktuelle.
Das ist also eher ein Fall für Miteinander-Reden und je nach Motivation des Gegenübers könnte “ich mach das schon richtig, halt dich da mal raus” eventuell nicht so gut ankommen.
Du hast völlig recht. An Deiner Stelle würde ich die Sachen rausnehmen, auf den realen Zustand korrieren und den Mapper anschreiben und ihn bitten sich auf die Realität zu beschränken.
Dem Argument daß ein nicht real existierender möglicher zukünftiger Stand für bestimmte exotische Anwendungen eventuell auch nützlich sein könnte kann ich nicht folgen. Ich halte es im Gegensatz für äußerst destruktiv, denn mit dieser Begründung kann man alles bunt gemischt eintragen: Den letzten stabilen Zustand, den realen Zustand, einen geplanten Zwischenzustand, eine persönliche Prognose eines wahrscheinlichen Zustand, einen geplanten Endzustand… Das Ergebnis ist totales Chaos. Ich halte es für sehr wichtig, daß es bei OSM ein Fast-Prinzip gibt, die Realität abzubilden und daß sich fast alle Karten mit der aktuell gültigen Realität beschäftigen.
Offline-Daten sind nicht “exotisch”, sondern einer unserer handfesten Vorteile gegenüber der Konkurrenz mit ihrem Immer-Online-Modell. Sobald du die komfortable Welt von Mapnik-Default verlässt und zum Garmin oder diversen Smartphone-Apps greifst, kannst du nicht mehr von minütlich aktualisierten Karten ausgehen.
Ich habe Thomas auch so verstanden, dass er keineswegs anzweifelt, dass es sich bei der konkurrierenden Eintragung tatsächlich um den bevorstehenden Zustand handelt, der dann auf längere Sicht bestehen bleiben wird.
Das Prinzip gibt es derzeit aber nicht - in Fällen, wo der alte und neue Dauerzustand identisch sind (z.B. eine eintägige Straßensperrung), scheint das auch deutlich mehr Mappern klar zu sein. Für eine eindeutige Antwort, wie wir mit so etwas umgehen, müssten wir eine Lösung finden, die verschiedenen Anforderungen unter einen Hut zu bringen - und eben nicht alle Anwendungsszenarien bis auf das, was ins eigene Bild passt, als exotisch abtun. Bis wir eine solche Antwort haben, sollte man die Frage eben mit Vorsicht und dem Wissen angehen, dass es noch keine perfekte Lösung gibt.
Da mich die Frage nicht direkt betrifft, würde mich jetzt allerdings eher die Reaktion des anderen beteiligten Mappers interessieren. Wer weiß, warum der das geändert hat und ob solche Grundsatzfragen überhaupt der Anlass waren.
vielleicht sollte es dann eher eine anklickbare option sein. das man nur aktuelles, oder auch geplantes / im bau befindliches “dazu klicken” kann. der osm mapper arbeitet nicht für den renderer ist hier auch wieder der fall. ich würde mir auch noch viel mehr an und ab klickbare dinge für die hauptkarte auf osm.org wünschen. z.b. das man auch die stromleitungen wegklicken kann oder auch die grenzen … andere karten haben zwar auch ne andere darstellung aber eine eigene karte zusammenbasteln ohne gleich selber eine datenbank und karte zu konstruieren/ zu rendern wäre schon sinnvoll
Für mich ist ganz klar dass wir den aktuellen Zustand mappen und den zukünftigen durch highway=(proposed|construction) kenntlich machen, wenn etwas geplant oder in Bau ist. Wir mappen keine Straßen, wo keine sind.
Natürlich kann man die OSM-Daten auch offline nutzen. Und natürlich aktualisiert sie dann nicht jeder in jeder Minute. Aber jemandem, der Daten offline nutzt, sollte auch bewusst sein, dass er damit nur eine Momentaufnahme einer dynamischen Datenquelle besitzt, die für den Zeitpunkt gilt, an dem er die Daten heruntergeladen hat. Die Daten in der Datenbank ändern sich, weil auch die Realität nicht statisch, sondern dynamisch ist. Wer aktuelle Daten haben will, muss sie zwangsläufig mit der Datenbank abgleichen.
Davon abgesehen wird sich jemand, der von seinem Navi auf eine Straße geschickt wird, die es nicht gibt, und der dann irgendwo in der Pampa steht, wohl mehr ärgern als jemand, der von einem Navi über eine etwas weitere Strecke, aber trotzdem zum Ziel geschickt wird, weil eine neue Straße noch nicht vorhanden ist.
Ich sehe es genauso wie Tordanik und würde das – bis es für diese Grundsatzfrage eine Lösung gibt – mit dem beteiligten Mapper diskustieren.
Wenn man mich an der Stelle freundlich fragen würde hätte ich vermutlich nichts dagegen, wenn meine Eintragungen (sinngemäss und ggf verbessert) danach wieder und zwischenzeitlich als *=construction da sind und der Stand des neuen Tages rechtzeitig zum Geofabrik-Extrakt des entsprechenden Morgens aktualisiert wird, sodass Offline-Anwendungen von den tagesaktuellen Daten wenigstens theoretisch (selbst erstellte Karten) auch profitieren könnten (statt immer ein bis zwei Tage veraltet zu sein).
Dazu bräuchten wir erstmal etwas, womit man das in den Daten sinnvoll angeben kann. temporary:= scheint ja nicht so beliebt zu sein.
Btw wäre es schön, wenn bei vorübergehenden Bauarbeiten, bei denen der Ursprungzustand nahezu dem Endzustand entspricht, wenigstens der Baustellenzustand danach auch wieder entfernt würde (Beispiele: 1, 2).
Und hier liegt eher “Entwicklungsbedarf” bei den Apps, denn wir haben die Möglichkeit es auch halbwegs gut Abzubilden. Die Bestandstrecke erhält ein “Ablaufdatum” und die construction erhält ein Beginndatum. Die App sollte dann selber aus dem Datum “errechnen”, welche gerade aktuell ist.
Ein weiteres Beispiel, daß die Dimension Zeit in OSM bisher eher stiefmütterlich behandelt wird, von nicht wenigen sogar am liebsten ganz wegdiskutiert oder in (praktisch nicht existierende) andere Datenbanken verbannt wird? Stattdessen wird 3D stark gepusht, dessen praktischer Nutzen sich mir bis heute nicht wirklich erschließt. Ein wenig mehr Gleichbehandlung der Dimensionen abseits des Planaren täte OSM gut!
Weißt du, warum das Thema 3D derzeit gut da steht? Weil sich der Teil der Community, der sich dafür interessiert, schon vor Jahren zusammengesetzt und eine funktionierende technische Umsetzung überlegt hat - inklusive ein Tagging-Schema, das einfach genug ist, um im OSM-Alltag praktikabel zu sein. Dann haben diese Leute direkt noch Software auf die Beine gestellt, die das auch auswertet. Und nicht zuletzt wurde über lange Zeit hinweg immer wieder gründlich und geduldig dokumentiert, erklärt, Werbung gemacht.
Da müssten jetzt eben auch mal ein paar fähige Leute, die an die Zukunft zeitbasierter Daten in OSM glauben, gemeinsam ihr Thema anpacken.