[Talk-de] Permanente/stabile OSM IDs!

Mo Jul 23 22:22:19 UTC 2012

Hallo Frederik

Am 24. Juli 2012 00:03 habe ich in meiner Antwort an Roland nochmals
darauf hingewiesen, dass ich einen erkennbaren Identifikator meine,
der für alle für das externe Projekt relevanten OSM Objekte gilt und
auch für solche funktioniert, die keine "besonderen Merkmale" haben.
Daher mein Vorschlag einer Projekt-ID (z.B. schlafbank_id=...), was in
Richtung "Linked Data" geht. Diese Projekt-ID/LinkedData-ID ist
eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen
Projekt) permanent.

In diesem Sinne gibt die externe Datenbank (die ähnlich deinem
Vorschlag gemeint ist) etwas zurück für den minimalen "Bloat" den OSM
wegen der Projekt-ID/LinkedData-ID tragen muss.

Was ich bei deinem Vorschlag einer externen Datenbank noch etwas
konkretisieren möchte ist folgendes:
* Wie geht man hier mit OSM Objekten um, auf die kein "fuzzy link"
definiert werden kann (wie z.B. Sitzbänke)?
* Du sprichst davon, dass jedermann "stored queries" auf "fuzzy links"
(im Sinne Tim Alders query-to-map) anlegen kann: An welche
Query-Syntax hast du gedacht?
* Wieso sollten solche "queries/fuzzy links" nicht gerade von den
Betreibern der externen Datenbank in OSM eingetragen werden?
* Bisher haben wir von externen Datenbanken gesprochen - also
Mehrzahl: Gehört so eine "externe Datenbank" nicht eigentlich zur OSM
Infrastruktur?

LG, Stefan

Am 22. Juli 2012 22:58 schrieb Frederik Ramm <frederik at remote.org>:
> 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"
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de