Lebenslauf von Objekten (Beispiel Bergbau)

Nahmd,

Zecke wrote:

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

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 “ @ <Zeitraum>” 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.

Netzwolf wrote:

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

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/c … ecken6.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/Comp … e_concepts

Nahmd,

Zecke wrote:

Netzwolf wrote:

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

Darum geht es mir gar nicht (auch wenn ich diesbzgl. einen anderen Standpunkt vertrete).

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

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.

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! 😉

Gruß Wolf

geri-oc wrote:

Vielleicht eine etwas andere Idee:
Im WIKI eine Seite anlegen - ähnlich dieser Himmelfahrt Fundgrube und auf diese dann verlinken.

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/Comp … e_concepts

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

<main tag>:timeframe:<Zeitpunkt> oder <Zeitspanne> = <value>
ggü. dem genannten
<main tag>:<Zeitpunkt> oder <Zeitspanne> = <value>

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,

Zecke wrote:

Ich würde persönlich etwas in der Form

<main tag>:timeframe:<Zeitpunkt> oder <Zeitspanne> = <value>
ggü. dem genannten
<main tag>:<Zeitpunkt> oder <Zeitspanne> = <value>

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

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.

Weiß jemand, ob so etwas schon von irgendwelchen Karten umgesetzt wird?

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.

Wäre das was für die historische Karte?

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

Netzwolf wrote:

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.

Hallo Wolf

Wollte gerade etwas vergleichbares schreiben. 🙂

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)

Netzwolf wrote:

Wie umgesetzt? Ein Zeit-Schieberegler als Bedienelement am Rand einer Karte?
..
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.

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

Netzwolf wrote:

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.

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.

EvanE wrote:

Netzwolf wrote:

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.

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

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

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.

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.

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

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

Zecke wrote:

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.

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

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.

Was ist mit Zeitpunkten? Gibt's dafür auch ein Tag (date?) oder nimmt man start_date=end_date?

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

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

Zecke wrote:

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? 😄

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

Nahmd,

reneman wrote:

Hast du meine Mail von hier gestern Nachmittag bekommen? Oder hat die der SPAM gefressen? 😄

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

[×] gefixt.

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

Gruß Wolf

Netzwolf wrote:

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.

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

Nahmd,

Zecke wrote:

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.

Redundanz ist nichts schlechtes. Daten aus mehreren Quellen zusammensuchen müssen dagegen schon. Sag ich mal so.

Speichern in einer Normalform ist bei den ungeheuren Datenmengen zu teuer. Eine ähnliche Diskussion hatten wir vor längerer Zeit bezüglich der Aufteilung von Wanderwegen und Zusammenfassung der Teilstücke mit einer Masterrelation: die Normalform wäre, den Namen ausschließlich in die Masterrelation zu packen und von da an die Kinder zu vererben: Man würde aber jedem Renderer die Last aufdrücken, die “Vererbung” der Felder aus der Masterrelation an die Kinder zu realisieren.

Man überlege sich auch, dass eine meiner “type=feature”-Relationen selbst keinen Namen trägt, aber zwei Ways enthält, die beide benamst sind, aber unterschiedliche Namen tragen.

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.

Mir ist es gleichgültig; die meisten Verarbeiter aber werden Dich treten für diese Idee (Obacht wenn ein schwarzer Van mit getönten Scheiben vor dem Haus steht).

Wie würden bei deinem Vorschlag punktuelle Ereignisse getaggt?

Gar nicht. Lassen sich nicht darstellen.

Wenn man wirklich die Schließung eines Bergwerkes am aa.bb.cccc speichern will, dann legt man ein Objekt für exakt diesen Tag an, lässt die Ära davor am Tag davor enden und die nächste Ära am Tag danach beginnen.

Nur wird man mit einem Zeitslider kaum exakt diesen Tag treffen.

Gruß Wolf

Netzwolf wrote:

reneman wrote:

