[Talk-de] LinkedOSMDB (War: "Permanente/stabile OSM IDs!")

[Stefan Keller]

Hallo,

Am 24. Juli 2012 23:55 schrieb Frederik Ramm <frederik at remote.org>:
> Hallo,
>
> On 24.07.2012 23:12, Stefan Keller wrote:
>>
>> Ein Vorschlag geht offenbar in Richtung "fuzzy links" bzw.
>> "semantische ID". Dabei "spielt" ein Mapper den Identifizierer und
>> definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte
>> (vgl. dazu  http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist
>> schon mal ein guter Ansatz (z.B. ist "name=Matterhorn" weltweit wohl
>> eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und
>> genügt ev. für "query-to-map"-Anwendungen. Er ist aber für die oben
>> erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen
>> Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen.
>
> Ich denke, dann muss man an diesem Konzept noch verfeinern.
>
>> Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM
>> Objekt einsetzbar ist und als ID erkennbar sein soll.
>
> Das finde ich nicht gut.
>
> Ich denke, die Link-Datenbank kann auch Parkbaenke identifizieren mit einer
> Anfrage wie: "Diejenige amenity=bench, die dem Punkt lat=y,lon=x am
> naechsten ist." - in dem Fall ist eine Punktposition Teil des hinterlegten
> Links, was ich aber gar nicht schlecht finde, selbst bei sowas wie
> "Matterhorn", einfach um eine groessere Stabilitaet auch gegenueber
> Spaesschen (jemand erfindet eine Insel in der Suedsee und taggt dort ein
> natural=peak name=Matterhorn) gewappnet zu sein.

Gute Idee, sich gegen solche Spaesschen zu wappnen.

Ich habe einfach Bedenken mit Koordinaten arbeiten. Die machen fast
noch grösseren Kummer als die OSM-ID.

Dann kann die LinkedOSMDB ja gleich bei der OSM-ID bleiben und
versuchen, diese bzw. das dazugehörige Objekt zu "tracken" (das meine
ich nicht abwertend).

> Natuerlich sind solche Links dann unter Umstaenden nicht mehr garantiert
> eindeutig, aber:
>
> Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die
> Parkbank mit der Plakette "gestiftet von Dr. Mueller", dann sollte man *das*
> in OSM taggen (inscription=gestiftet...) und dann kann man darauf auch einen
> Link setzen (eine Parkbank im Umkreis von 50m um den Punkt X, mit
> Inschrift...).
>
> Oder es gibt kein identifizierendes Merkmal, weil da eben drei Parkbanke
> stehen und alle gleich sind - aber *dann* gibt es auch keinen Anlass, auf
> speziell eine der drei verlinken zu wollen.

Diese "Relevanz-These" scheint mir etwas gewagt: Wieso sollte ich als
für die Erhaltung der Parkbänke verantwortliche Parkverwaltung zwei
nebeneinander stehende knallrote Parkbänke (ohne Plakette) nicht
verlinken wollen?

> Da waeren uebrigens noch allerhand interessante Sperenzchen denkbar - man
> koennte z.B. auch einen Link setzen auf "eine Gruppe von 3-5 Parkbaenken in
> der unmittelbaren Naehe der Position X" oder so etwas.
>
> Und wie gesagt, man koennte ja staendig automatische Analysen machen und
> diese Links aufloesen, und in einer Datenbank das Aufloese-Ergebnis
> festhalten und Aenderungen visualisieren - "die Permanent-ID X, der folgende
> Abfrage hinterlegt ist und die 17mal pro Woche nachgefragt wird, ergab
> gestern noch die OSM-ID A als Resultat, heute ergab sie B". Solche IDs
> koennten sogar geflaggt werden als "muesste mal ein Mensch kontrollieren".

Stimmt. Gute Ideen.

> Das ist doch ein viel maechtigeres Konzept, als OSM seine eigenen IDs
> aufzubuerden. Vorallem laesst es auf besere Weise Raum fuer Wettbewerb -
> wenn der Betreiber der Link-Datenbank schlurt, dann kann jemand anders die
> Datenbank komplett kopieren und eine eigene Version davon betreiben, ohne
> dass man jetzt in OSM alle "linkedosmdb"-Tags noch kopieren muss auf
> "freelinkdb" oder was auch immer ;)

Guter Punkt. Um dem vorzubeugen würde ich als LinkedOSMDB-Betreiber
die ID-Werte analog dem TOID und Swiss-OID-Prinzip definieren. Das
verhindert, dass zwei DBs dieselbe ID-Werte zweimal vergeben.
Andererseits lässt sich das Umkopieren und Ergänzen nur verhindern
wenn die neue freelinkdb genau denselben geografischen Bereich
umfasst. Deckt die freelinkdb einen grösseren Bereich ab, ist etwas
was vorher eindeutig war, plötzlich nicht mehr unbedingt so (z.B. ist
name=Stuttgart für Deutschland wohl eindeutig, weltweit aber nicht
mehr).

>> Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist:
>> Sollen nebst "linkedosmdb_id=..." weitere Keys zugelassen sein
>> (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar
>> und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte
>> Objekt mit "name=...") ?
>
> Wie gesagt, fuer mich ist die Gesamtheit aller Eigenschaften der potentielle
> Key eines Objekts, und wenn diese Gesamtheit nicht ausreicht, um das Objekt
> zu identifizieren, dann ist dieses Objekt auch nicht des Identifizierens
> wuerdig.

Wie oben gesagt, finde ich die Relevanz-These
("identifizierwürdige-Parkbänke-müssen-ein-besonderes-Merkmal-haben")
etwas gewagt.

Die Gesamtheit aller Eigenschaften, sprich Tags, kann doch im selben
Objekt über die Zeit variieren, ohne dass sich das Objekt der Realität
auch nur im geringsten ändert. Wenn schon, dann könnte es eine Auswahl
von Tags sein (was du ja auch schon erwähnt hast), wobei das für mich
nicht ausschliesst, dass die Auswahl sehr, sehr klein sein kann (z.B.
zwei oder gar ein Tag :->).

LG, Stefan