[Talk-de] Permanente/stabile OSM IDs!

[Peter Wendorff]

Am 27.07.2012 08:20, schrieb Tobias Knerr:
> Am 27.07.2012 08:00, schrieb Markus:
>> Eine ID muss m.E.
> [...]
>> 4. möglichst stabil mit dem OSM-Objekt verbunden sein
>> 5. möglichst stabil mit dem realen Objekt verbunden sein
> 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie
> verbunden ist.
>
> Das Problem "wann ist ein Restaurant noch dasselbe Restaurant", das mit
> einer Query-basierten Lösung praktisch automatisch gelöst würde, wird
> von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer
> einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu
> dieser Frage ist es schon prinzipbedingt nicht lösbar.
>
>> Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie
>> ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen
>> Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht,
>> wiederhergestellt, dupliziert wird, und wie es von einem.
> Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID
> eigentlich bezieht.
...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

Klar - das könnte man auch einfacher haben, weil es letztlich genau der 
Idee stabiler IDs nach overpass bzw. query2map entspricht und man dann 
keine ID mehr in OSM einpflegen braucht, aber die entsprechend zu 
referenzierenden Attribute mit der ID zu verknüpfen, ist soweit ich das 
bisher sehe, weitgehend alternativlos.

Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende 
Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf 
dieses Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr 
erkennbar.

Gruß
Peter