Am 17. November 2012 02:12 schrieb Martin Koppenhoefer <[email protected]>:
> > -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. 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. 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. Gruss, Chaos _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
