[Talk-de] Permanente/stabile OSM IDs!

[Stefan Keller]

Hallo,

Am 22. Juli 2012 22:58 schrieb Frederik Ramm <frederik at remote.org>:
> 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.

Kann ich mit Leben ink. allen erwähnten hypothetischen Fällen.
Daher ja mein Vorschlag von "Projekt/privaten" IDs :->

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

Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht
solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der
Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines
Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten,
dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und
allen Tags) erhalten bleibt und bitte ein neuer Node in den Way
eingefügt wird und nicht - wie offenbar aktuell - der Node im Way
erhalten wird und die Haltestelle eine neue Node-ID erhält.

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

Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke
geht, die keinen Namen haben!

UUID ist ein Spezialfall von meinem Vorschlag einer Projekt-ID. Im
Gegensatz zu UUIDs verlangen "meine" Projekt-IDs aber nicht, dass sich
alle an eine gemeinsame UUID-Spezifikation halten, sondern lediglich,
dass der Mapper den Tag in Ruhe lässt. Wenn dann noch die Editoren den
Mapper beim Verschieben besser unterstützen (und wirklich updaten und
nicht löschen und neu erzeugen), dann umso besser für OSM - und die
Projekt-Datenbank.

...

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

Wie gesagt, ist damit der (häufige) Fall nicht abgedeckt, für alle
diese Objekte, für die die Mapper keine ref-Links (o.ä.) ausdenken.

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

Sehe keinen Unterschied zu meinem Vorschlag, denn auch hier werden
"Links" als Tags ins OSM Objekt gesetzt.
Ich könnte mir höchstens vorstellen, dass mein Vorschlag nur dort zum
Zuge kommt, wo Mapper keine "Links setzen".

> Was aber eine gute Idee waere:

Vorab: Genau diese Idee steckt hinter meinem Vorschlag. Der Vorteil
meines Vorschlags ist, dass es das Overpass-Permanent-ID-Konzept
ergänzt (und ursprünglich auf ein Tag einschränken wollte), da das
Overpass-Permanent-ID-Konzept nur für OSM Objekte funktioniert, die
für Mapper einen sprechenden Schlüssel haben.

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

Soweit wie gesagt einverstanden.

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

Deine Hinweise oben drängen für mich eine Kombination des
Overpass-Permanent-ID-Konzept mit meinem Vorschlag auf: Projekt-IDs
würden dann nur vergeben, wenn in der OSM DB keine "zusammengesetzte
Schlüssel" vergeben werden können, wie das wohl z.B. bei Sitzbänken,
Briefkästen, etc. der Fall ist.

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

Ausgezeichnete Idee!

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

Wie gesagt: Ich will auch keine Überflutung - besonders nicht mit zig
Attributen (wie z.B. von OpenGeoDB) - und ich will auch keine UUID für
jedes OSM Objekt. Aber wir erwarten doch auch nicht, das Mapper sich
für Sitzbänke und Briefkästen irgendwelche "ref"-Attribute ausdenken
müssen - dazu braucht's m.E. Projekt-IDs, oder?

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