[Talk-de] Permanente/stabile OSM IDs!

Do Jul 26 21:23:33 UTC 2012

Hallo Peter

Am 26. Juli 2012 18:57 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> Am 26.07.2012 18:18, schrieb Stefan Keller:
>> Hallo Rainer,
>> Am 26. Juli 2012 16:57 schrieb Rainer Kluge <rkluge50 at web.de>:
...
> So wie du kann ich auch mein Mantra wiederholen:

Was jetzt folgt, sind jetzt Voraussetzungen, die du aufgestellt hast,
nicht ich.

> Vorausgesetzt, die PID/UUID wird mit kopiert

Das stimmt. Dabei sind wir uns aber wohl aber einig, dass der
"Normalfall" für den einfachen Mapper. Für Tools und Aktionen zur
Verbesserung der OSM-Infrastruktur, wie sie Frederik beschrieben hat
(ich zitiere unten), das das wohl selbstverständlich.

> Vorausgesetzt, man kann sich darauf verlassen, dass, WENN sie mitkopiert
> wird, wirklich das gleiche Objekt damit gemeint ist.

Stimmt. Das ist aber eine philosophische Frage, der wir uns alle bei
jeder Aenderung stellen müssen und die daher nicht spezifisch gegen
PID/UUID oder sonst einen Identifikationsansatz spricht.

> 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.

Das ist kein Argument gegen die PID/UUID, die ich meine: Jedes Objekt,
das in OSM für die externe Datenbank von Interesse ist, erhält eine
PID/UUID, sei es ein Shop oder ein Gebäude oder beides aufs Mal. Der
Umgang damit ist externen Datenbank überlassen und die Mapper sollen
mit den beiden (oder dem einen) machen was sie für richtig halten.

>>> 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?

Ja; da war ich unklar: Dies ist tatsächlich ein Ausnahmefall der aber
alle Ansätze und alle Projekte, die sich auf irgendwelche Tags
verlassen, gleichermassen betrifft. Das muss letztlich
projektspezifisch gelöst werden. Beim PID/UUID-Ansatz könne das durch
einen Vandalismus-Detektor und eine Restaurierungs-Liste zuhanden von
Mapper gelöst werden.

>> 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.

Was gegen die OID (und damit für mich für PID/UUID) spricht? Folgendes -
ich zitiere Frederik Ramm <frederik at remote.org> oben vom 22. Juli 2012 22:58:
===
> ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind
>
> Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen sollte,
> seine Daten auf mehrere Server auf verschiedenen Kontinenten aufzuteilen und
> daher alle Objekte auf neue Server mit neuen Nummernraeumen verteilt, sollte
> das niemanden stoeren.
>
> Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden Objekte
> "umnumeriert", um nicht mehr genutzte "Luecken" wiederzuverwenden, sollte
> das keine Probleme verursachen.
>
> Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und neu
> einfuegt, sollte niemand davon etwas merken.
===

>> 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.

Für die (noch fiktive) LinkedOSMDB, die eine stabile IDs anbieten
würde, wäre das "linkdedosmdb_id=...". Dort sieht jeder die Zeichen
"_id". Aber natürlich kann niemand verhindern, dass ganze Tags von
Mapper gelöscht werden - genauso wie niemand verhindern kann ganze
OSM-Objekte grundlos gelöscht werden.

Die meisten der (an sich guten) Punkte sind Probleme, die alle Ansätze haben.

Irgendwie stehen wir immer noch ohne Lösung da:
* Die einen sagen, nehmt OID und ignorieren die fundamentalen Probleme
(wie oben beschrieben).
* Die anderen schlagen semantische IDs vor, die inhärent nur für
"benennbare, individuelle" OSM-Objekte gelten.
* Und beide können sich nicht mit den Nachteilen (v.a. Ballast) von
PIDs anfreunden - haben aber selber auch keinen besseren Vorschlag,
der potentiell für alle Objekte gilt und der den Wunsch, dass "OSM-IDs
eine 100% OSM-interne Sache sind" nicht erfüllt.

Habe ich etwas übersehen?

LG, Stefan

Am 26. Juli 2012 18:57 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> 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
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de