Lebenslauf von Objekten (Beispiel Bergbau)

Communities Deutschland (Germany)
21

Nahmd,

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.

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

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

22

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

23

Nahmd,

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

24

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.

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

25

Nahmd,

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?

Ja natürlich.

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.

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.

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

Gruß Wolf

26

Moin,

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.

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.

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