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.
Eine Kirche als Gebäude wird ja (idR) nicht an einem Tag erbaut.
Anders ist es bei der Nutzung.
Es gibt einen definierten Tag an dem eine Kirche geweiht wird.
Wenn du jetzt z.B. Stadtviertel als Fläche betrachtest, spielt Tag und Monat eigentlich keine große Rolle, da die die Entwicklung eines Neubaugebietes sich eigentlich immer über mehrere Jahre hinzieht.
Je näher man an die Jetzt-Zeit heran geht, desto eher interessieren auch Monat und Tag. Je weiter man in die Vergangenheit geht, desto ungenauer werden die Quellen und man kommt auch bequem mit Jahr/Jahrzehnt/Jahrhundert aus.
Hallo Edbert,
ich würde für Gebäude den Tag der “Abgabe”: Einweihung, Fertigstellung etc nehmen. Im Falle berühmter Bauwerke die über Jahrhunderte gebaut wurden (Kölner Dom) ist es oft so, dass ein Bauabschnitt nach Fertigstellung verwendet wurde (In der Regel Presybiterium oder Seitenschiff als Abschnitt 1) Für solche Bauwerke würde ich quantisieren und die einzelnen Bauabschnitte mit “Abgabedatum” taggen.
Ich denke, es ist der einzige Ausweg, denn sonst müssen wir z.B die Sagrada Familia in Barcelona entfernen, weil sie immer noch nicth fertig ist.
