[Talk-de] Permanente/stabile OSM IDs!

Peter Wendorff wendorff at uni-paderborn.de
So Jul 22 20:30:32 UTC 2012


Hallo Stefan.

Ich glaube, du hast dir da direkt ein schwierigeres Thema rausgesucht - 
und ich hab dazu sicher auch keine perfekte Lösung. Den Ansatz der 
Overpass-API hast du ja schon mit aufgelistet, und ich halte ihn für 
momentan den am ehesten praxistauglichen.
Deine anderen Ideen "kritisiere" (bitte nicht übelnehmen) ich mal 
zwischen deinem Text:

Am 22.07.2012 21:22, schrieb Stefan Keller:
> 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs
> "ungewollt/unfreiwillig"?
Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger 
Weg, wenn ich keine Luftbilder zur Verfügung habe.
Beim Hochladen bekommt dieser Supermarkt die Id "node 42" - denn osm hat 
ja für nodes, ways und relations getrennte id-räume.

Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser 
eintragen als Polygon:
Wenn/da du weißt, dass ids zum verlinken genutzt werden könnten, benutzt 
du den alten node als startknoten des gebäudepolygons und kopierst die 
daten auf das polygon.
Der way hat jetzt eine ID way23 - und die id node42 kann er auch gar 
nicht kriegen, das hat mit dem editor nichts zu tun.

Wenn eine Software aber zur ID node42 verlinkt, wird er z.B. die 
Öffnungszeiten nicht mehr finden können, denn die hängen jetzt 
korrekterweise am way23.

Eine "Korrektur" hin zu stabilen ObjektIDs ist also mit der aktuellen 
API nicht machbar - und vermutlich auch so ohne weiteres dauerhaft nicht 
zu lösen, denn:

- Ich trage das Gebäude Mozartstraße 3 als Polygon way323 ein mit 
building=yes, amenity=doctors.
- Eine Datenbank D verlinkt das Gebäude (way323), um die Arztpraxis von 
Dr. OSM zu markieren.
- Du verbesserst OSM und trägst die drei Arztpraxen von Dr. OSM, Dr. 
Etsch und Dr. doofe-IDee als einzelne nodes ein.

