[Talk-de] Permanente/stabile OSM IDs!

Stefan Keller sfkeller at gmail.com
Do Jul 26 16:18:39 UTC 2012


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.

> 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 (:->).

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.

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.

LG, Stefan

Am 26. Juli 2012 16:57 schrieb Rainer Kluge <rkluge50 at web.de>:
> On 26.07.2012 15:17, Stefan Keller wrote:
>>
>> Peter Wendorff schrieb u.a.
>>>
>>> - Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu):
>>>   Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig
>>>   relativ leicht verifizieren, ob der neu erstellte node vielleicht
>>>   der adäquate Ersatz ist.
>>> - Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag
>>>   verloren: Du erkennst das, hast aber immer noch die ID und den
>>> Ausschnitt,
>>>   die passen - aber prüfen musst du sowieso.
>>
>>
>> Bei diesen beiden Punkten versagt die OSM-ID
>
>
> Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem
> Schlauch.
>
> 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?
>
> 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?
>
>
> Gruß
> Rainer
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de




Mehr Informationen über die Mailingliste Talk-de