Hast du meine Mail von hier gestern Nachmittag bekommen? Oder hat die der SPAM gefressen? 😄

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. 🙁
[×] gefixt.
Und Mailsystem von www.openstreetmap.org ist ohnehin in Dauerbenutzung.

Edit: Deine Mail vor 3 Std. und vor 15min landete nun bei mir im Spam, dafür die dritte nicht 😄 Danke, muss jetzt erstmal lesen 🙂

Nahmd,

reneman wrote:

[×] gefixt.

Bist du sicher?

Ja.
Nur die Forenadresse war alt, in Userpage und Wiki ist die richtige eingetragen, und die funktioniert auch (von web.de aus probiert). Die Wegwerf-Emailadresse funktioniert auch.

Ich tippe mal auf kurzzeitigen Serverschluckauf. (Irgendwas ist ja immer.™)

Antwort ist 2× raus, einmal von Web.de.

Gruß Wolf

Netzwolf wrote:

Redundanz ist nichts schlechtes. Daten aus mehreren Quellen zusammensuchen müssen dagegen schon. Sag ich mal so.

Speichern in einer Normalform ist bei den ungeheuren Datenmengen zu teuer. Eine ähnliche Diskussion hatten wir vor längerer Zeit bezüglich der Aufteilung von Wanderwegen und Zusammenfassung der Teilstücke mit einer Masterrelation: die Normalform wäre, den Namen ausschließlich in die Masterrelation zu packen und von da an die Kinder zu vererben: Man würde aber jedem Renderer die Last aufdrücken, die “Vererbung” der Felder aus der Masterrelation an die Kinder zu realisieren.

Ich sehe das weniger von der Seite des Implementierers als von der des Designers. Am Anfang sollte eine saubere Datenstruktur stehen. Daran mangelt es bei OSM an so einigen Stellen. Man sollte es m.E. so sauber (und das heißt für mich - so orthogonal wie möglich) machen. Rechner werden ohnehin immer schneller, d.h. die Auswertung wird schon nachkommen.

