Wollte sagen: Da ist Variante B1 oben *sinnvoller*, bei der gegen die OSM-DB die OID verwendet wird und gegen aussen eine UUID/PID angeboten wird.
Am 27. Juli 2012 16:16 schrieb Stefan Keller <[email protected]>: > Hallo > > Am 27. Juli 2012 08:55 schrieb Peter Wendorff <[email protected]>: >> ...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. > Da ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet > wird und gegen aussen eine UUID/PID angeboten wird. > > LG, Stefan > > Am 27. Juli 2012 08:55 schrieb Peter Wendorff <[email protected]>: >> 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 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
