Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Am 24. Juli 2012 23:55 schrieb Frederik Ramm frede...@remote.org: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank mit der Plakette gestiftet von Dr. Mueller, dann sollte man *das* in OSM taggen (inscription=gestiftet...) und dann kann man darauf auch einen Link setzen (eine Parkbank im Umkreis von 50m um den Punkt X, mit Inschrift...). Zunächst mal eine Entschuldigung, dass ich in diesem älteren Thread nochmal was schreibe. +1, ist für die meisten Fälle sicher das beste, und hat auch den Vorteil, dass die interessanten Informationen in OSM stehen und nicht in einer externen DB. (Eine der Gefahren von UUID oder anderen extern verwalteten IDs ist vielleicht, dass Firmen damit ggf. die ODBL umgehen könnten? Ganz sicher bin ich mir damit allerdings nicht). Oder es gibt kein identifizierendes Merkmal, weil da eben drei Parkbanke stehen und alle gleich sind - aber *dann* gibt es auch keinen Anlass, auf speziell eine der drei verlinken zu wollen. Allerdings könnte es sein, dass es 3 gleiche Parkbänke gibt, und man dennoch auf eine bestimmte verlinken will, z.B. weil Humphrey Bogart auf der einen saß, oder weil man davon eine besondere Aussicht hat, und 5 Meter daneben schon nicht mehr, etc. Da waeren uebrigens noch allerhand interessante Sperenzchen denkbar - man koennte z.B. auch einen Link setzen auf eine Gruppe von 3-5 Parkbaenken in der unmittelbaren Naehe der Position X oder so etwas. ja, damit könnte man es evtl. in den Griff bekommen (eine Gruppe von 3 Parkbänken nahe Pos. x, davon die mittlere). Solche IDs koennten sogar geflaggt werden als muesste mal ein Mensch kontrollieren. +1, das könnte man auch tun, indem man zusätzlich zur OSM-ID einen Zeitstempel speichert, und wenn sich dann an tags oder Position was (wesentlich) ändert könnte man das von Hand überprüfen. Wie gesagt, fuer mich ist die Gesamtheit aller Eigenschaften der potentielle Key eines Objekts, und wenn diese Gesamtheit nicht ausreicht, um das Objekt zu identifizieren, dann ist dieses Objekt auch nicht des Identifizierens wuerdig. je nachdem. Bestimmte Dinge, die in der realen Welt Bedeutung haben können (z.B. auf das Objekt bezogene Ereignisse) sind in OSM nicht unbedingt darstellbar, bzw. ist es nicht gewünscht, diese abzubilden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hoi Stefan, fuzzy links bzw. semantische ID name=Matterhorn weltweit wohl eindeutig Berühmte Namen finden immer Abbildungen in anderen Objekten. Beispielsweise gibt es das legendäre Restaurant Matterhorn in NZ :-) http://www.matterhorn.co.nz Und bei unserem Matterhorn gibt es mehrere Gipfel, die dieses bezeichnen... Neben name braucht man also noch restaurant bzw. gipfel etc? plus land (oder Adresse?) oder eine (fuzzi?)-Koordinate? Wie machen das eigentlich andere Projekte mit der ID? Beispielsweise Wikipedia oder Commons? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hi, On 07/24/2012 11:55 PM, Frederik Ramm wrote: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank s/kein/ein/ ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Am 25.07.2012 01:20, schrieb Stefan Keller: Ich habe einfach Bedenken mit Koordinaten arbeiten. Die machen fast noch grösseren Kummer als die OSM-ID. Das klingt für mich etwas komisch. Du willst nicht mit einer festen Koordinate/BBox arbeiten, aber dir dann über mehr oder weniger Raten eine Koordinate aus der OSM-DB holen? Mal ganz praktisch gefragt: Was verspricht sich ein Projekt egtl. aus so einer Verlinkung? Die meisten Eigenschaften wird das Projekt sowieso selber erheben müssen. Bei OSM gibt es neben der Koordinate in der Regel maximal noch die Adresse. Ist es da nicht allgemein deutlich einfacher, diese Daten selber zu speichern? Das hindert ja kein Projekt daran, die Daten nicht aus OSM zu holen. Aber wenn ich mir so überlege, welcher Aufwand getrieben werden soll, um das ganze zu verknüpfen, frage ich mich ob das überhaupt einen nennenswerten Vorteil bringt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Markus wrote: Wie machen das eigentlich andere Projekte mit der ID? Beispielsweise Wikipedia oder Commons? Wenn ich das recht verstanden habe, dann wird in der Wikipedia eine Koordinate hinterlegt für das Objekt, das beschrieben wird. Am Objekt in der OSM muss dann ein wikipedia-Tag sein, welches auf den Artikel zurückverweist. Im groben haben wir hier also die Project-ID-Lösung. Wenn jemand das wikipedia-Tag killt, dann bleibt nur noch die Koordinate stehen. In der Wikipedia wird also nicht mehr das Objekt visualisiert (z.B. eine Straße) sondern ein Pointer zeigt irgendwo in die Mitte der selbigen. Bei einem solch großen Projekt wie die Wikipedia wird das wohl nicht hinterfragt und keiner kritisiert diese Lösung. Wie sieht es aber mit kleineren Projekten aus. Also eben der kleinen Vereinskarte. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Am 25.07.2012 01:20, schrieb Stefan Keller: Diese Relevanz-These scheint mir etwas gewagt: Wieso sollte ich als für die Erhaltung der Parkbänke verantwortliche Parkverwaltung zwei nebeneinander stehende knallrote Parkbänke (ohne Plakette) nicht verlinken wollen? Als Verwalter der Parkbänke halte ich aber sowieso meine master-table als referenz - und zwar als Kopie, die definitiv nur von mir angetastet werden kann. Darin kann ich eindeutig referenzieren, und anhand dessen auch entdecken, wenn in osm neues auftaucht oder etwas, das meiner Datenbank nach existieren sollte, plötzlich fehlt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hi, On 07/25/2012 10:44 AM, Manuel Reimer wrote: Bei einem solch großen Projekt wie die Wikipedia wird das wohl nicht hinterfragt und keiner kritisiert diese Lösung. Wie sieht es aber mit kleineren Projekten aus. Also eben der kleinen Vereinskarte. Bei der Wikipedia kommen neben die sind gross auch noch zwei andere Punkte ins Spiel - erstens das Tag ist schon etabliert und zweitens deren Relevanzkriterien, durch die wir sicher sein koennen, dass wir eben *nicht* irgendwann an jedem Gullideckel und jeder Strassenlaterne ein Wikipedia-Tag haben. Ansonsten gilt wie ueberall bei OSM in gewissen Grenzen die Narrenfreiheit des einzelnen Mappers - wenn ich hier schreibe, dass ich Projekt-IDs nicht gut finde, dann rede ich vom allgemeinen Fall. Das heisst nicht, dass ich einem einzelnen Mapper seine 30 Bildstock-IDs loeschen wuerde. Ich will bloss nicht, dass wir das als allgemein akzeptiertes Vorgehen fuer jede Art von Links zwischen der Aussenwelt und OSM propagieren, dass man in OSM seine privaten IDs platziert, weil ich die Sorge habe, dass das dann ueberhand nimmt (erstmal eine permanente ID an alles, was place=* hat, denn sowas kann man bestimmt gut brauchen, und danach dann an alle POIs, und...). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
aighes wrote: Mal ganz praktisch gefragt: Was verspricht sich ein Projekt egtl. aus so einer Verlinkung? - Nutzung der OSM-Tools um Geodaten zu pflegen - Halten der Geodaten in der OSM-DB erlaubt auch anderen Projekten die Nutzung Die meisten Eigenschaften wird das Projekt sowieso selber erheben müssen. ... kann diese dann aber komfortabel mit den OSM-Editoren eintragen und pflegen. Ich bekomme für unsere Bildstock-Karte alle Daten (Koordinate, Beschreibung, Errichtungsdatum) aus der OSM. Lediglich die Bilder steuere ich selber zu, weil ich sicherstellen will, dass ich auf *unserer* Karte nur *unsere* Bilder habe. Das Problem hier ist nun, dass ich irgendwie die Verlinkung zwischen den aus OSM abgeholten Daten und den Bildern hinbekommen muss. Bei OSM gibt es neben der Koordinate in der Regel maximal noch die Adresse. Für so einen typischen Bildstock kann man alle Daten, die relevant sind, mit dokumentierten Tags anbringen. Es gibt alles was man braucht und vermutlich auch noch wesentlich mehr: name - Für den Namen des Bildstocks, wenn bekannt/vorhanden start_date - Wann wurde der Bildstock errichtet? description - Kurzbeschreibung Ist es da nicht allgemein deutlich einfacher, diese Daten selber zu speichern? Das hindert ja kein Projekt daran, die Daten nicht aus OSM zu holen. Aber wenn ich mir so überlege, welcher Aufwand getrieben werden soll, um das ganze zu verknüpfen, frage ich mich ob das überhaupt einen nennenswerten Vorteil bringt. Warum gibt es dann WIWOSM? http://wiki.openstreetmap.org/wiki/DE:WIWOSM Faktisch ist das die Project-ID-Lösung für Wikipedia. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Frederik Ramm wrote: Ich will bloss nicht, dass wir das als allgemein akzeptiertes Vorgehen fuer jede Art von Links zwischen der Aussenwelt und OSM propagieren, dass man in OSM seine privaten IDs platziert, weil ich die Sorge habe, dass das dann ueberhand nimmt (erstmal eine permanente ID an alles, was place=* hat, denn sowas kann man bestimmt gut brauchen, und danach dann an alle POIs, und...). Bleibt nur die Frage, ob nun eine eigene ID besser ist, als eine UUID als Allgemein eindeutige ID. Ich finde die Idee mit der UUID durchaus nicht verkehrt, wenn klare Regeln dafür geschaffen werden. Zum Beispiel sollte eine UUID wirklich eindeutig sein. Darf also nicht mehrfach verwendet werden. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Ich möchte den Diskussionsfaden von Permanente/stabile OSM IDs! zusammenfassen wie folgt: Den Anwendungsfall, den ich einem Lösungskonzept zuführen möchte, sind Nachnutzer und (OSM-)externe Datenbanken (nennen wir es Fachinformationssystem X, das z.B. Schlafbänke als Objekte der Realität verwaltet). Das Fachinformationssystem X verwaltet eigene, zusätzliche Eigenschaften eines Objekts der Realität jemand hat Schlafbänke vorgeschlagen :-) und möchte sich mit der OSM DB verknüpfen. Dazu kann sie sich - wie von Frederik skizziert - auf eine externe Datenbank verlassen, nennen wir sie LinkedOSMDB (siehe auch z.B. OpenMetaMap, die sich noch auf OSM IDs stützt). Die LinkedOSMDB bietet in Richtung Fachinformationssystem X hin eine eindeutige und stabile ID (z.B. ein URI à la Linked Open Data, oder ein TOID à la UK's MasterMap oder die Swiss OID à la Interlis: http://www.interlis.ch/oid/oid_d.php). Dazu gehört natürlich auch eine schnelle API. Und Richtung OSM Datenbank hin zeigt sie auf OSM-Objekte. In OSM geht es nun darum, einen Ansatz zu finden, um eine ID eines OSM-Objekts zu gewährleisten, die zusammen mit dem Objekt der Realität eindeutig ist und stabil bleibt. Genau genommen, ist mit eindeutig im Rahmen eines bestimmten Kontextes gemeint. Und ich spreche bewusst von stabil und nicht von permanent, denn es ist nicht das oberste Ziel, IDs auf gelöschte Objekte - die auch in der Realität gelöscht wurden - zu erhalten - das wäre eine zusätzliche Historisierungs-Dienstleistung. Die Meldung Objekt bzw. ID nicht (mehr) vorhanden genügt. Die OSM ID ist es nicht und soll es auch nicht werden, wie Frederik das beschrieben hat. Ein Vorschlag geht offenbar in Richtung fuzzy links bzw. semantische ID. Dabei spielt ein Mapper den Identifizierer und definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte (vgl. dazu http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist schon mal ein guter Ansatz (z.B. ist name=Matterhorn weltweit wohl eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und genügt ev. für query-to-map-Anwendungen. Er ist aber für die oben erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen. Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM Objekt einsetzbar ist und als ID erkennbar sein soll. Vorschlag: linkedosmdb_id=...! Man beachte, dass damit nicht automatisch sämtliche OSM-Objekte damit aufgebläht werden und dass es keine UUID sein muss, die universumweit eindeutig ist (das geht auch kürzer als mit 64 Zeichen, wie TOID und Swiss OID zeigen). Diese ID ist nicht zusammengesetzt (bei network+ref sieht man dem Key network alleine keine ID-Eigenschaft an und man sieht auch nicht, dass sie zusammengehören!). Und Koordinaten inkl. BoundaryBox kommen auch nicht in Frage, denn das Objekt ist ja immer noch dasselbe, wenn deren Lage ein paar Koordinatenstellen weniger hat oder wenn es verschoben wird, weil jemand die Bushaltestelle an den richtigeren Ort schiebt, die Orthophotos falsch georeferenziert waren oder Koordinaten sich ändern, weil Kontinente herumdriften!!! Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist: Sollen nebst linkedosmdb_id=... weitere Keys zugelassen sein (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte Objekt mit name=...) ? LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hallo, On 24.07.2012 23:12, Stefan Keller wrote: Ein Vorschlag geht offenbar in Richtung fuzzy links bzw. semantische ID. Dabei spielt ein Mapper den Identifizierer und definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte (vgl. dazu http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist schon mal ein guter Ansatz (z.B. ist name=Matterhorn weltweit wohl eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und genügt ev. für query-to-map-Anwendungen. Er ist aber für die oben erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen. Ich denke, dann muss man an diesem Konzept noch verfeinern. Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM Objekt einsetzbar ist und als ID erkennbar sein soll. Das finde ich nicht gut. Ich denke, die Link-Datenbank kann auch Parkbaenke identifizieren mit einer Anfrage wie: Diejenige amenity=bench, die dem Punkt lat=y,lon=x am naechsten ist. - in dem Fall ist eine Punktposition Teil des hinterlegten Links, was ich aber gar nicht schlecht finde, selbst bei sowas wie Matterhorn, einfach um eine groessere Stabilitaet auch gegenueber Spaesschen (jemand erfindet eine Insel in der Suedsee und taggt dort ein natural=peak name=Matterhorn) gewappnet zu sein. Natuerlich sind solche Links dann unter Umstaenden nicht mehr garantiert eindeutig, aber: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank mit der Plakette gestiftet von Dr. Mueller, dann sollte man *das* in OSM taggen (inscription=gestiftet...) und dann kann man darauf auch einen Link setzen (eine Parkbank im Umkreis von 50m um den Punkt X, mit Inschrift...). Oder es gibt kein identifizierendes Merkmal, weil da eben drei Parkbanke stehen und alle gleich sind - aber *dann* gibt es auch keinen Anlass, auf speziell eine der drei verlinken zu wollen. Da waeren uebrigens noch allerhand interessante Sperenzchen denkbar - man koennte z.B. auch einen Link setzen auf eine Gruppe von 3-5 Parkbaenken in der unmittelbaren Naehe der Position X oder so etwas. Und wie gesagt, man koennte ja staendig automatische Analysen machen und diese Links aufloesen, und in einer Datenbank das Aufloese-Ergebnis festhalten und Aenderungen visualisieren - die Permanent-ID X, der folgende Abfrage hinterlegt ist und die 17mal pro Woche nachgefragt wird, ergab gestern noch die OSM-ID A als Resultat, heute ergab sie B. Solche IDs koennten sogar geflaggt werden als muesste mal ein Mensch kontrollieren. Das ist doch ein viel maechtigeres Konzept, als OSM seine eigenen IDs aufzubuerden. Vorallem laesst es auf besere Weise Raum fuer Wettbewerb - wenn der Betreiber der Link-Datenbank schlurt, dann kann jemand anders die Datenbank komplett kopieren und eine eigene Version davon betreiben, ohne dass man jetzt in OSM alle linkedosmdb-Tags noch kopieren muss auf freelinkdb oder was auch immer ;) Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist: Sollen nebst linkedosmdb_id=... weitere Keys zugelassen sein (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte Objekt mit name=...) ? Wie gesagt, fuer mich ist die Gesamtheit aller Eigenschaften der potentielle Key eines Objekts, und wenn diese Gesamtheit nicht ausreicht, um das Objekt zu identifizieren, dann ist dieses Objekt auch nicht des Identifizierens wuerdig. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hallo, Am 24. Juli 2012 23:55 schrieb Frederik Ramm frede...@remote.org: Hallo, On 24.07.2012 23:12, Stefan Keller wrote: Ein Vorschlag geht offenbar in Richtung fuzzy links bzw. semantische ID. Dabei spielt ein Mapper den Identifizierer und definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte (vgl. dazu http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist schon mal ein guter Ansatz (z.B. ist name=Matterhorn weltweit wohl eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und genügt ev. für query-to-map-Anwendungen. Er ist aber für die oben erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen. Ich denke, dann muss man an diesem Konzept noch verfeinern. Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM Objekt einsetzbar ist und als ID erkennbar sein soll. Das finde ich nicht gut. Ich denke, die Link-Datenbank kann auch Parkbaenke identifizieren mit einer Anfrage wie: Diejenige amenity=bench, die dem Punkt lat=y,lon=x am naechsten ist. - in dem Fall ist eine Punktposition Teil des hinterlegten Links, was ich aber gar nicht schlecht finde, selbst bei sowas wie Matterhorn, einfach um eine groessere Stabilitaet auch gegenueber Spaesschen (jemand erfindet eine Insel in der Suedsee und taggt dort ein natural=peak name=Matterhorn) gewappnet zu sein. Gute Idee, sich gegen solche Spaesschen zu wappnen. Ich habe einfach Bedenken mit Koordinaten arbeiten. Die machen fast noch grösseren Kummer als die OSM-ID. Dann kann die LinkedOSMDB ja gleich bei der OSM-ID bleiben und versuchen, diese bzw. das dazugehörige Objekt zu tracken (das meine ich nicht abwertend). Natuerlich sind solche Links dann unter Umstaenden nicht mehr garantiert eindeutig, aber: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank mit der Plakette gestiftet von Dr. Mueller, dann sollte man *das* in OSM taggen (inscription=gestiftet...) und dann kann man darauf auch einen Link setzen (eine Parkbank im Umkreis von 50m um den Punkt X, mit Inschrift...). Oder es gibt kein identifizierendes Merkmal, weil da eben drei Parkbanke stehen und alle gleich sind - aber *dann* gibt es auch keinen Anlass, auf speziell eine der drei verlinken zu wollen. Diese Relevanz-These scheint mir etwas gewagt: Wieso sollte ich als für die Erhaltung der Parkbänke verantwortliche Parkverwaltung zwei nebeneinander stehende knallrote Parkbänke (ohne Plakette) nicht verlinken wollen? Da waeren uebrigens noch allerhand interessante Sperenzchen denkbar - man koennte z.B. auch einen Link setzen auf eine Gruppe von 3-5 Parkbaenken in der unmittelbaren Naehe der Position X oder so etwas. Und wie gesagt, man koennte ja staendig automatische Analysen machen und diese Links aufloesen, und in einer Datenbank das Aufloese-Ergebnis festhalten und Aenderungen visualisieren - die Permanent-ID X, der folgende Abfrage hinterlegt ist und die 17mal pro Woche nachgefragt wird, ergab gestern noch die OSM-ID A als Resultat, heute ergab sie B. Solche IDs koennten sogar geflaggt werden als muesste mal ein Mensch kontrollieren. Stimmt. Gute Ideen. Das ist doch ein viel maechtigeres Konzept, als OSM seine eigenen IDs aufzubuerden. Vorallem laesst es auf besere Weise Raum fuer Wettbewerb - wenn der Betreiber der Link-Datenbank schlurt, dann kann jemand anders die Datenbank komplett kopieren und eine eigene Version davon betreiben, ohne dass man jetzt in OSM alle linkedosmdb-Tags noch kopieren muss auf freelinkdb oder was auch immer ;) Guter Punkt. Um dem vorzubeugen würde ich als LinkedOSMDB-Betreiber die ID-Werte analog dem TOID und Swiss-OID-Prinzip definieren. Das verhindert, dass zwei DBs dieselbe ID-Werte zweimal vergeben. Andererseits lässt sich das Umkopieren und Ergänzen nur verhindern wenn die neue freelinkdb genau denselben geografischen Bereich umfasst. Deckt die freelinkdb einen grösseren Bereich ab, ist etwas was vorher eindeutig war, plötzlich nicht mehr unbedingt so (z.B. ist name=Stuttgart für Deutschland wohl eindeutig, weltweit aber nicht mehr). Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist: Sollen nebst linkedosmdb_id=... weitere Keys zugelassen sein (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte Objekt mit name=...) ? Wie gesagt, fuer mich ist die Gesamtheit aller Eigenschaften der potentielle Key eines Objekts, und wenn diese Gesamtheit nicht ausreicht, um das Objekt zu identifizieren, dann ist dieses Objekt auch nicht des Identifizierens wuerdig. Wie oben gesagt, finde ich die Relevanz-These (identifizierwürdige-Parkbänke-müssen-ein-besonderes-Merkmal-haben) etwas gewagt. Die Gesamtheit aller Eigenschaften, sprich Tags, kann doch im selben Objekt über die Zeit variieren, ohne dass sich das Objekt der Realität auch nur im
