[Talk-de] Permanente/stabile OSM IDs!

Tobias Knerr osm at tobias-knerr.de
So Jul 22 20:47:09 UTC 2012


Am 22.07.2012 21:22, schrieb Stefan Keller:
> Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie
> JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich
> keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen.
> Ich lasse mich aber gern - bzw. weils's sein muss :-> vom Gegenteil
> überzeugen.

Viele Bearbeitungsoperationen kann man in der Tat so durchführen, dass
eine ID erhalten bleibt, aber das ist keine Garantie, dass ein Mapper
auch diesen Weg wählen wird - und es gibt auch keine Pflicht, das zu tun.

Zudem gibt es Änderungen der Darstellungsform (Umbau von Node auf
Fläche, oder von geschlossenem Way auf Relation), bei denen der Erhalt
einer ID schon vom Prinzip her nicht möglich ist. Ebensowenig kann etwa
beim Auftrennen eines der Ways einer Straße die Liste der IDs für die
Straße erhalten bleiben.
 >
> 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.

Es ändert schon etwas: IDs sind "versteckte" Eigenschaften, die der
Mapper bedenkenlos ändern darf und oft wird. Tags sind hingegen
Eigenschaften, bei denen beim Bearbeiten klar sein sollte, dass das
"nach außen", also für Datennutzer, Folgen haben wird und man sich daher
beim Ändern Gedanken machen muss.

> Mein Minimalvorschlag ist, dass "nur" eine klar am Tagnamen erkennbare
> projektspezifische ID eingeführt wird, die niemals mehr verändert wird
> (ausser sie geht mit dem OSM Objekt unter). Die externe Datenbank
> verwaltet die Beziehung zwischen ihren Objekten und dem so
> bezeichneten OSM-Objekt selber. Bei OpenMetaMap steht zurzeit OSM ID
> (für keyA bzw. "Object ID"); da wäre nun nur noch eine
> "openmetamap_osm_id" nötig.

Diese Option scheitert schon daran, dass es auf lange Sicht zu viele
Datenbanken geben dürfte, die mit OSM interagieren wollen. Das geht gut,
solange es sich um einige wenige, bekannte Projekte handelt - z.B. bei
den existierenden Wikipedia-Links -, aber wenn jetzt außer Flickr noch
dutzende weitere kommerzielle Fotoportale OSM-Verlinkungen einführen
wollen, würden diese Tags ausufern.

Es ist außerdem auch nicht klar, welche Eigenschaft dem Verlinker nun
wichtig ist. Wenn ein Restaurant umzieht, ist es dann noch "dasselbe"
Restaurant? Die Definition von "dasselbe" ist vermutlich für jedes der
verlinkten Projekte anders, und man kann nicht erwarten, dass der Mapper
die Kriterien jedes der Projekte kennt.

Bei einer Query hingegen ist das ganz automatisch definiert - da müssen
in der Query eben genau die Eigenschaften eingebaut sein, die für den
Verlinker das Objekt ausmachen.

Von daher denke ich weiterhin, dass die Identifikation über
Eigenschaften aus der realen Welt (was auf geeignete Queries in z.B.
Overpass hinausläuft) die richtige Lösung ist. Solche Probleme wie dein
Beispiel mit Leerzeichen sind vorhersehbar, so dass man sich in vielen
Fällen darauf vorab einstellen kann.

Gruß,
Tobias




Mehr Informationen über die Mailingliste Talk-de