[Talk-de] Permanente/stabile OSM IDs!

[Peter Wendorff]

Am 26.07.2012 18:18, schrieb Stefan Keller:
> Hallo Rainer,
>
> Am 26. Juli 2012 16:57 schrieb Rainer Kluge <rkluge50 at web.de>:
>> 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