Am 27.07.2012 16:16, schrieb Stefan Keller:
Hallo
Am 27. Juli 2012 08:55 schrieb Peter Wendorff <wendo...@uni-paderborn.de>:
...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
= 12423528312313513412351341351
Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung
aber sicher nicht für die Anwendungsfälle zur datenbankmässigen
Verknüpfung.
Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören.
Genau das, was ich will:
Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als
anderes Objekt betrachten, also SOLL die ID doch kaputtgehen.
Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein
anderes Objekt betrachten, also SOLL die ID kaputtgehen.
Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
betrachten, also SOLL die ID kaputtgehen.
Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße
geht, reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].
Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM
drinsteht und sich niemand zusätzlich um die Pflege irgendeines
ID-Systems kümmern muss.
Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht
mir auch die alte OSM-ID für 80% der Fälle aus - das will ich aber
üblicherweise nicht.
Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
Kriterien, und die kann ich in Attributen fassen, die dann einer ID
ähnlich sind.
Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.
Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API
schon, ohne zusätzliche Tags oder Attribute.
Gruß
Peter
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
