Die Frage ist (noch) theoretisch.
Wenn der OSM4D Viewer steht, ist dort eine Zeitleiste vorgesehen mit der Möglichkeit hin und her zu schieben.
Somit wird man beispielsweise Objekte die geöffnet sind farbig und die, die geschlossen sind grau darstellen können.
Um in die Vergangenheit zu reisen wird man einen Zeitpunkt eingeben können.
Natürlich wird die Karte starke Einschränkungen haben was Inhalte angeht: Historische Grenzen, entstehende Städte und Dörfer etc.
Trotzdem riecht das eher nach einem anderen Projekt und einem neuen Server, oder?
Es klinkt prinzipell interessant. Aber vielleicht sollten wir bei OSm erst einmal die Realität so gut wie möglich abbilden.
Ich kann dir also nur zu stimmen, wenn das nach einem neuen Projekt ausschaut.
So siehe ich das auch. Es wäre eine interessante Möglichkeit OSM für die Historiker schmackhaft zu machen.
Auch didaktisch wäre so ein historischer Atlas wahrscheinlich eine gute Sache.
Etwas Ähnliches habe ich schon mal 1995 gehört, als ich über 3D Stadtmodelle gesprochen habe.
Ich kann mich noch sehr gut an damalige Worte von Herrn Hagen Graeff (Präsident des Deutschen Vereins für Vermessungswesen e.V.) erinnern:
“Laß mal das Ding dem Verrückten machen. Das schafft man nie…”
Und nun ein Wenig ernsthafter: Wenn ich mir die Entwicklungskurve von OSM ansehe, denke ich, dass dieses Thema so in 4-7 Jahren läuft.
Eigentlich müsste man nur an möglichst vielen Objekten ein start_date=YYYY taggen. Damit kann man dann sehr schön alles ausblenden (oder dimmen), was später als das gewünschte Datum entstanden ist.
Natürlich ist dieser Ansatz nicht perfekt:
Wie Objekte ohne start_date behandeln?
Weglassen? Dimmen? Stricheln? Flächenfüllung? …?
Objekte, deren Bedeutung sich im Laufe der Jahre/Jahrhunderte geändert hat
(Pfad → Feldweg → Straße → Hauptstraße → … oder
Wegkreuz → Marterl → Kapelle → Kirche → …)
können so nicht adäquat erfasst werden.
Objekte, die nicht mehr existieren sollten in einer Jetzt-Zeit Karte nicht erscheinen.
Keine Ahnung ob end_date dafür ausreichen würde.
Hallo Edbert,
wir haben an start und end date für jedes Objekt gedacht,
wobei die nicht getaggten Objekte in dem besagten Viewer eben ohne Farbe als hellgrau ( etwa RGB=<230,230,230> ) dargestellt werden.
Das soll das Auffinden der nicht getaggten Objekte erleichtern. Bei der “Reise in die Vergangenheit” kann diese “heute” Ansicht als Hintergrund gezeichnet werden um dem User die Orientierung zu erleichtern.
Objekte bei denen die Bedeutung im Laufe der Zeit geändert wurde- z.B. aus einem Fußweg eine Straße müßten nach diesem Ansatz leider doppelt gezeichnet werden. Es ist zumindest bei historischen Bauwerken wichtig um die Übersicht zu behalten - z.B Umbauarbeiten an einer Kathedrale.
Zum Glück gibt es nicht unendlich viele solche Objekte und zum Zweiten ist unser Wissen über vergangene Strukturen sehr unkomplet, so dass wir für eine durchschnittliche Stadt eine endliche Anzahl der Varianten bekommen, die man anhand historischer Karten eintragen kann.
Ja klar, das geht aber nur eine Generation zurück.
Ich dachte jetzt eher an so Probleme wie z.B. mehrere unterschiedliche Nutzungen/Namen im Laufe der Jahr(hundert)e.
Wie auch immer, die Idee mit dem wandernden Tagebau finde ich gut.
Da sollte man auch etwas vorsehen für die Zukunft (soweit sie bereits bekannt ist).
Tagebaue und die zugehörigen Straßenverlegungen werden ja sehr lange im Voraus geplant/bewilligt.
So hört sich das für mich nach einem sinnvollen Ansatz an.
Das hatte ich geahnt/gefürchtet. Klassisches Beispiel dürfte eine Burganlage sein:
Bergfried → innere Burg → mittlere Burg → Vorburg → … → teilweise Zerstörung →
begrenzter Wiederaufbau → weitgehende Zerstörung → Ruinen (ohne Nutzung)
→ Rekonstruktion des Kernteils → neue Nutzung (Hotel, Restaurant, …) → …
Ich finde das Thema ebenfalls sehr interessant und wäre durchaus bereit einiges an Zeit in ein entsprechendes Projekt zu stecken.
Das Problem an einem neuen Server/ einer neuen Datenbank wird sein die aktuellen Daten von OSM mit einzubinden/zu verknüpfen.
Zur kompletten Nutzung der OSM-DB:
start_date=YYYY-MM-DD an noch existierende Objekte zu hängen wird denke ich kein Problem sein. Komplett verschwundene Objekte in der DB werden aber auf Nicht-Akzeptanz eines Teiles der Community stoßen und zur Verwirrung von Anfängern beitragen. Evtl. ließe sich dem Problem begegnen wenn alle in der Realität verschwundenen Objekte in allen Editoren per default ausgeblendet und nur in einem speziellen Modus bearbeitbar sind.
Hallo EvanE&marek,
ließe sich eine wechselnde Nutzung nicht mit Relationen darstellen? Für jede Nutzung eine Relation (mit Start-&Enddatum) wäre zwar sicher nicht unbedingt im Sinne des Erfinders, aber so müssten nicht mehrere Wege für das selbe Objekt gezeichnet werden, was wiederum die eindeutige geschichtliche Auswertung abseits von Karten ermöglichen würde.
Hallo Edbert,
mir fällt keine Bessere Lösung momentan ein. Laß uns gemeinsam darüber nachdenken. Es ist klar dass in einigen Bereichen es schwierig sein wird.
@BBO - Vielleicht ist Dein Vorschlag “per dafault ausblenden” auch eine Lösung: Man könnte das etwa so machen, wie in den sog. architektonischen Abbruchzeichnungen wo der “ist” Zustand schwarz, neu gelb und Abbruch rot ist.
Stellen wir uns vor: Ein OSM4D Editor hätte zugleich eine Zeitleiste. Wenn ich eine bestimmte Zeit einstelle wäre “ist” Zeit schwarz gezeichnet, das danach hellgrau uda das davor z.B rosafarbig. Der Standarteditor würde diese Elemente anhand von end_date und vielleicht zusätlicher Beschreibung nicht mehr anzeigen…
TU Lodz ist bereit einen Server für die Startphase zur Verfügung zu stellen. Wir bräuchten ein gut dokumentiertes Testgebiet um diesen Demonstrator schmackhaft zu machen.
BBO, kannst Du programmieren oder würdest du lieber an einem Testgebiet Was machen wollen?
Komplett verschwundene (oder zukünftige) Objekte können auch in eine externe Datenbank ausgelagert werden. Dann kommt man den Realitätsmappern nicht in die Quere. Das schont auch nebenbei die api, minutely diffs und bereitgestellte Extrakte
Hi ajoessen,
wie kann, technisch gesehen, die Auslagerung in eine externe Datenbank funktionieren, wenn ich in z.B. in JOSM editiert habe und ein externer Server bereitsteht?
Wie ich schon geschrieben habe: da sehe ich das Problem der Verknüpfung.
Beispiel Stadtmauer: ein Teil ist bis heute vorhanden, ein Teil wurde schon vor Jahren abgerissen
Wenn man die Daten komplett in der OSM-Db halten würde, könnte man zwei Wege(einer davon mit end_date) verwenden die sich einen node teilen.
In einer extra Datenbank müsste man einen neuen "Start"node ungefähr an die Stelle des "End"nodes in OSM setzen. So sieht es auf der Karte dann evtl. nach einer zusammenhängenden Mauer aus, sonst wäre das aber nur schwierig auswertbar. Aus einer extra Datenbank auf einen OSM node zu verknüpfen halte ich für zu Riskant, zu schnell wird in OSM ein node ersetzt.
Was Programmieren angeht: nur Grundlagen. Ich würde mich eher um Foren-/Wikipflege kümmern und natürlich testen wollen.
An welchen Server du deine gezeichneten Wege schickst lässt sich ja in JOSM einfach einstellen…
Es müssten halt zwei upload-Möglichkeiten angeboten werden:
mit der osm.api für reale Objekte
mit der osm4d.api für vergangene Objekte, die in josm eventuell auch in einer eigenen Ebene liegen.
Natürlich dürfen beide keine gemeinsamen Punkte haben.
Hi BBO,
danke für Deine Kommentare und den Tipp mit JOSM…
Wenn Du Wiki ausbauen könntest (http://wiki.openstreetmap.org/wiki/OSM-4D#Time) um das was wir hier diskutieren ( 1. pro und kontra - 2. mögliche Lösungen 3.Beispiele) wäre das ein super Beitrag.
Ich denke dass eine Datenbank für alles eine gute Lösung ist, allerdings bräuchte man für tägliche Arbeit Mechanismen die Vergangenes nur dann anzeigen, wenn jemand das ausdrücklich will. ich kenne JOSM nicht: Kann man dort elemente als visible / invisible deklarieren? Falls ja, dann könnte man wohl eine Art Voreinstellung vornehmen. Wir müßten uns nur wohl auf Taggingschema einigen…
Man kann nie wissen wo das ganze eines Tages hinführt
@Marek
Wenn wirklich eine extra Db aufgesetzt wird: was hältst du von meinem Relationen-Vorschlag aus Post #12?
Edit:
visible / invisible in JOSM sollte möglich sein (siehe Filterfunktion). Aber: eine entsprechende Voreinstellung sollte in allen gängigen Editoren vorhanden sein bevor es los geht (wenn solche Änderungen überhaupt auf die Akzeptanz der Community stoßen). Was das Taggingschema angeht: wir müssen wohl neue Schlüssel bzw. Kombinationen wie historic:amenity=… festlegen wenn wir in der OSM-Db bleiben wollen.
Diese Probleme hätten wir bei einer eigenen Db natürlich nicht, man könnte JOSM (evtl. mittelfristig ergänzt durch ein mittels Zeitstrahl gesteuertes Filterplugin) direkt weiternutzen und auch das Taggingschema müsste nicht geändert werden(nur durch start/end_date ergänzt).
