[Talk-de] Permanente/stabile OSM IDs!

[Stefan Keller]

Lieber Rainer,

Am 25. Juli 2012 19:15 schrieb Rainer Kluge <rkluge50 at web.de>:
> Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme*
> aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage
> war, was fehlt dir noch, wenn du diese *Lösungen* anwendest.

Bitte lies doch meine Beiträge hier auch nochmal. Ich denke Manuel's
Hinweis ist gerechtfertigt und bisher war die Diskussion hier durchaus
lösungsorientiert.

Peter Wendorff schrieb u.a.
> - Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu):
>  Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig
>  relativ leicht verifizieren, ob der neu erstellte node vielleicht
>  der adäquate Ersatz ist.
> - Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag
>  verloren: Du erkennst das, hast aber immer noch die ID und den Ausschnitt,
>  die passen - aber prüfen musst du sowieso.

Bei diesen beiden Punkten versagt die OSM-ID und der Vorschlag sich
"zur Sicherheit" noch eine Koordinate oder gar einen Ausschnitt
("Suchradius") zu speichern und eine Lösung mit einer UUID/Projekt-ID
ist viel sinnvoller für die eingangs geschilderten Anwendungsfälle.

1. "Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu)"
=> Mit UUID/Projekt-ID muss man da nichts nachgucken.

2. "Die Tags eines bildstocks ändern sich, dabei geht das
bildstock-tag verloren" => Das is genau einer der Schwachpunkte von
"semantischen/zusammengesetzten IDs", weil die Chance dass einer von
mehreren Tags verloren geht grösser ist als bei einem und weil man es
ihnen nicht ansieht, dass sie "zusammengehören" (im Ggs. zu
UUID/Projekt-ID).

Zudem muss ich hier nochmals betonen, dass die
"semantischen/zusammengesetzten IDs" für genau solche Anwendungen, die
"nur" auf OSM-Objekte verlinken wollen, immer noch keine Lösung gibt,
denn viele Anwendungsfälle möchten auch auf OSM-Objekte zeigen, die
keine natürlich identifizierenden Tags haben, wie eben Bildstöcke,
Sitzbänke, Einzelbäume, RobyDogs, Startstromleitungsmasten,
Seilbahnkabel, etc. . Wieso soll OSM nicht offen sein für solche
Anwendungen?

Eine UUID, die generell über alle OSM-Objekte verteilt wird,
zusätzlicher Ballast ist, kann ich nachvollziehen.

Eine Projekt-ID will da ein Kompromiss sein und hat den Nachteil, dass
es ev. (in ferner Zukunft?) pro OSM-Objekt mehrere solche geben
könnte. Jedenfalls kann man das nicht abwertend als Privat-Keys
bezeichnen, wenn es freie Services gibt, die stabile OSM IDs anbieten
- wie das mit Frederiks Vorschlag (und meiner LinkedOSMDB) angedacht
ist.

Ganz wichtig scheint mir, dass wir von den ähnlichen Anwendungsfälle
reden. Die Lösung mit semantischen/zusammengesetzten IDs scheint sich
um die Fälle zu kümmern, bei denen eine externe Datenbank (hier
Wikipedia) ein OSM-Objekt in etwa "einfängt", um es auf einem
Kartenausschnitt zu zeigen.

In Manuel's Fall der Bildstöcke, in OpenMetaMap und meinen Fällen geht
es darum, dass eine Fachdatenbank sein Objekte mit OSM-Objekten
(möglichst direkt!) verknüpfen will.

Konsens ist - glaube ich - Frederiks Vorschlag einer "LinkedOSMDB",
die zwischen der Fachdatenbank und OSM sitzt. Nach einigem Nachdenken
könnte es nun auch sein, dass ich innerhalb der LinkedOSMDB von der
Privat wieder auf OSM-IDs schwenke. Der vorläufige Stand meiner Lösung
möchte ich im Thread "LinkedOSMDB" nebenan zusammenfassen.

LG, Stefan

Am 25. Juli 2012 19:15 schrieb Rainer Kluge <rkluge50 at web.de>:
> On 25.07.2012 12:32, Manuel Reimer wrote:
>>
>> Peter Wendorff wrote:
>>>
>>> Wo ist jetzt deine Lücke in dem Konzept?
>>> Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID auch nicht.
>>
>> Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern
>> nicht verändert/angefasst wird.
>
> Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme*
> aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage
> war, was fehlt dir noch, wenn du diese *Lösungen* anwendest.
>
> Gruß
> Rainer
>
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de