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 frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
