[Talk-de] Permanente/stabile OSM IDs!

[Frederik Ramm]

Hallo,

    ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, 
auf die sich niemand sonst verlassen darf, weil dies die 
Handlungsmoeglichkeiten bei OSM einschraenkt.

Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen 
sollte, seine Daten auf mehrere Server auf verschiedenen Kontinenten 
aufzuteilen und daher alle Objekte auf neue Server mit neuen 
Nummernraeumen verteilt, sollte das niemanden stoeren.

Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden 
Objekte "umnumeriert", um nicht mehr genutzte "Luecken" 
wiederzuverwenden, sollte das keine Probleme verursachen.

Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und 
neu einfuegt, sollte niemand davon etwas merken.

Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde 
zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das 
Leben schwerer zu machen -> m.E. keine gute Idee.

UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren 
der Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper 
soll sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X 
ist, und wenn das Restaurant umzieht auf die andere Strassenseite, dann 
loescht er das und legt es neu an, oder er schiebt es rueber, ganz wie 
es gerade am geeignetsten erscheint.

Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines 
Erachtens nie schluessig dargelegt werden, was die UUID genau sein soll. 
Eine UUID fuer die ganze "Bachstrasse", oder eine fuer jeden Teil-Way? 
Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, 
und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf 
die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit 
umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder 
nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir 
brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt...

> 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.

Ich halte das fuer die beste Loesung, die wir haben, weil hier 
derjenige, der den Link setzt, entscheiden muss, was ihm wichtig ist, 
und die Mapper sich nicht damit herumschlagen muessen.

Das Problem der "unvermeidbaren Unzulaenglichkeiten" wird dadurch nicht 
geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der 
anderen Strassenseite neu zeichne, wird das immer noch gefunden.

> 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".

Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme 
wie das UUID-Konzept.

Was aber eine gute Idee waere:

Man baut eine externe Datenbank als Interface zwischen der 
Oeffentlichkeit und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese 
Datenbank permanente Schluessel - seien das UUIDs oder Nummern oder 
sonstwas. Zu OSM hin benutzt diese Datenbank das 
Overpass-Permanent-ID-Konzept (das nicht von Roland erfunden wurde, 
sondern ursrpuenglich mal von Tim Alder mit seinem "query to map" 
angedacht worden war).

Jeder kann bei Bedarf einen Link in dieser Datenbank anlegen lassen und 
den dann ueberall benutzen.

Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat 
dieses Vorgehen den Vorteil, dass alle Links in der Datenbank 
regelmaessig automatisiert ueberprueft werden koennen: Sind sie noch 
gueltig? Zeigen sie noch auf genau 1 Objekt, oder mittlerweile auf 0 
oder 2? Es waere trivial, in dieser Datenbank eine Liste zu generieren 
mit allen "kaputten" Links; es waere sogar moeglich, diese nach 
Nutzungsintensitaet zu sortieren, so dass viel genutzte Links von 
Freiwilligen sofort repariert werden koennen, wenn sie kaputt gehen. Es 
waere sogar denkbar, in dieser Datenbank das "letzte bekannte gute" 
Ergebnis aus OSM zu cachen fuer jeden Link, so dass man, selbst wenn bei 
OSM was kaputt geht, dem Anfrager immer noch wenigstens eine alte 
Version ausliefern kann.

Und das beste: Man muss OSM nicht mit seinen Privatkeys ueberfluten, um 
das machen zu koennen.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"