Wenn ich im Wiki diese Seite (http://wiki.openstreetmap.org/wiki/DE:Relation:route) ansehe, scheint aber für Wanderwege der favorisierte Weg schon die Relation zu sein. Warum das dann nicht für die Master-Relation gelten soll, kann ich schwer nachvollziehen.

Mir ist es gleichgültig; die meisten Verarbeiter aber werden Dich treten für diese Idee (Obacht wenn ein schwarzer Van mit getönten Scheiben vor dem Haus steht).

Viele scheint leider das Thema eher kaum zu interessieren, wenn ich mir die Zahl der Beiträge so anschaue.

Punktuelle Ereignisse sollten in einer historischen Karte schon erfassbar sein. Die Idee des Timesliders ist ja nicht die einzig mögliche Art der Darstellung. Dass es damit schwierig würde, ist mir auch klar.

Gruß,
Zecke

Nahmd,

Zecke wrote:

Ich sehe das weniger von der Seite des Implementierers als von der des Designers. Am Anfang sollte eine saubere Datenstruktur stehen. Daran mangelt es bei OSM an so einigen Stellen. Man sollte es m.E. so sauber (und das heißt für mich - so orthogonal wie möglich) machen.

Genau das will ich auch.

Deine Vorgabe: Einsparung redundanter Tags:

Konsequenz 1:

Basiselement: Way

tourism=hostel
name=Schacht7
start_date=1980

History-Element: Relation

start_date=1900
end_date=1980
man_made=adit
member: das Basiselement.

Du willst, dass "name=" vom Basiselement kopiert wird.
Wieso nicht auch das "tourism=" ???

Konsequenz 2:

Basiselement: Way

tourism=attraction
name=Schacht7
start_date=1980

History-Element: Relation

start_date=1900
end_date=1980
man_made=adit
member: das Basiselement.

Heute in der Zeitung: der Freizeitparkt wird umbenannt.
Ich ruf gleich den JOSM auf und ändere:

Basiselement: Way

tourism=attraction
name=Freizeitpark über und unter Tage
start_date=1980

History-Element: Relation

start_date=1900
end_date=1980
man_made=adit
member: das Basiselement.

Was steht jetzt auf der Geschichtskarte? Ooooooops!

Du verstehst, warum ich alle Tags an der Relation haben und keine von der Geometrie erben möchte?

Wenn ich im Wiki diese Seite (http://wiki.openstreetmap.org/wiki/DE:Relation:route) ansehe, scheint aber für Wanderwege der favorisierte Weg schon die Relation zu sein.

Ja natürlich.

Warum das dann nicht für die Master-Relation gelten soll, kann ich schwer nachvollziehen.

Es geht um die großen Langstreckenwanderwege. Die haben mehr als 2k Way-Member, müssen also gesplittet werden in Abschnitte. Bei den En-Wegen zB nach Bundesländern. Jede Relation beschreibt einen Wegabschnitt. Die Masterrelation fasst die Wegabschnitte zusammen.

In der Normalform würden “name=”, “ref=” usw. ausschließlich an der Masterrelation gespeichert und an die Member, also die Teilstrecken-Relationen vererbt. In der Realität speichert man alle Tags an alle Relationen.

Viele scheint leider das Thema eher kaum zu interessieren, wenn ich mir die Zahl der Beiträge so anschaue.

Warum sollte es? Wenn es gut gemacht ist, interagiert das Tagging nicht mit dem normalen Tagging. Dann interessiert es nur noch den, der eintragen möchte, und den, der darstellen möchte. Die meisten gehören weder zur ersten noch zur zweiten Gruppe.

Punktuelle Ereignisse sollten in einer historischen Karte schon erfassbar sein. Die Idee des Timesliders ist ja nicht die einzig mögliche Art der Darstellung. Dass es damit schwierig würde, ist mir auch klar.

Dann setz' start_date und end_date auf den gleichen Wert und gib der Relation ein “type=dirac”.

Gruß Wolf

Moin,

Netzwolf wrote:

Du willst, dass "name=" vom Basiselement kopiert wird.
Wieso nicht auch das "tourism=" ???
...
Was steht jetzt auf der Geschichtskarte? Ooooooops!
...
Du verstehst, warum ich alle Tags an der Relation haben und keine von der Geometrie erben möchte?

Guter Einwand! Habe ich bisher nicht bedacht. Also doch nur den Objekttyp (Punkt, way etc.) und die Koordinaten erben, den Rest pro Zeitabschnitt vollständig setzen. Die Alternative wäre, die Gegenwart nur im letzten Zeitabschnitt zu beschreiben, aber dann wäre die Kompatibilität zu konventionellen Renderern hinüber.

Netzwolf wrote:

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

Natürlich könnte man hierein die Attribute stecken, die für alle Zeitphasen gleich sind. Dann wäre das Problem mit den klassischen Renderern vom Tisch. Am Objekt stehen dann alle in der Gegenwart gültigen Tags (also im Endeffekt eine Wiederholung statt n Wiederholungen). Man könnte es dann auch dem Mapper überlassen, er kann es so machen wie es ihm lieber ist.

Netzwolf wrote:

Punktuelle Ereignisse sollten in einer historischen Karte schon erfassbar sein. Die Idee des Timesliders ist ja nicht die einzig mögliche Art der Darstellung. Dass es damit schwierig würde, ist mir auch klar.

Dann setz' start_date und end_date auf den gleichen Wert und gib der Relation ein “type=dirac”.

Westfrankreich ist nicht so mein Hauptaktivitätsgebiet (http://www.openstreetmap.org/browse/relation/111314)!

Scherz beiseite, so etwas in der Art hatte ich ja auch angedacht.
Ich habe das Gefühl, es könnte konvergieren.

Gruß,
Zecke