[Talk-de] Permanente/stabile OSM IDs!

[Stefan Keller]

Hallo Werner

Interessant, was du da in deinem Mail vom 24. Juli 2012 00:38 schreibst.

Letztlich sagst du damit, dass jedes OSM Objekt identifiziert oder
zumindest "verfolgt" werden kann, wenn man vom ihm 1. die OSM ID(?),
2. die Version und 3. das Change-Datum (aus der Historie) verwaltet,
oder?

D.h. dass eine externe Datenbank jedem OSM Objekt eine eigene
(permanente/stabile) ID zuordnen könnte, was meine Frage eingangs
löst. Ich bin ein wenig verunsichert, weil du schreibst "... habe ich
mal einen Prototypen geschrieben, der ... aus der OSM-DB ein Objekt zu
jedem Zeitpunkt ermitteln kann.".

Was ich - bzw. Linked Open Data und Projekte wie query-to-map oder
OpenMetadata ja möchten, ist eine eindeutige, permanente ID - solange
es das Objekt gibt.

Weiter hast du geschrieben:
> Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr aufwändig.

Ja; das habe ich auch gemerkt, als ich ein Extrakt (z.B. ein Land) mit
aktuell halten wollte.
Ist es nun mit deine Prototyp möglich oder nicht?

> Anmerkungen:
> * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die
>   Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden.

Du meinst es braucht eine zeitliche Toleranz, eine Zeitspanne (von
z.B. einigen Minuten)?

> * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction
>   Bot verändert wurden.

Ok. Aber was kann der Bot anders machen als das was unbedarfte Mapper
und Editoren tun (löschen+neu einfügen sollte ja erkannt werden mit
deinem Ansatz)?

Grüsse, Stefan


Am 24. Juli 2012 00:38 schrieb Werner Hoch <werner.ho at gmx.de>:
> Hallo,
>
> Am Sonntag, den 22.07.2012, 21:22 +0200 schrieb Stefan Keller:
>> 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs
>> "ungewollt/unfreiwillig"?
>>
>> Oben wird die Overpass Permanent ID erwähnt
>> (http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ) und
>> dort steht: "...you shouldn't use an object ID, because the OSM IDs
>> may change at any time." Das würde ich gerne mal näher analysieren:
>>
>> Ein klarer Fall für ein Löschen und Neu-Einfügen (mit neuer ID)
>> scheint mir zu sein, wenn das auch in der realen Welt der Fall ist:
>> Wenn z.B. ein Gebäude abgerissen und neu erstellt wird, oder ein
>> wichtiger Einzelbaum gefällt und neu gepflanzt wird.
>>
>> Soeben realisiere ich, dass wenn Nodes (mit Tags) lagemässig
>> verschoben werden, ein neuer Node mit neuer ID und neuen Koordinaten
>> und den "geretteten" Tags erzeugt wird (zumindest in JOSM), während
>> dessen alte Koordinaten als "normaler Way-Node zurückbleiben. Das ist
>> aber kein logisch zwingender Grund, sondern technischer Mangel.
>
> Dieses Problem lässt sich umgehen, wenn man nicht mit der Version des
> Weges arbeitet, sondern zusätzlich mit einem Datum.
>
> Ein way X lässt sich zu jedem Zeitpunkt und immer gleich aus OSM (und
> der OSM-Historie) extrahieren.
> Dieses Objekt(mit Datum) ist stabil. Diese Information ließen sich
> cachen und bei Bedarf gegen die Objekte mit aktuellerem Datum
> abgleichen.
>
> Wie kommt man an das Objekt mit ObjektID+Datum?
> --> alle referenzierten Objekte mit dem entsprechenden Datum ermitteln.
> Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr
> aufwändig.
>
> Vor einigen Jahren habe ich mal einen Prototypen geschrieben, der über
> die API aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann:
> Beschreibung:
> http://www.h-renrew.de/h/osm/tools/osmhistory.html
> Quelltext:
> https://github.com/werner2101/python-osm
>
> Anmerkungen:
> * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die
>   Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden.
> * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction
>   Bot verändert wurden.
>
> Grüße
> Werner
>
>