[Talk-de] key start_date

Marcus Koenig einschmelzer at hotmail.com
Sa Nov 17 10:54:18 UTC 2012




> > -1, wenn das Gebäude und das Geschäft darin dasselbe Objekt in OSM sind, dann ist was schief gegangen und spätestens in dem Moment wo man das Baujahr einträgt sollte man die 2 sauber trennen, z.b. indem man für das Geschäft eine Multipolygonrelation erstellt, oder notfalls einen Node innerhalb des Gebäudes. Unklarheiten gibt es sonst auch bei anderen Tags wie name, operator, etc.
> >
> 
> -1/2
> 
> Das war auch mein erster Gedanke: Mehrere Eigenschaften am selben
> OSM-Objekte müssen spätestens dann getrennt werden, wenn ein key nicht
> mehr eindeutig zugeordnet werden kann.
> 
> Allerdings hat der start_date key das Problem, dass er diese
> Uneindeutigkeit bei fast jedem Key-Paar erzeugt.
> amenity=pub; wheelchair=yes  -> start_date = Wann die Kneipe eröffnet
> wurde oder seit wann die Rollstuhlrampe installiert ist?
> amenity=parking; fee=yes -> start_date = Seit wann da ein Parkplatz
> ist, oder seit wann er kostenpflichtig ist?
> 
> Wenn das dazu führt, dass wir an jedem OSM-Objekt nur noch einen Key
> haben können, läuft irgend was falsch.
> 
> 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?

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

> Und noch mal an der Originalposter: Historisch Daten von Objekten, die
> auch jetzt noch existieren sind erst mal kein Problem. Wenn es aber
> darum geht, Dinge zu mappen, die jetzt nicht mehr existieren (und von
> denen auch keine Spuren zu sehen sind), wirst du hier wahrscheinlich
> Gegenwind bekommen. Wir haben schon Probleme, die dritte Dimension
> vernünftig  in der Datenbank abzubilden, geschweige denn eine vierte.
> Da kommt dann schnell die Definitionskeule, das wir bei OSM 'die
> Wirklichkeit abbilden', was bei enger Auslegung leider die Gegenwart
> meint.

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.

Danke und Gruß

MAK

 		 	   		  


Mehr Informationen über die Mailingliste Talk-de