Hallo Rainer Am 27. Juli 2012 07:31 schrieb Rainer Kluge <[email protected]>: > On 26.07.2012 23:23, Stefan Keller wrote: >> Am 26. Juli 2012 18:57 schrieb Peter Wendorff<[email protected]>: >> >>> 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 <[email protected]>: > On 26.07.2012 23:23, Stefan Keller wrote: >> >> Am 26. Juli 2012 18:57 schrieb Peter Wendorff<[email protected]>: >>> >>> 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-de _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
