Zeit in OSM4D.

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.

Sprechen wir in 30 Jahren nochmal drüber wenn das Thema dann ein H-Kennzeichen hat. 😉

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.

marek kleciak wrote:

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.

Edbert (EvanE)

EvanE wrote:

- Objekte, die nicht mehr existieren sollten in einer Jetzt-Zeit Karte nicht erscheinen.
Keine Ahnung ob end_date dafür ausreichen würde.

Dafür gibts doch disused:tag=* historic:tag=* und abandonned:tag=*
Die müssten bei der historischen Betrachtung ihres Prefixes beraubt werden.

So könnte man auch eine Animation wandernder Tagebaue erstellen.

Gruß,
ajoessen

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.

ajoessen wrote:

EvanE wrote:

- Objekte, die nicht mehr existieren sollten in einer Jetzt-Zeit Karte nicht erscheinen.
Keine Ahnung ob end_date dafür ausreichen würde.

Dafür gibts doch disused:tag=* historic:tag=* und abandonned:tag=*
Die müssten bei der historischen Betrachtung ihres Prefixes beraubt werden.

So könnte man auch eine Animation wandernder Tagebaue erstellen.

Hallo ajoessen

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.

Edit: Typo

Edbert (EvanE)

Hallo Marek

marek kleciak wrote:

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.

So hört sich das für mich nach einem sinnvollen Ansatz an.

marek kleciak wrote:

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.

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

Edbert (EvanE)

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.

EvanE wrote:

marek kleciak wrote:

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.

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

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.

Gruß BBO

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?

Grüße,
Marek

BBO wrote:

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.

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

Gruß,
ajoessen

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?

Grüße,
Marek

ajoessen wrote:

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

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.

marek kleciak wrote:

BBO, kannst Du programmieren oder würdest du lieber an einem Testgebiet Was machen wollen?

Was Programmieren angeht: nur Grundlagen. Ich würde mich eher um Foren-/Wikipflege kümmern und natürlich testen wollen.

marek kleciak wrote:

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?

An welchen Server du deine gezeichneten Wege schickst lässt sich ja in JOSM einfach einstellen...

marek kleciak wrote:

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?

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.

Gruß,
ajoessen

BBO wrote:

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.

Das sollte verschmerzbar sein. Es wird ja keiner eine routingfähige Karte des römischen Reiches erstellen wollen ;-)

Gruß,
ajoessen

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

ajoessen wrote:

BBO wrote:

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.

Das sollte verschmerzbar sein. Es wird ja keiner eine routingfähige Karte des römischen Reiches erstellen wollen ;-)

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:

marek kleciak wrote:

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

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

ajoessen wrote:

BBO wrote:

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

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

Hallo ajoessen

Das kommt ja immer darauf an. 😉

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.

Edbert (EvanE)

ajoessen wrote:

marek kleciak wrote:

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?

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.

Gruß,
ajoessen

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.

BBO wrote:

ajoessen wrote:

BBO wrote:

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.

Das sollte verschmerzbar sein. Es wird ja keiner eine routingfähige Karte des römischen Reiches erstellen wollen ;-)

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?

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.

viw wrote:

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/G … 5_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...

marek kleciak wrote:

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 Bauchgefühl sagt mir, dass außerhalb der großen OSM Lösung Projekte nur eine Randexistenz führen.
...

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.

Edbert (EvanE)

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.

marek kleciak wrote:

Kannst Du die Lösung aufskizzieren und in Wiki platzieren?
Was wäre in der API 7 zu ändern?
Was in der Grundstruktur?

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.

marek kleciak wrote:

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

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.

Edbert (EvanE)

BBO wrote:

viw wrote:

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.

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.

FK270673 wrote:

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
....
Daraus kann man dann die Kartendaten für ein bestimmtes Jahr, beispielsweise 1952, extrahieren.

Und wieder das Problem Werte im Schlüssel zu haben.
Diese Methode ist ziemlich umstritten bei OSM.

JM2C
Edbert (EvanE)

Und: Wenn ich das Jahr 1925 betrachten will, werde ich dann Kaiserstraße oder Hindenburgstraße angezeigt bekommen?

errt wrote:

Und: Wenn ich das Jahr 1925 betrachten will, werde ich dann Kaiserstraße oder Hindenburgstraße angezeigt bekommen?

Das hängt vom Renderer ab. Entweder man definiert den 1.1. oder den 31.12. als Standarddatum.

Eine tagesgenaue Darstellung wäre technisch möglich, aber die entsprechenden Daten stehen leider nicht zur Verfügung.

EvanE wrote:

Und wieder das Problem Werte im Schlüssel zu haben.
Diese Methode ist ziemlich umstritten bei OSM.

JM2C
Edbert (EvanE)

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.

FK270673 wrote:

EvanE wrote:

Und wieder das Problem Werte im Schlüssel zu haben.
Diese Methode ist ziemlich umstritten bei OSM.

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.

