[Talk-de] Permanente/stabile OSM IDs!

Stefan Keller sfkeller at gmail.com
So Jul 22 19:22:10 UTC 2012


Hallo

Mich beschäftigt seit einiger Zeit die Frage von "permanenten/stabilen
OSM IDs" und der Verknüpfung von OSM mit anderen Datenbanken.

2012/7/22 Sarah Hoffmann <lonvia at denofr.de> schrieb in einer
Diskussion auf talk-ch:
> On Sun, Jul 22, 2012 at 01:40:48PM +0200, Stefan Keller wrote:
...
>> What remains to me is the following, since I'm having in mind OSM
>> which is more and more related to "external databases". First, I'm
>> still convinced that the principle of update (versus delete and
>> recreate) should hold also for OSM. Second, we seem to have a problem
>> with stable id's in OSM (osm_id).
>>
>> Having external id's in OSM now seems to me like a necessity (in order
>> to become related to external dbs) and a concession to the fact the
>> OSM doesn't have stable ids. At least it's also an indication or flag
>> to OSM users.
>
> One of the big TODOs of OSM. Closest thing we have at the moment is
> Rolands proposal base on the Overpass API:
> http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
>
> Problem is that it is pretty hard to define what is 'stable' in the
> context of OSM. How should splitting of ways be handled? What if a
> shop moves to the next building? What if we split the bus stops into
> two, one for each direction? So, we actually end up with a n-to-n
> relation: one OSM object might have multiple UIDs (for the shop, for
> the building, for the address...) and a UID might reference multiple
> OSM objects (split ways).
>
> Sarah


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.

Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig,
dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch
verlängert oder ein Node eingefügt, dann hoffentlich auch nicht!

Im oben erwähnten Fall wird ein - zunächst als ein "bus_stop" erfasste
- Busstation in zwei "bus_stops" aufgeteilt, weil das eher der
Realität entspricht. Oder es wird ein Way gesplittet wird (wenigstens
bleibt dann die ID typischerweise erhalten). In diesen Fällen lässt
sich auch mit nicht-technischen Argumenten debattieren, ob das nun ein
Update oder ein Delete/Create ist! Daher:


2. OSM ID's sind grundsätzlich stabil!

Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie
JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich
keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen.
Ich lasse mich aber gern - bzw. weils's sein muss :-> vom Gegenteil
überzeugen.


3. Projekt-ID Tag als Lösung?

Laut Overpass's Permanent ID könnte die Lösung eine "eindeutige
Eigenschaft" des Objekts sein, typischerweise eine Kombination von
Tags. Als Beispiel wird eine Relation mit den Tags "network=BAB" und
"ref=A 516" herangezogen. Ich finde den Vorschlag gut - man muss sich
aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem
der offenbar "unvermeidbaren menschlich- und technischen
Unzulänglichkeiten" nicht löst.

Es kommen immer wieder Fälle vor, wo eine ID ungewollt "untergeht" und
wo man als OSM-externe Datenbank (z.B. als Projekt wie
http://wiki.openstreetmap.org/wiki/OpenMetaMap ) dann situativ darauf
reagieren muss. Fälle wie der Lizenzwechsel müssen sowieso separat
gelöst werden. Es kann auch vorkommen, dass am (zu einer ID
kombinierten) Tag "network=BAB"+"ref=A 516" etwas geschieht, z.B. wenn
ein jemand (inkl. ein Tool) findet, "ref=A 516" sei doch "ref=A516" -
also A516 ohne Space! Das Problem solcher "eindeutigen Eigenschaften"
eines Objekts scheint mir, dass solch sprechende IDs nichts taugen -
und es ist erst noch nicht an den Keynamen network+ref erkenntlich,
dass sie überhaupt IDs bilden. Das ist genau der Unterschied zwischen
Schlüssel und Identifikator!

Mir scheint nichts anderes übrig zu bleiben, als entweder mit der OSM
ID zu leben (und deren Stabilität laufend zu verbessern!) - oder aber
folgendes:

Eine OSM-externe Datenbank vergibt einen eigenen und für sie
eindeutigen ID-Tag in OSM, die "nicht-sprechende" Identifikatorwerte
erhalten, z.B. "unserprojekt:id=10001" oder "unserprojekt_id=10001".
D.h. keine Kombination und keine "normal" aussehende Keys, sondern
einen einzigen in OSM klar als ID erkennbaren Key. Der feine
Unterschied zu network+ref (Bundesbahnen), TMC:cid_58 (TMC), uic_ref
(DIDOK) oder openGeoDB:loc_id (OpenGeoDB) ist, dass es sich um eine
einzige, einzigartige ID handelt, die von aussen referenziert wird -
und das den Mappern auch klar zeigt.

Wenn das gewünscht (und von OSM geduldet ist), kann eine externe
Datenbank zusätzlich(!) von mir aus auch auf sich selber zeigen - wie
das allen oben erwähnten Datenbanken der Fall ist. Umstritten ist,
dass diese Datenbanken das OSM Objekt "vereinnahmt" und mit weiteren
Tags "belastet". Das muss nicht sein.

Mein Minimalvorschlag ist, dass "nur" eine klar am Tagnamen erkennbare
projektspezifische ID eingeführt wird, die niemals mehr verändert wird
(ausser sie geht mit dem OSM Objekt unter). Die externe Datenbank
verwaltet die Beziehung zwischen ihren Objekten und dem so
bezeichneten OSM-Objekt selber. Bei OpenMetaMap steht zurzeit OSM ID
(für keyA bzw. "Object ID"); da wäre nun nur noch eine
"openmetamap_osm_id" nötig.

Meinungen?

LG, Stefan




Mehr Informationen über die Mailingliste Talk-de