Lebenslauf von Objekten (Beispiel Bergbau)

Ich tagge in der letzten Zeit einige Bergwerksanlagen, insbes. Schächte. Dabei gibt es verschiedene milestones

  • Baubeginn (Beginn der Abteufung)
  • Inbetriebnahme
  • Umnutzung (z.B. von Förderschacht zu Luftschacht)
  • Stillegung (-> disused)
  • Abbau des Fördergerüsts (ab hier würde ich abandoned verwenden)
  • Teilverfüllung (Ich habe ein Beispiel, in dem ein Schacht im oberen Bereich verfüllt wurde, daneben wurde ein neuer Schacht abgeteuft und ab Teufe X mit dem alten Schacht verbunden, ab Teufe X der alte Schacht weiterverwendet)
  • Verfüllung
  • Abdeckung (üblicherweise eine Betonplatte mit Inspektionsluken)
    etc.

Ich versuche, das aktuell mit start_date, end_date, disused, abandoned in den Griff zu bekommen, aber so richtig zufriedenstellend ist das nicht. Die übrige Information stecke ich notgedrungen in die description.

Beispiel: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=18&lat=49.27805&lon=6.97177&layers=BTT

Gibt es generalisierte Ansätze, den Lifecycle von Objekten zu erfassen?

Nahmd,

Nicht dass ich wüsste. Du könntest aber etwas entwerfen ähnlich zu Conditional restriction: ein Suffix (z.B. “:timeframe”) angehängt an “normale” Keys und ein “ @ ” angehängt an den ”normalen” Wert, um die Gültigkeit eines Tags nur in einem bestimmten Zeitraum auszudrücken.

Meines Wissens ist aber das Tagging von nicht mehr sichtbaren Objekten eher unerwünscht.

Gruß Wolf

Vielleicht eine etwas andere Idee:

Im WIKI eine Seite anlegen - ähnlich dieser Himmelfahrt Fundgrube und auf diese dann verlinken. Vorallem bekommt man reichlich Informationen unter.

Könnte mir dieses sogar unter einer übergeordneten Seite “Historsiche Schachtanlagen” und/oder nach Ländern und Regionen sortiert vorstellen.

Darum geht es mir gar nicht (auch wenn ich diesbzgl. einen anderen Standpunkt vertrete). Die Objekte, um die es geht, sind durchaus sichtbar, selbst wenn sie seit teilweise 80 Jahren nicht mehr genutzt werden. Hier ein Beispiel: Steinbachschacht der Grube Von der Heydt, die Grube wurde bereits 1932 stillgelegt, seitdem wird der Schacht nicht mehr genutzt.

http://upload.wikimedia.org/wikipedia/commons/thumb/0/07/20110602Steinbachschacht_Saarbruecken6.jpg/1280px-20110602Steinbachschacht_Saarbruecken6.jpg

Viele stehen noch heute unter Bergaufsicht, z.B. weil die Möglichkeit austretenden Grubengases (Methan) besteht, oder die von Senkungen aufgrund Sackungen der Verfüllung.

Ich kenne mich nun leider nicht so mit Bergbau aus. Wenn es noch sichtbar ist, kannst du das natürlich gerne modellieren.
Leider ist OSM in Hinwsicht auf die Zeitachse noch nicht so ausgereift:
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

Nahmd,

Ich auch. Ich kann den auch ausformulieren: solange es nicht so etwas wie PermaIds gibt, über die man externe Datenbanken andocken kann, solange soll man auch Daten dulden, die eigentlich anderswohin gehören.

Aber zurück zum Thema.

Der Vorschlag mit dem “:timespan” war durchaus ernst gemeint. :sunglasses:

Der ganze Bergbau ist ein spannendes Thema. Interessiert mich auch deshalb, weil ich bereits unter Tage gearbeitet habe, in Bochum und im Saarland. Und nicht als Grubenhunt! :wink:

Gruß Wolf

Das ist immer gut, aber hier weniger meine Fragestellung. Wiki- und Webseiten gibt es bereits für viele der Anlagen, wenn nicht kann und sollte man sie natürlich erstellen (so man genügend Informationen hat).
Mir geht es eher darum, bestimmte, immer wiederkehrende Eckdaten unterbringen zu können. Darunter natürlich auch Links zu Wikipedia oder Webseiten (aber das gibt OSM ja bereits her).

Mir ist einfach nur start_date und end_date etwas zu wenig. Und v.a. zu wenig definiert: Ist end_date nun der Zeitpunkt der Stillegung oder der Verfüllung? Dazwischen können viele Jahrzehnte liegen.

