[Talk-de] Permanente/stabile OSM IDs!

Stefan Keller sfkeller at gmail.com
Fr Jul 27 15:15:00 UTC 2012


Hallo

Am 27. Juli 2012 16:52 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> 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:

Ok. Dann bin ich reden wir aber von ganz verschiedenen Anwendungsfällen :->

> Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes
> Objekt betrachten, also SOLL die ID doch kaputtgehen.

Stimmt. Das ist ein gerechtfertigtes Löschen und einfügen.

> Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes
> Objekt betrachten, also SOLL die ID kaputtgehen.

Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele
zusammengetragen, wo die Koordinaten sich ändern, in dem ganze
Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass
es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle
verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer
dieser Verschiebung nicht traut, kann selber nachschauen - das aber
nicht auf "Kosten" der anderen verlangen, dass die Bushaltestelle
damit à priori eine andere sei.

> Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
> betrachten, also SOLL die ID kaputtgehen.

Das sind alle Systeme gleich.

> Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht,
> reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].

Das ist kein Anwendungsfall, um den es mir hier geht.

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

Nein: Ich möchte lediglich eine permanente/stabile ID anbieten und die
Kriterien, nach denen das getan wird den Nutzern überlassen.
Ich möchte einzig eine Lösung, welche nach aussen unabhängig ist von
OSM-IDs und nach der OSM-DB eindeutig ist in Bezug auf das OSM-Objekt.
Daher kommt eine (nicht von aussen ersichtliche) Kombination von Tags
und ein Ausschluss nicht-mit-normalen-Tags-identifiziertbarer
OSM-Objekte nicht in Frage.

Dies gesagt, halte ich aber immer noch ein Türchen offen für
Argumente, die für B1 sprechen, bei der die Interface-DB (LinkedOSMDB)
sich mit OIDs herumschlägt.

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

Die Overpass-API ist alles andere als stabil gemäss meinen Kriterien.
Das wäre dann Lösungsvariante B3.

LG, Stefan

Am 27. Juli 2012 16:52 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> 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
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de




Mehr Informationen über die Mailingliste Talk-de