[Talk-de] Permanente/stabile OSM IDs!

[Stefan Keller]

Hallo Rainer

Am 27. Juli 2012 07:31 schrieb Rainer Kluge <rkluge50 at web.de>:
> On 26.07.2012 23:23, Stefan Keller wrote:
>> Am 26. Juli 2012 18:57 schrieb Peter Wendorff<wendorff at uni-paderborn.de>:
>>
>>> 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.
>
> Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle
> abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer
> ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal
> nicht den Normalfall meint.
>
> Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für
> eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des
> Mappers funktionieren würde.

Die allermeisten Spezialfälle die gegen die UUID/PID angeführt werden,
müssen in der externen Datenbank gelöst werden. Solche hohe Ansprüche
bei der noch die Absicht des Mappers einbezogen wird, erfüllt kein
ID-System - und muss es auch nicht!

Es kommt mir vor als ob wir hier die Objektorientierung neu erfinden
(bzw. in Frage stellen) wollten, die gegenüber dem Relationalen Modell
postuliert hat, dass nicht die Gesamtheit aller Werte eines Tupels das
Tupel identifizieren, sondern dass jedem systeminternen Objekt eine ID
zugeordnet wird. Das ist die OSM-ID. Diese soll reorganisiert werden
können, ohne dass jedwelche Nutzer in Problem damit haben. Es gibt
also tatsächlich gute Gründe, dass die OSM ID "eine 100% OSM-interne
Angelegenheit ist". Mit UUID/PID erhalten wir eine permanente/stabile
"OSM-ID gegen aussen" (oder "externe ID" oder UUID/PID) und decken
damit 80% der Fälle automatisch (nach der 80/20 Regel). Die restlichen
20% können in der externen Datenbank gelöst werden (dazu gab es hier
bereits interessante Vorschläge) und müssen - wie gesagt - letztlich
wieder von Menschen beurteilt werden.

Ich sehe hier folgende Vorstellungen: Für die einen (A) wird die
"externe ID" direkt in OSM mitverwaltet, bei der anderen ist eine
Softwarekomponente dafür zuständig. Letztere wiederum organisiert sich
(B1) eine solche externe ID, indem sie entweder versucht, mit den OIDs
klar zu kommen - oder (B2) aber solche "externe ID" in OSM. Ich
tendiere zu B2.

Nun diskutieren wir die verbleibenden 20% der Fälle - und was auch
immer herauskommt: 80% Automatisierung gegenüber vorher ist doch schon
mal nicht schlecht, oder?

> In allen nachfolgenden Fällen ist der Editor
> auf einen Entscheidung des Bedieners angewiesen:
>
> - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem
> gelöschten oder ist es ein anderes, neues Objekt?

Es ist identisch, denn die UUID/PID ist gleich. Jedwelche Ansprüche,
ob das nun mit der Realität oder der Absicht des Mappers übereinstimmt
überlassen wir den Fachdatenbanken/Nutzern. Wie gesagt: Der Normalfall
ist, dass der Mapper etwas verändert (verschiebt, ergänzt, etc.) wenn
es an allen Attributen (inkl. Geometrie) eine Änderung gibt und er
löscht, wenn ein Objekt der Realität gelöscht wird. Das gilt
selbstredend für gute Editoren und automatisierte Prozesse.

> - Ausschneiden und mehrmals Einfügen. Welches der eingefügten Objekte ist
> das verschobene Originalobjekt?

Ähnlicher Spezialfall wie oben. Grundsätzlich tut man nach gesundem
Menschenverstand nicht ausschneiden und grad wieder am selbern Ort
dasselbe Objekt einfügen, nur um eine Vorlage zu haben für weitere
Objekte (vgl. unten). Da müsste ein schlauer Editor beim Einfügen nur
einem Objekt die UUID/PID vergeben und/oder ggf. eine Warnung ausgeben
(er erkennt das an der noch festzulegenden Konvention. dass das Tag
mit "_id" endet). Die anderen kriegen keine UUID/PID.

> - Kopieren und Einfügen, Löschen des Originals. Im Moment des Einfügens weiß
> der Editor noch nichts von dem späteren Löschen. Soll er die ID kopieren?
> Wenn ja, was passiert, wenn dann doch nicht gelöscht wird? Ein Konflikt beim
> Hochladen?

Bei diesem Spezialfall gibt der Editor schon beim Einfügen eine
Warnung aus (analog Fall vorher).

LG, Stefan

Am 27. Juli 2012 07:31 schrieb Rainer Kluge <rkluge50 at web.de>:
> On 26.07.2012 23:23, Stefan Keller wrote:
>>
>> Am 26. Juli 2012 18:57 schrieb Peter Wendorff<wendorff at uni-paderborn.de>:
>>>
>>> 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.
>
>
> Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle
> abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer
> ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal
> nicht den Normalfall meint.
>
> Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für
> eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des
> Mappers funktionieren würde. In allen nachfolgenden Fällen ist der Editor
> auf einen Entscheidung des Bedieners angewiesen:
>
> - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem
> gelöschten oder ist es ein anderes, neues Objekt?
>
> - Ausschneiden und mehrmals Einfügen. Welches der eingefügten Objekte ist
> das verschobene Originalobjekt?
>
> - Kopieren und Einfügen, Löschen des Originals. Im Moment des Einfügens weiß
> der Editor noch nichts von dem späteren Löschen. Soll er die ID kopieren?
> Wenn ja, was passiert, wenn dann doch nicht gelöscht wird? Ein Konflikt beim
> Hochladen?
>
> Gruß
> Rainer
>
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de