Hallo Am 27. Juli 2012 08:55 schrieb Peter Wendorff <wendo...@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. 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 <wendo...@uni-paderborn.de>: > 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 > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
