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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de