Netzwolfs Vorschlag zeigt, glaube ich, eine brauchbare Richtung auf, ich werde mal in die Richtung nachdenken.

Danke für eure Anregungen!

Habe mir mal das erwähnte Lifecycle-Konzept angesehen.
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

Das letztgenannte Konzept läuft im übrigen ziemlich auf den Vorschlag von Netzwolf hinaus. Ich würde persönlich etwas in der Form

:timeframe: oder = ggü. dem genannten : oder =

vorziehen, weil damit klar ist, daß nach dem 2. Doppelpunkt ein Zeitwert kommt.

Weiß jemand, ob so etwas schon von irgendwelchen Karten umgesetzt wird?
Wäre das was für die historische Karte?

Nahmd,

Wenn man die (hier zeitliche) Bedingung in das Tag aufnimmt, bläst man die Menge der verwendeten Tags auf. Außerdem kann abhängig von der Art des verwendeten Index kann die Suche nach Objekten mit Zeitbezug in einer Datenbank deutlich langsamer werden.

Wie umgesetzt? Ein Zeit-Schieberegler als Bedienelement am Rand einer Karte?

Da die Hintergrundkarte immer den Zustand heute anzeigt und nur ein minimaler Anteil der Objekte mit einer Zeitdimension ausgestattet werden wird, würde die Leiste nur in intensiv bearbeiteten (Showcase-)Gebieten wirklich Freude machen. Ähnlich wie bei 3D.

Was soll dargestellt werden? Soll sich das Icon je nach eingestelltem Jahr ändern? Das einzubauen ist trivial. Sofern der Lutz zustimmt und jemand die Icons bereitstellt.

Ob Du den Zeitraum in das Tag oder in den Value setzt, das würde ich aber noch einmal diskutieren. Mit den Erfindern der Conditional restrictions, vielleicht auch mit den Planern von Historic OSM, und natürlich mit allen hier, die Daten auswerten/rendern und/oder sich mit den Geo-Datenbanken auskennen.

Zeitaum/Condition im Key sieht viel schöner aus und ist auch angenehmer zu editieren, Zeitraum/Condition im Value ist technisch sauberer. Beim Conditional Access hätte ich definitiv für “im Value” gestimmt, weil alle Werte auf einmal erfasst werden und auch auf einmal in das Feld eingetragen werden.

Bei der historischen Zeitskala kann von verschiedenen Leuten ergänzt werden und es sind – anders als bei Conditional Access – im Grunde unbegrenzt viele Einträge zu einem Tag möglich. Hier bin ich mir unklar, welche Art der Schlüsselung besser ist.

Gruß Wolf

Hallo Wolf

Wollte gerade etwas vergleichbares schreiben. :slight_smile:

Die Zeitangabe gehört für mich eindeutig in den Wert. Das Schema für Conditional restrictions hat ja eine Weg gezeigt wie das gehen kann: Wert @ (Bedingung / Zeitangabe). In dem Schema sind auch mehrere Werte in einem Tag möglich. Auch das kann man übernehmen. Problematisch wird der Fall erst dann, wenn die Textlänge im Wert nicht mehr ausreicht. Dafür müsste man sich dann noch etwas ausdenken.

Das schöne an “schlüssel:timeframe” ist ja, dass man es für jeden Schlüssel, bei dem das wichtig erscheint, nutzen kann und so einen kompletten Lebenszyklus erfassen kann. Beipiel Kirchen: Bauzeit, Kirche, Lagerraum, Kirche, disused, abandoned, …

Edbert (EvanE)

Nein, dachte eher an etwas anklickbares: Man markiert ein Objekt auf der Karte, klickt auf einen Knopf und bekommt (z.B. tabellarisch) dessen Lebenslauf in einem Popup erzählt. Die historische Karte listet derzeit halt alle Tags, muss also das spezielle Verfahren für Lifecycle nicht “verstehen”.

Irgendwie fehlt mir ein Datentyp “Tabelle” oder “dictionary” in OSM, also eine collection von key=value. Man hätte als keys Zeitpunkte oder -perioden und als values beschreibende Werte. Die ganze Tabelle würde man einem Attribut “lifecycle” des beschriebenen Objekts zuordnen.

Mit einigen Schönheitsfehlern: das “;” als Trenner für Subausdrücke ist äußerst unglücklich gewählt.

Zum einen, weil es in den Bedingungen und auch in den Werten vorkommen kann. Das Vorkommen in den Bedingungen hat man mit dem “dann klammern wir das halt” “berücksichtigt” mit dem Ergebnis, dass man nicht mehr mit einem Regex in Subfelder aufteilen kann.

