Am 26.07.2012 18:18, schrieb Stefan Keller:
Hallo Rainer,
Am 26. Juli 2012 16:57 schrieb Rainer Kluge <[email protected]>:
Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem
Schlauch.
An die Gefahr des Aneinandervorbeiredens habe ich auch schon gedacht
und möchte nochmals betonen, dass es mir nicht um den Fall geht wie
bei Wikipedia/WIWOSM, sondern um eine externe Datenbank, die eigene
Dinge verwaltet (z.B. Bilder und Historische Dokumente zu Bildstöcke)
und diese mit Tags und Geometrie ergänzt, die von OSM kommen. Diese
externe Datenbank hält sich über OSM à jour und gibt ihr auch etwas
zurück (komme später darauf zurück). Diese externe Datenbank (oder ein
LinkedOSMDB-Dienst) muss nun in Echtzeit auf ein einzelnes OSM-Objekt
zugreifen können und sie möchte klar sagen können: Ist das OSM-Objekt
wirklich neu, geändert oder gelöscht?
Zum ersten Punkt:
- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese
ID gespeichert
- Jemand löscht diesen Bildstock
- Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und
stellt fest, dass dieses nicht mehr existiert
Wo ist hier das Problem?
Angenommen es handelt sich eigentlich um dasselbe Objekt, und das
Objekt wird nicht mehr am derselben Ort erstellt, dann ist die Chance
gross, dass man es verliert. Ich habe oben einige solche Situationen
zusammengetragen. Sagen wir, es wurde "nur" um 10m verschoben, aber
innerhalb von 10m gibt es noch weitere neue Objekte: Welches ist es
nun?
Mit einer Projekt-ID/UUID muss man nichts tun.
So wie du kann ich auch mein Mantra wiederholen:
Vorausgesetzt, die PID/UUID wird mit kopiert
Vorausgesetzt, man kann sich darauf verlassen, dass, WENN sie mitkopiert
wird, wirklich das gleiche Objekt damit gemeint ist.
Vorausgesetzt, die PID/UUID ist für den Mapper korrekt an genau dem
Objekt angebracht, das sie auch bezeichnen soll - also nicht
gleichzeitig an Shop und Gebäude (obwohl das durchaus auch mal ein
Objekt sein/werden kann) etc.
IMHO ziemlich viele "vorausgesetzt"s, um das als sichereren Weg ohne
genauso aufwändige Prüfung anzupreisen.
Zum zweiten Punkt:
- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese
ID gespeichert
- Jemand löscht das Bildstock-Tag dieses Objekts
- Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu
und stellt fest, dass das Bildstock-Tag weg ist
Wo ist hier das Problem?
Das ist ein kritischer, sogenannt "bösartiger" Fall: Das Hauptproblem
einer Lösung mit OSM-ID (oder ggf. OSM-ID+Koordinate) ist, dass OSM-ID
nicht stabil ist (:->).
häh?
Hast du damit jetzt die Frage beantwortet, wo das Problem liegt und wo
dein UUID-Ansatz besser wäre, oder hast du das als Ausnahme definiert
und nimmst deshalb an, dein Ansatz müsse das nicht unterstützen?
Dieser Fall ist gerade auch ein schwacher Punkt der
"semantischen/zusammengesetzten ID, denn dort ist gar nicht
offensichtlich, dass man einen Identifizierungs-Ansatz zerstört.
Die Semantische ID ist aber gerade momentan nicht die Konkurrenz zur
nicht-semantischen UUID, sondern eine weitere Variante. Gefragt ist doch
erstmal, warum zur OSM-ID ein zusätzliches System überhaupt Sinn macht,
da liegt also der eigentliche Vergleichspunkt.
Hier schneidet die Projekt-ID immer noch besser ab: Sie ist gut
erkenntlich und kann an jedes Objekt, das referenziert werden soll,
gehängt werden.
Wie sieht sie denn aus, so dass sie gut erkenntlich ist?
Bedenke: Die meisten Mapper benutzen im alltäglichen Gebrauch nicht
ständig die Dokumentation/das Wiki, sondern mappen drauflos, indem sie
abgucken, was anderswo steht oder die Editor-Presets nutzen.
Beides kann ich für eine solche ID aber nicht als verständlich erkennen.
Gruß
Peter
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