Edbert (EvanE)

EvanE wrote:

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.

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.

Gruß FK270673

FK270673 wrote:

Die Methode his:1945-1991:name=* hat den Vorteil, dass man einen Extrakt für ein bestimmtes Jahr erstellen kann:
...

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

Edbert (EvanE)

Liebe Leute,
könnt Ihr vielleicht in dem OSM-4D Proposal Abschnitt Zeit, einen Unterabschnitt wo man diese Ideen an einem Ort hätte?

Ich finde das alles wirklich super und danke bei der Gelegenheit dem guten Geist der bereits diesen Abschnitt richtig gut erweitert hat 😬)

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.

Jahreszahl sollte man (denk ich mir) nur dann nehmen, wenn genaueres Datum unbekannt ist.

marek kleciak wrote:

Jahreszahl sollte man (denk ich mir) nur dann nehmen, wenn genaueres Datum unbekannt ist.

Das kommt darauf, was du betrachtest.
- 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.

Edbert (EvanE)

EvanE wrote:

Je weiter man in die Vergangenheit geht, desto ungenauer werden die Quellen und man kommt auch bequem mit Jahr/Jahrzehnt/Jahrhundert aus.

Nur wie drückt man letzeres mit date_on oder his:* aus?

gruß,
ajoessen

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.

ajoessen wrote:

EvanE wrote:

Je weiter man in die Vergangenheit geht, desto ungenauer werden die Quellen und man kommt auch bequem mit Jahr/Jahrzehnt/Jahrhundert aus.

Nur wie drückt man letzeres mit date_on oder his:* aus?

In http://wiki.openstreetmap.org/wiki/Key:start_date ist es ziemlich gut beschrieben, wie man auch ungefähre Datumsangaben machen kann. Das kann/sollte man meines Erachtens übernehmen.

Was ggfs. hinzukommt ist, dass man einen Bereich von-bis angeben kann.

Edbert (EvanE)

marek kleciak wrote:

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.

Gerade bei Groß-Objekten mit Jahrzenten oder mehr Bauzeit müsste/sollte man dann aber auch die Bauperiode (ggfs. auch die von Teilabschnitten) eintragen. Denn schon in der Bauzeit wird eine solche Groß-Baustelle das Stadtbild stark prägen.

Edbert (EvanE)

Mach einen Wiki Vorschlag dafür - an einem bekannten Beispiel.

marek kleciak wrote:

Mach einen Wiki Vorschlag dafür - an einem bekannten Beispiel.

Sorry, ich habe schon zu viele Baustellen.
Die beiden von dir genannten Kirchen Kölner Dom mit mehreren hundert Jahren Bauzeit (und einer sehr langen Unterbrechung) sowie die Sagrada Familia in Barcelona sind meines Erachtens sehr gute und auch bekannte Beispiele für das Problem von Jahrzehnten/Jahrhunderten langen Bauzeiten.

Edbert (EvanE)

EvanE wrote:

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.

Eine Straße wurde und wird normalerweise in mehreren Abschnitten gebaut. Zuerst wird der Weg planiert, dann kommt eine Schotterdecke drauf, dann eine erste Asphaltschicht, dann wird der Bürgersteig gebaut, dann wird die Straßenbeleuchtung eingeschaltet und die Straßenschilder werden aufgestellt und irgendwann kommt der Bürgermeister. Das alles spielt sich innerhalb von ein bis zwei Jahren ab. Aus juristischen Gründen wird die Straße erst ein bis zwei Jahre nach Fertigstellung offiziell gewidmet, damit die Gemeinde für alle bis dahin entstandenen Schäden nicht haften muss.

EvanE wrote:

Je näher man an die Jetzt-Zeit heran geht, desto eher interessieren auch Monat und Tag.

OSM kann ja die Bauarbeiter ermahnen, vor Beginn der Bauarbeiten construction:start_date einzugeben ;-) Für uns ist die taggenaue Angabe des Baubeginns ja fast noch wichtiger als die Absicherung der Baustelle ;-) Obwohl pylon=yes die Genauigkeit der Karte ungemein erhöhen würde ;-) Die Unfallversicherung weiß dann, dass dort gearbeitet wird, und kann das Gebiet ggf. kontrollieren.

Gruß FK270673

EvanE wrote:

Gerade bei Groß-Objekten mit Jahrzenten oder mehr Bauzeit müsste/sollte man dann aber auch die Bauperiode (ggfs. auch die von Teilabschnitten) eintragen. Denn schon in der Bauzeit wird eine solche Groß-Baustelle das Stadtbild stark prägen.

Ich habe über construction:start_date ( danke FK270673) sowie construction:end_date nachgedacht. Es ist wahrscheinlich DIE Lösung für das Problem extrem lange gebauter Objekte (wie Kölner Dom beispielsweise).
Ab dem Zeitpunkte der Einweihung würde dann start_date: gelten.

Bei Gelegenheit baue ich´s in Wiki ein.