Am 17. November 2012 11:54 schrieb Marcus Koenig <[email protected]>:
>> >> 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 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