Zum anderen, weil die übliche Bedeutung “Zusammenfügen von Werten zu einem Set gleichberechtigter Werte” hier abgeändert ist zu “Erstellung einer Folge von Werten, bei der die Reihenfolge relevant ist”. Unschön.

Außerdem sind “@” und “;” nicht mehr in Datenwert erlaubt. Das ist für die Access Restrictions akzeptabel, für ein allgemeines Tagging aber nicht mehr: “amenity=pub; name=drunk@home”.

Also mal “eben so” das Konzept der “Connditional Restrictions” auf “timeframe” zu übernehmen halte ich für zu kurz gedacht und keine wirklich gute Idee. Die Einschränkungen machen das System unflexibel.

Ich würde auf jeden Fall abändern:

(1) einen anderen Gruppentrenner; das “;” ist völlig inakzeptabel.
(2) die Zeitangabe nach vorne, mit z.B. einem ”:” abgeschlossen. Dann sind wieder alle Datenwerte möglich.


shop:timeframe = 1800:bakery ¦ 1900: bakery;butcher ¦ 2000: stationary

Ich kann mich aber auch (modulo des Aufblasens der Keymenge und der möglicherweise langsameren Suche) anfreunden mit:


shop:timeframe:1 = 1800: bakery
shop:timeframe:2 = 1900: bakery;butcher
shop:timeframe:3 = 2000: stationary

was im Editor sehr angenehm zu bearbeiten ist (solange man nichts einfügen will :wink: ).
Von da ist es aber nur ein kleiner Schritt zu:


shop:timeframe:1800 = bakery
shop:timeframe:1900 = bakery;butcher
shop:timeframe:2000 = stationary

wo der Editor sogar nach Zeit sortiert. Hier möglich, weil es nur banale Zeitangaben gibt im Unterschied zu “Conditional Restrictions” mit seinen höchst vielgestaltigen Bedingungen.

Ich bin mir wirklich nicht sicher, was das richtige ist.

Aber egal, was entschieden wird: so gewünscht, realisiere ich die Anzeige für die Geschichtskarte.

Gruß Wolf

Der Vollständigkeit halber hier noch ein Ansatz mit Relationen:
http://wiki.openstreetmap.org/wiki/DE:OSM-4D#Tagging_2

Gruß
BBO

Eigentlich gefällt mir der Relationsansatz (so wie du ihn beschrieben hast) ganz gut, auch wenn das die Daten etwas aufbläht. Es sieht sauber und flexibel aus. Im Prinzip brauchst du für jede Zeitspanne eine eigene Relation. Was ist mit Zeitpunkten? Gibt’s dafür auch ein Tag (date?) oder nimmt man start_date=end_date?

Nahmd,

Da das “type=usage” noch nicht in Benutzung ist, könnte man statt dessen “type=feature” wählen und grundsätzlich alle Objekte so erfassen. Dann hätten wir das Format, das unsere kommerzielle Konkurrenz schon seit einem Jahrzehnt nutzt: die Geometrie völlig getrennt von der Semantik; und das viele Probleme löst und und ebenso viele Diskussionen überflüssig macht.

Bis auf das Problem, dass ich für diese Äußerung gesteingt werden werde: “er hat Jehova gesagt”. :confused:

Aber im Ernst: wenn diese Lösung, dann bitte alle relevanten Tags in die Relation und nicht nur die gegenüber dem “Basiseintrag” geänderten. Dann ist der Einbau in die Geschichtskarte nur eine Sache von wenigen Stunden. Und Daten erfassen macht ja nur dann wirklich Spaß, wenn sie auch irgendwo dargestellt oder genutzt werden.

Wenn eine Eigenschaft nur für eine infinitesimal kurze Zeitspanne gilt, erwischt man den Zeitpunkt mit dem Zeit-Slider ohnehin nicht und kann deshalb auf die Erfassung verzichten. :wink:

Gruß Wolf

Ausgehend von der Idee einer Relation habe ich mal einen Entwurf erstellt. Ich verwende zu einem realen Objekt drei Sorten von Relationen:

  1. Eine Lifecycle-Relation (type=lifecycle). Sie hat 1…n Elemente der Rolle “member” (reale Objekte). Des weiteren 1…m Elemente der Rolle time_element. Diese beschreiben entweder einen Zeitpunkt oder eine Zeitspanne und sind selbst Relationen der Typen date oder timespan.

  2. Date-Relation (type=date)
    Rolle: member (das Objekt/die Objekte, für die ein Ereignis beschrieben wird)
    Pflicht-Attribut: date=
    optionale Attribute, darunter üblicherweise description

  3. Timespan-Relation (type=timespan)
    Ähnlich der Date-Relation, statt eines Date-Attributs gibt es jedoch ein start_date und ein end_date

