[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