[Talk-de] Permanente/stabile OSM IDs!

Stefan Keller sfkeller at gmail.com
So Jul 22 20:57:27 UTC 2012


Hallo Peter

Am 22. Juli 2012 22:30 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
...
> 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:

Das ist ein interessanter Fall, der mir auch von (Einzel-)Parkplätzen
und (Einzel-)Bäumen etc. bekannt ist.

"Meine/unsere" externe DB sollte sich da vorher schon klar gemacht
haben, bevor sie die Projekt-IDs in OSM einträgt, ob sie Supermärkte
(oder was auch immer) nun als Punkte oder Flächen (oder beides)
modelliert. Je nachdem wird dann darauf reagiert.

LG, Stefan

Am 22. Juli 2012 22:30 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> 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
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de




Mehr Informationen über die Mailingliste Talk-de