Auf einmal ist zwar das ursprüngliche polygon noch da, aber das ist gar 
nicht das, was die externe datenbank meinte - die verlinkt immer noch 
zum damals am besten passenden Objekt.
Das war zwar vorher schon eine Arztpraxis, aber eben noch ungenau, die 
drei arztpraxen wurden als eine abgebildet.
> Soeben realisiere ich, dass wenn Nodes (mit Tags) lagemässig
> verschoben werden, ein neuer Node mit neuer ID und neuen Koordinaten
> und den "geretteten" Tags erzeugt wird (zumindest in JOSM), während
> dessen alte Koordinaten als "normaler Way-Node zurückbleiben.
Das stimmt nicht, wenn du den node nur verschiebst. Dafür musst du ihn 
kopieren und einfügen.
> Das ist aber kein logisch zwingender Grund, sondern technischer Mangel.
Nein. Nur eine andere Interpretation dessen, was richtig ist, als du sie 
annimmst.
> Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig,
> dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch
> verlängert oder ein Node eingefügt, dann hoffentlich auch nicht!
Im Sinne stabiler IDs:
Wenn ein way das Tag highway=residential verliert und jetzt auf einmal 
stattdessen building=yes bekommt, dann ist das ein neues Objekt.
Wenn dagegen highway=residential durch highway=pedestrian ausgetauscht 
wird, ist die Straße im Grunde die gleiche geblieben.
> 2. OSM ID's sind grundsätzlich stabil!
>
> 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.
Guck dir alle Städte an, die bisher noch Hausnummern in Form von Nodes 
enthalten, verschaff denen aktive Mapper mit etwas Langeweile und gute 
Luftbilder - und schon sind deine alten Nodes weg und unter neuen IDs 
die gleichen Hausnummern in Form von Gebäudepolygonen drin - tausendfach.
> 3. Projekt-ID Tag als Lösung?
>
> 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 kommen immer wieder Fälle vor, wo eine ID ungewollt "untergeht" und
> wo man als OSM-externe Datenbank (z.B. als Projekt wie
> http://wiki.openstreetmap.org/wiki/OpenMetaMap ) dann situativ darauf
> reagieren muss. Fälle wie der Lizenzwechsel müssen sowieso separat
> gelöst werden. Es kann auch vorkommen, dass am (zu einer ID
> kombinierten) Tag "network=BAB"+"ref=A 516" etwas geschieht, z.B. wenn
> ein jemand (inkl. ein Tool) findet, "ref=A 516" sei doch "ref=A516" -
> also A516 ohne Space! Das Problem solcher "eindeutigen Eigenschaften"
> eines Objekts scheint mir, dass solch sprechende IDs nichts taugen -
> und es ist erst noch nicht an den Keynamen network+ref erkenntlich,
> dass sie überhaupt IDs bilden. Das ist genau der Unterschied zwischen
> Schlüssel und Identifikator!
Die stabile ID, die die overpass-ID einführt, ist eben keine ID im 
eigentlichen Sinne, sondern eine Annäherung, das ID-Problem zu lösen, 
indem man einen (ersten) Schritt weggeht von den OSM-internen IDs.
> Mir scheint nichts anderes übrig zu bleiben, als entweder mit der OSM
> ID zu leben (und deren Stabilität laufend zu verbessern!) - oder aber
> folgendes:
>
> 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".
> D.h. keine Kombination und keine "normal" aussehende Keys, sondern
> einen einzigen in OSM klar als ID erkennbaren Key. Der feine
> Unterschied zu network+ref (Bundesbahnen), TMC:cid_58 (TMC), uic_ref
> (DIDOK) oder openGeoDB:loc_id (OpenGeoDB) ist, dass es sich um eine
> einzige, einzigartige ID handelt, die von aussen referenziert wird -
> und das den Mappern auch klar zeigt.
Trotzdem wirst du keinen Mapper finden, der sich dann auf Dauer mit IDs 
von 20 verschiedenen Projekten auskennt, um die korrekt zu halten.
Beispiel von oben: ich trenne das Gebäude mti amenity=doctors auf in ein 
gebäudepolygon und drei Nodes für die einzelnen arztpraxen.
Am gemeinsamen node war vorher die ID aus deinem projekt: arztpraxen_id:245.
Woher soll ich als mapper jetzt wissen, was das bedeutet? ist das das 
Gebäude, oder welche der drei Praxen ist es?
Was mach ich damit?
1) ich lass es eventuell falsch am gebäude - stört mich ja nicht - aber 
du hast einen falschen link in deiner datenbank.
2) ich lass das mit dem editieren ganz sein, weil ich nichts 
kaputtmachen will - das ist aber für OSM auch nicht gut, denn wer weiß, 
ob es dein Projekt überhaupt noch gibt.
3) ich pappe die ID an alle drei neuen arztpraxen - und du musst dich 
wieder damit rumschlagen.

Alles keine besonders tollen Möglichkeiten - weder für dich als 
Betreiber des Fremdprojekts noch für mich als Mapper.
> Wenn das gewünscht (und von OSM geduldet ist), kann eine externe
> Datenbank zusätzlich(!) von mir aus auch auf sich selber zeigen - wie
> das allen oben erwähnten Datenbanken der Fall ist. Umstritten ist,
> dass diese Datenbanken das OSM Objekt "vereinnahmt" und mit weiteren
> Tags "belastet". Das muss nicht sein.
Die Belastung ist nicht so sehr nur auf Seiten der Datenbank (obwohl es 
auch da andere Meinungen gibt), sondern eben auch vor allem die der 
Mapper, die nicht wissen, wie sie damit umgehen sollen.
Die Wikipedia-Links sind so eine Ausnahme, weil sie
1) für viele interessant sind, unter anderem auch einen Wert für den 
Mapper zur Recherche bilden, und
2) einfach für jeden nachprüfbar sind.

Gruß
Peter




Mehr Informationen über die Mailingliste Talk-de