[Talk-de] Permanente/stabile OSM IDs!
Peter Wendorff
wendorff at uni-paderborn.de
Fr Jul 27 14:52:39 UTC 2012
Am 27.07.2012 16:16, schrieb Stefan Keller:
> Hallo
>
> Am 27. Juli 2012 08:55 schrieb Peter Wendorff <wendorff at 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
Mehr Informationen über die Mailingliste Talk-de