Damit man sich das besser vorstellen kann, habe ich mal für den Amelung-Schacht (http://www.openstreetmap.org/browse/node/416885580) eine solche Lifecycle-Relation (2788299) erstellt.

Die einzelnen Attribute sind nicht perfekt, ich habe z.T. deutsche Begriffe verwendet, weil mir englische nicht geläufig sind, es geht aber eher um’s allgemeine Prinzip.
Ich freue mich auf Kommentare.

Ich würde die Beziehungen rumdrehen, das Konstrukt auf zwei Typen beschränken, von denen einer auch anderweitig benutzt werden kann, und damit auch Umwidmungen beschreiben können:

(1)
nodes/ways mit Tags für die heutige Nutzung und unbedingt einem mit start_date, so dass ein time-enabled history das Objekt für die Zeit davor tilgen kann. Und “normale” Renderer rendern das Objekt ganz normal.

(2)
n× eine “type=feature”-Relation, die eine Auswahl von Ways/Nodes/ als Member hat, unbedingt start_date und end_date, und (jetzt kommts) alle tags, die das Objekt in dem angegebenen Zeitraum beschreiben. Das heißt, das bspw. der Name des Objektes n× wiederholt wird. Denn der Name hätte sich ja auch ändern können. Normale Renderer kennen den type=feature nicht und rendern den auch nicht. Wer den type auszuwerten beginnt, muss auch start/end_date berücksichtigen. Aufwärtskompatibel.

Die n Einträge sind also unabhängig voneinander und sie können völlig unabhängig voneinander gerendert werden. Ein History/Time-Enabled Renderer wird die und nur die Objekte rendern, die nach start/end-date für den jeweiligen Zeitpunkt existieren. Und wenn diese Zeiträume sich nicht überschneiden, wird immer höchstens ein Objekt dargestellt. Dass die n Einträge zusammengehören, wird hier überhaupt nicht ausgedrückt; denn es ist weder für gerenderte Tiles noch für dynamische Overlays von irgendeiner Bedeutung. Deshalb werden auch alle relevanten Tags in allen n Rels gespeichert.

(3)
Dass die Entwicklungsstufen zusammengehören, wird in einer eigenen Relation gespeichert. Diese wird von Renderern völlig ignoriert. Sie wird nur von nichtgeographischen Auswertungen und von Menschen genutzt, und enthält als Mitglieder genau die n Einträge aus (2).

Das war’s schon. Nachteilig ist, dass man Tags wie den Namen mehrfach eingeben muss; das verschafft aber auch eine hohe Flexibilität. Vorteilig ist, das bestehende Renderer nicht gestört werden, die Erweiterung zu history/time-awareness mit sehr geringem Aufwand realisiert werden kann.
Für die Geschichtskarte schätze ich (nur die Technik) maximal ein Wochenende, wobei die Jahr und/oder Datumseingabe die meiste Arbeit machen wird. Das Erstellen der zur Darstellung nötigen Icons braucht wahrscheinlich länger (außer wenn man reneman überzeugt oder besticht).

Just my 2.38¢

Gruß Wolf

@Wolf: OT: Hast du meine Mail von hier gestern Nachmittag bekommen? Oder hat die der SPAM gefressen? :smiley:

Edit: Danke Wolf. Die Mail ist erneut raus :slight_smile: Zum glück kann man im Browser einfach so lange zuück gehen, bis man die Mail inkl. Text wieder angezeigt bekommt :smiley:

Nahmd,

Nein.
Die ist im Datennirvana gelandet, alldieweil die Email-Adresse in der Forenverwaltung veraltet war. Mist! Jetzt muss ich wieder in den Keller und die Geißel suchen. :frowning:

[×] gefixt.

Und Mailsystem von www.openstreetmap.org ist ohnehin in Dauerbenutzung.

Gruß Wolf

Erst mal danke für die intensive Beschäftigung mit dem Thema.

Wenn man Tags, die für die gesamte Lebensdauer gelten, in das Main-Objekt steckte (wie bei meinem Vorschlag), würden die konventionellen Renderer auch nicht gestört (sie werten die Lifecycle-Relation nicht aus), man vermeidet aber viel Redundanz. Evtl. würde das Rendern etwas aufwendiger. Der (historische) Renderer muß die passende Relation aus der Lifecycle-Relation ziehen + die Tags des main-Objektes hinzumischen.

Wie würden bei deinem Vorschlag punktuelle Ereignisse getaggt?

Gruß,
Zecke