[Talk-de] key start_date

Ronnie Soak chaoschaos0909 at googlemail.com
Sa Nov 17 11:12:07 UTC 2012


Am 17. November 2012 11:54 schrieb Marcus Koenig <einschmelzer at hotmail.com>:

>>
>> start_date:<Bezugs-key> skaliert zwar hübsch, vergrößert aber mal eben
>> key-Namensraum auf das doppelte. (Oder dreifache, wenn wir das auch
>> für end_date machen.) Das sehen hier einige wahrscheinlich nicht so
>> gerne.
>
> Ist die größere Datenmenge hier das Problem?

Weniger die Datenmenge als die größere Anzahl an verschiedenen Keys.
Im Rahmen anderer Diskussionen
wurde oft dagegen argumentiert, dass keys 'variable' Elemente
enthalten, da wohl viele Datenauswerter zwingend eine fest definierte
Liste an Keys benötigen. So ganz ist diese Diskussion nie aufgelöst
wurden, da gerade Datenauswerter selbst auch meinten, so zwingend wäre
das gar nicht.
Das System <key>:<bezugskey> wäre nun auch nicht völlig variable,
sondern nur komplizierter als vorher, ich erwarte aber trotzdem
Gegenstimmen.

(Man müsste sowas als proposal Vorschlagen und ein Meinungsbild
einholen, ehe man es großflächig benutzt.)


>
>> Es gab glaub ich mal die Diskussion um built_date nur für das
>> Errichtungsdatum des physischen Objekts, das hilft allerdings auch
>> noch nicht viel weiter.
>
> built_date wäre für die Zwecke, die ich Moment im Sinn habe, durchaus geeignet und wäre ein eindeutig zuweisbarer key, der für jedes eigenständig erfasste physische Objekt möglich wäre und somit keine Kollisionen und Ambivalenzen erzeugen würde.

Sicher? Was ist mit Objekten, die an einem Ort gebaut, dann aber an
einem anderen Ort aufgestellt wurden. Ist built_date dann des
Erschaffungsdatum oder das Errichtungsdatum? Was, wenn es mehrere
große Bauabschnitte gab? Was, wenn etwas als Gasthaus errichtet, dann
aber als Schule umgebaut wurde? (Diese Diskuusion gab es schon mal
hier auf der Liste. Das sind so Argumente, an die ich mich noch
erinnere..).

>
> Ja, ich hatte mich auch schon gewundert, dass es bisher noch nicht mehr Ansätze in Richtung historical mapping gibt. Aber ich verstehe natürlich durchaus, dass die Zeitdimension die Datenmenge enorm vergrößern und das ganze sehr verkomplizieren würde. Trotzdem würde ich gerne schon mal erste Schritte machen.
>
Ich fände solch eine Datenbank auch höchst interessant. Ich sehe aber
ein, dass eine integration der Daten in OSM den eigentlichen Zweck von
OSM gefährden würde, da es den normalen Workflow doch extrem
verkompliziert. Klar würden historische Daten im Rendering
herausgefiltert. Aber man stelle sich mal die Rohdatenansicht z.B. in
JOSM vor, wenn ein paar Jahrhunderte an Daten dort übereinander
liegen. Kein Neuling würde sich trauen, dort noch etwas zu editieren.
Natürlich kann man auch dort Filtern, aber diese Filter müssten dann
in nahezu jedem OSM-basierenden Tool nachgerüstet werden. Für eine
effektive Filterung direkt durch die API existiert ja leider, wie
schon erwähnt, keine Unterstützung. (Spatiale Datenbanken arbeiten für
gewöhnlich nur 2D. 3D ist möglich, aber komplizierter. 4D hab ich
persönlich noch nie gesehen.)


Gruss,
Chaos




Mehr Informationen über die Mailingliste Talk-de