Abgerissene Häuser lassen wir ja in der Datenbank, weil sie z.B. in Luftbildern noch erkennbar sind und damit die Gefahr bnesteht, dass sie (falsch) wieder eingetragen werden.
Viele Objekte sind ja auch heute noch in einer Nutzung (railway=abandoned → Radweg, Feldweg → Straße) oder sind heute noch in anderer Form sichtbar (Burgmauer/graben → lineare Erhebung/Senke). So braucht vieles nur zusätzliches Tagging. Für Dinge, die heute nicht mehr (ggfs. in anderer Form) sichtbar sind, passt dieser Ansatz natürlich nicht.
Für Zukunft kann natürlich nur in Frage kommen, was schon genehmigt ist, wie die Erweiterung/Verlagerung von Tagebauen, Steinbrüchen oder Straßen. Zumindest der Teil bewilligte Planungen hat mMn durchaus seine Berechtigung in den OSM-Daten. Das schließt den Bundesverkehrswegeplan als ‘Wunschliste’ explizit nicht ein.
Für den Rest, der heute in keiner Form mehr erkennbar ist, erhebt sich die Frage, wie man das a) in eine andere Datenbank speichert und b) wie solche zusätzlichen externen aber eng gekoppelten Datenbanken in den Editoren (bei JOSM z.B. als eigene änderbare Ebene) verwendet werden können.
Es könnte aber auch nur einen Upload zu OSM4D geben, welcher dann die aktuellen Elemte an die OSM API weiterschiebt. Natürlich nicht als BOT sondern wie Josm im Benutzerkontext. Dazu muss sich jeder User vorher auf dem Server ein OAuthKey anlegen und fertig ist der Lack.
Damit greift man dann nicht in bestehende Strukturen ein.
Außerdem müsste der Server sich dann darum kümmern die aktuellen Daten von OSM zu spiegeln und kann die historischen mit einer anderen OSM ID (negativ) bereitstellen.
Das Problem wird nur sein, dass Konflikte eben nicht beim Hochladen erkannt werden, sondern erst beim überspielen. Vielleicht kann man aber solange die Verbindung aufhalten.
Relationen können nur an bestehende Objekt gehängt werden. Wenn sich aber der Grundriss dieser Burg dreimal ändert, dann hast du nicht nur 3 Relationen sondern auch drei Wege da drin.
Ich würde dann entsprechend 3 Relationen mit den in dem bezeichneten Zeitraum genutzten Mauern als Mitglieder anlegen: so kann jede Mauer(=way) solange genutzt werden wie sie auch in der Realität vorhanden war. Andernfalls müssten drei Wege für das selbe Objekt angelegt werden, die zusammenhängende Geschichte einer Mauer würde verloren gehen.
Nur so als Anregung: Ich weiß nicht, ob es schon eine Möglichkeit gibt, die (geschätzte) Genauigkeit eines Wertes zu modellieren. Besonders bei historischen Daten (Grenzverläufe etc.), bei denen die Genauigkeit weit unter der von GPS liegt, wäre so eine Angabe m.E. nach sinnvoll.
Eine extra DB möchte ich nur in dem Fall, dass nachgewiesenermaßen Etwas in OSM definitiv nicht geht bzw von der Community größtenteils abgelehnt wird.
Das Bauchefühl sagt mir, dass außerhalb der großen OSM Lösung Projekte nur eine Randexistenz führen.
Für die Testzwecke: z.B verschiedene Gegenvorschläge testen, braucht man eine extra DB.
So gesehen weiß ich einfach selbst nicht was besser ist: Für jede Nutzung eine Relation (mit Start-&Enddatum) oder ein Haufen neuer Grundriße.
@ BBO Vorschlag:
Nimm ein bekanntes Objekt an dem viele Änderugen frei und gut dokumentiert sind, zum Beispiel: http://www.stadt-os.com/images_design/Grafiken_Inhalt_Archaeologie/arch_Dom_plan2005_1500.jpg und versuch´s mit beiden Methoden.
Noch niemand hat´s gemacht, wir diskutieren größtenteils über Unbekanntes.
Du wirst eine Erfahrung sammeln und darüber berichten können: Vorteile und Nachteile beider Methoden.
Auf dieser Grundlage wird es für uns alle leichter gemeinsam eine Entscheidung zu treffen…
Nun es gibt eine ‘goldene Regel’ bei OSM: Map what’s on the ground
Die wird auch manchmal verkürzt mit “ground truth” bezeichnet.
Historische Daten genügen dieser Forderung (zu deutsch etwa: “Erfasse die Realität”) nicht.
Von daher ist die OSM-Community sehr skeptisch, was diese Daten betrifft.
Es ist das gleiche wie mit Luftverkehrswegen, Funkbereichen, Funkreichweiten, Satelliten-Laufbahnen und vielem anderen. Im Grunde wäre eine gut integrierte Lösung (Editoren) mit einer externen Datenbank ein echter Fortschritt für OSM. Fortschritt in dem Sinne, dass auch Daten, die nicht in die Haupt-Datenbank gehören, trotzdem eng an OSM gekoppelt sein können. Mit der Existenz einer solchen ‘Standard’-Anbindung für externe Datenbanken würde z.B. die Frage “TMC-Daten in OSM oder nicht” neu zu bewerten sein.
Ich denke gerade über euer eigenes Projekt hinaus gedacht, wäre die Entwicklung einer Datenbank-Anbindung eine lohnende Aufgabe.
Kannst Du die Lösung aufskizzieren und in Wiki platzieren?
Was wäre in der API 7 zu ändern?
Was in der Grundstruktur?
Btw.: Map what’s on the ground ist eine vereinfachende Regel, sie erlaubt streng genommen schon das erste Stock eines Hauses, oder Brücke die auf der Brücke liegt nicht. Ein Verbot ist streng genommen auch Etwas abstraktes. Aber ich gebe zu, es ist schwer eine Trennlinie zu ziehen, daher wäre es wahrscheinlich eine Bereicehrung wenn man garantieren könnte dass eine Änderung in der Datenbank A auch eine Folge in der Datenbank B hätte.
Eine externe Datenbank kann nach zwei Prinzipien aufgebaut sein:
Verwende die Datentypen und Methoden von OSM plus eigenes Tagging wo nötig.
Mache etwas eigenes, was der Struktur der externen Daten angepasst ist.
Im ersten Fall kannst du die Werkzeuge, die bereits für OSM existieren mit wenig Aufwand verwenden oder anpassen.
Im zweiten Fall musst du alle Werkzeuge für die Datenbank und für die Bearbeitung der Daten selber entwickeln. Das scheint mir für die meisten Fälle kein guter Ansatz zu sein.
In beiden Fällen sollte die Zuordnung OSM - externe Daten möglichst nur über die Geokoordinaten erfolgen.
Eine Garantie für den Bestand oder die Unveränderbarkeit von OSM-Objekten ist weder möglich noch gewollt.
Eine Änderung in der API 0.6 / 0.7 scheint mir nicht notwendig.
Anpassungen sind hingegen in den Editoren notwendig.
(Ich kann nur über JOSM aus eigener Anwender-Erfahrung reden.)
JOSM müsste es unterstütze, je Datenebene einen unterschiedlichen
Download/Upload Server zu verwenden. Ob das in anderen Editoren
wie Merkaartor oder Potlatch2 geht, vermag ich nicht einzuschätzen.
Daneben braucht es auch noch eigene Vorlagen für solche Ebenen,
die in einer ‘OSM-Datenebene’ nicht angewendet werden sollen/dürfen.
In Summe also durchaus größere Änderungen an der JOSM Programmstruktur.
Nach meiner Vorstellung sind die Datenbank-Inhalte zwischen OSM und einer externen Datenbanken disjunkt. Von daher sollte es nichts geben, was man koordinieren müsste.
Aber wer ist denn Mitglied in deiner Relation? Es geht doch nicht darum, dass wir eine Mauer haben die einmal 2m breit und 5 m hoch ist und danach 3m breit und 5 m hoch und dann im Krieg wieder 2m Höhe verloren hat, sondern es geht um drei Mauern an unterschiedlicher Stelle. Also ergeben sich 3 Wege. Die möchtest du für den Zeitbezug jetzt auch noch in je eine Relation dann also 3 Relationen stecken. Davon bekommst du aber die drei Wege nicht weg.
In meiner Heimatregion habe ich bereits mit einem Historischen Informationssystem (HIS) experimentiert, um historische Veränderungen zu dokumentieren.
Das funktioniert dann ungefähr so:
his:1905-:highway=residential
his:1905-1925:name=Kaiserstraße
his:1925-1945:name=Hindenburgstraße
his:1945-1990:name=Liebknechtstraße
his:1990-:name=Konrad-Adenauer-Straße
his:1907-1953:railway=tram
Daraus kann man dann die Kartendaten für ein bestimmtes Jahr, beispielsweise 1952, extrahieren.
Man kann ja irgendwann eine neue Datenbank eröffnen und die Daten dorthin exportieren. Jetzt geht es erstmal darum, etwas Neues auszuprobieren und den Virus der Begeisterung langsam, aber sicher zu verbreiten.
Mir fällt ja auch keine bessere Lösung für das Problem mehrerer Zeitabschnitte ein.
Allerdings würde ich die Einschränkung/Bedingung möglichst weit nach hinten setzen.
Also historic:name:1925-1935=* statt historic:1925-1935:name=*
Mir scheint, dass die Auswertung dann einfacher wird. Aber das hängt auch davon ab, was einem wichtiger ist: Zeitabschnitte oder Tagging.
Ach ja, für das Problem überlappender Jahre würde ich den 30.6. / 1.7. als Grenze nehmen.
In einer (zukünftigen) externen Datenbank können die Gewichtungen anders verteilt sein und solche Lösungen generell notwendig oder erlaubt sein.
Die Methode his:1945-1991:name=* hat den Vorteil, dass man einen Extrakt für ein bestimmtes Jahr erstellen kann:
Wähle alle Geodaten, die 1961 bereits vorhanden waren (!<Jahr1 && !>Jahr2), und übernehme sie in die Auswahl_1961.osm mit den jeweils gültigen Attributen highway=primary usw. Diese Datei kann man dann einem Renderer (z.B. Kosmos) übergeben und erhält eine Karte_1961.png mit den Namen und Straßen von 1961. Diesen Vorgang kann man dann Jahr für Jahr wiederholen und auf diese Weise eine Diashow über den historischen Zeitablauf erstellen.
Klar, wie ich schrieb ist es eine Frage, welche Prioritäten man setzt.
Besonders interessant fände ich übrigens wann welche Stadtviertel bebaut wurden. Also ein start_date an landuse=residential. Auch interessant was das vorher war, Acker / Kiesgrube / Industriegebiet / Müllhalde / …
ist eine Jahreszahl nicht zu ungenau? Es gibt ja bestimmte sehr bekannte Zeitpunkte, wo sich schlagartig die Objekte zu einem bestimmten Stichtag geändert haben.
