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
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
