Re: [Talk-de] Permanente/stabile OSM IDs!
Hoi Stefan, Danke für die Zusammenfassung: * OSM-ID * semantische IDs * Ballast von PIDs * OSM-IDs eine 100% OSM-interne Sache und dann gabs noch die UUID Eine ID muss m.E. 1. eindeutig sein (inkrementell oder UUID) 2. automatisch zugeordnet sein 3. persistent sein (nicht händisch editierbar) 4. möglichst stabil mit dem OSM-Objekt verbunden sein 5. möglichst stabil mit dem realen Objekt verbunden sein Forderung 1 und 2 wird durch OID bzw. UUID erfüllt. Forderung 3 wird durch OID erfüllt, könnte auch durch geschützte UUID oder geschützte PID erfüllt werden. Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht, wiederhergestellt, dupliziert wird, und wie es von einem. Das könnten wir anhand von konkreten und illustrierten Beispielen so erläutern, dass es auch für Anfänger und Gelegenheits-Mapper nachvollziehbar verständlich ist. Der verbleibende Rest (Stabilität ist systemimmanent unklar, Mapper macht Fehler, etc) muss seitens der Anwendungs-SW geregelt werden, die zwei DBs verknüpft. Neu: Mapper müssen m.E. zunehmend verstehen lernen, dass sie nicht nur zeichnen, sondern eine DB erstellen :-) Und dass das was sie tun, unmittelbare Auswirkungen auf die Anwendungen (Karten, Router, etc) hat. Wir könnten hier schon mal beginnen, konkrete Beispiele zu sammeln, die einer Regelung bedürfen... Und dann in einem zweiten Schritt entsprechende Regelungen zu finden, und in einem dritten Schritt diese beispiele und Regeln illustriert beschreiben. Gruss, Markus PS: PIDs sind m.E. unnötiger Ballast. (bzw ein Workaround für mangelhafte oder fehlende Regeln zu 4 und 5) @Frederik: selbstverständlich müssen IDs projektintern geregelt sein. Und selbstverständlich nach aussen so dokumentiert, dass Dritte sich darauf systematisch verlassen können. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 08:00, schrieb Markus: Eine ID muss m.E. [...] 4. möglichst stabil mit dem OSM-Objekt verbunden sein 5. möglichst stabil mit dem realen Objekt verbunden sein 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie verbunden ist. Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit einer Query-basierten Lösung praktisch automatisch gelöst würde, wird von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu dieser Frage ist es schon prinzipbedingt nicht lösbar. Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht, wiederhergestellt, dupliziert wird, und wie es von einem. Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID eigentlich bezieht. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 08:20, schrieb Tobias Knerr: Am 27.07.2012 08:00, schrieb Markus: Eine ID muss m.E. [...] 4. möglichst stabil mit dem OSM-Objekt verbunden sein 5. möglichst stabil mit dem realen Objekt verbunden sein 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie verbunden ist. Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit einer Query-basierten Lösung praktisch automatisch gelöst würde, wird von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu dieser Frage ist es schon prinzipbedingt nicht lösbar. Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht, wiederhergestellt, dupliziert wird, und wie es von einem. Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID eigentlich bezieht. ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Klar - das könnte man auch einfacher haben, weil es letztlich genau der Idee stabiler IDs nach overpass bzw. query2map entspricht und man dann keine ID mehr in OSM einpflegen braucht, aber die entsprechend zu referenzierenden Attribute mit der ID zu verknüpfen, ist soweit ich das bisher sehe, weitgehend alternativlos. Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf dieses Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr erkennbar. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
Frederik Ramm frede...@remote.org schrieb: Hallo, der eine oder andere mag vom redaction bot ueberrascht worden sein und wuenscht sich, er koennte noch mit den alten Daten weiterarbeiten. Das ist ja auch rechtlich gar kein Problem - solang man die CC-BY-SA-Lizenz einhaelt, kann man damit machen, was man will. Ich habe auf http://download.geofabrik.de/osm-before-redaction/ einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der Nacht vollstaendig.) Die sind logischerweise statisch, sie werden nicht aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM insgesamt wieder von dem Bot erholt hat. 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Moin Tobias, Danke für diese wesentliche Ergänzung! Eine ID muss m.E. [...] 4. möglichst stabil mit dem OSM-Objekt verbunden sein 5. möglichst stabil mit dem realen Objekt verbunden sein 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie verbunden ist. Genau das sind die entscheidenden Fragen: wann ist ein Restaurant noch dasselbe Restaurant worauf bezieht sich die ID eigentlich Und da jedes externe Projekt seine eigene verschiedene Sicht hat, ergeben sich folglich Missverständnisse. Hier brauchen wir eine Definition, eine die von OSM ausgeht, die möglichst eindeutig beschreibt wie wir unsere Daten verstehen. Und dann brauchen wir eine auch für Anfänger und Gelegenheits-Mapper verständliche illustrierte Beschreibung. Idealerweise sind die Regeln möglichst intuitiv verständlich. Beispiel: Wenn Du in einem Park Bäume zeichnest, dann kannst Du erst /einen/ Baum zeichnen, und diesen dann einfach mit Strg-d duplizieren und die Kopie an den Ort des nächsten Baumes verschieben. Wenn dort aber schon ein Baum ist, musst Du erst prüfen, was für Eigenschaften er hat. Denn vielleicht ist er ja eine Tanne, und der Baum den Du einzeichnen willst ist eine Eiche. Oder der Baum wird vom Gartenbauamt gepflegt, und der den Du zeichnen willst von der Friedhofsverwaltung. Hier kannst DU zwar immer noch duplizieren, aber Du musst dann die nicht-zutreffenden Eigenschaften löschen bzw. ändern, und neu hinzugekommene Eigenschaften hinzufügen. Query-basierte Lösung Wie könnte sowas genau aussehen? (Beispiele) Was ist der technische Aufwand? Was sind Vor- und Nachteile? Mit einer einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu dieser Frage ist es schon prinzipbedingt nicht lösbar. Ja. Deswegen brauchen wir eine OSM-Definition zur Bedeutung der ID. Gruss, Markus - - - - Beispiel *Haus*: Status 1: (ID-1) Das Haus gehört einem Besitzer, der Besitzer hat es verpachtet an einen Restaurant-Betreiber, das Restaurant heisst Linde Status 2: (immer noch ID-1?) Der Restaurant-Betreiber macht Pleite, das Restaurant wird von einem neuen Pächter übernommen und heisst nun Hirsch Status 3: (ID-?) Auch der neue Pächter hat Schwierigkeiten. Er verkleinert den Hirsch. in der verbleibenden Haushälfte zieht ein Video-Verleih ein. Status 4: Der Pächter mit dem Video-Verleih übernimmt das ganze Haus durch Kauf, aus dem Hirsch wird der Massagesalon Cleopatra. Status 5: Der neue Besitzer kauft auch noch die kleine Halle nebenan, dort baut er eine Sauna ein, das Obergeschoss wird zur Bar mit Nebenzimmern, das Gelände bekommt einen begrünten Zaun und einen bewachten Eingang und einen Parkplatz. (Area) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
Am 27.07.2012 00:06, schrieb Frederik Ramm: Ich habe auf http://download.geofabrik.de/osm-before-redaction/ einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der Nacht vollstaendig.) Super, vielen Dank! Die sind logischerweise statisch, sie werden nicht aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM insgesamt wieder von dem Bot erholt hat. Na Du bist ja optimistisch. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity dazu. Wenn Gebäude und Funktion einmal unabhängig voneinander werden (Restaurant zieht auf andere Straßenseite um), dann verbleibt das uuid:building dort wo es war und das uuid:amenity zieht mit dem Restaurant auf die andere Straßenseite um. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
Wenn ich auch editiern wollt, gibt es einen API server bei fosm.org um weiter mit cc-by-sa zu machen. mike 2012/7/27 Chris66 chris66...@gmx.de Am 27.07.2012 00:06, schrieb Frederik Ramm: Ich habe auf http://download.geofabrik.de/osm-before-redaction/ einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der Nacht vollstaendig.) Super, vielen Dank! Die sind logischerweise statisch, sie werden nicht aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM insgesamt wieder von dem Bot erholt hat. Na Du bist ja optimistisch. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org http://flossk.orgSaving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
Da gibt es übrigens nichtmal mehr einen Planet zum laden. Das ist also nach aktuellem Stand eine Einbahnstraße. Ich wünsch dann mal noch viel Spaß. Grüße Am 27.07.2012 11:01, schrieb Mike Dupont: Wenn ich auch editiern wollt, gibt es einen API server bei fosm.org um weiter mit cc-by-sa zu machen. mike 2012/7/27 Chris66 chris66...@gmx.de Am 27.07.2012 00:06, schrieb Frederik Ramm: Ich habe auf http://download.geofabrik.de/osm-before-redaction/ einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der Nacht vollstaendig.) Super, vielen Dank! Die sind logischerweise statisch, sie werden nicht aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM insgesamt wieder von dem Bot erholt hat. Na Du bist ja optimistisch. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
es gibt einen planet von april : http://pine02.fosm.org/planet/earth-20120401130001.osm.bz2 2012/7/27 Björn Sieper ac...@gmx.net Da gibt es übrigens nichtmal mehr einen Planet zum laden. Das ist also nach aktuellem Stand eine Einbahnstraße. Ich wünsch dann mal noch viel Spaß. Grüße Am 27.07.2012 11:01, schrieb Mike Dupont: Wenn ich auch editiern wollt, gibt es einen API server bei fosm.org um weiter mit cc-by-sa zu machen. mike 2012/7/27 Chris66 chris66...@gmx.de Am 27.07.2012 00:06, schrieb Frederik Ramm: Ich habe auf http://download.geofabrik.de/**osm-before-redaction/http://download.geofabrik.de/osm-before-redaction/ einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der Nacht vollstaendig.) Super, vielen Dank! Die sind logischerweise statisch, sie werden nicht aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM insgesamt wieder von dem Bot erholt hat. Na Du bist ja optimistisch. ;-) Chris __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org http://flossk.orgSaving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 10:38, schrieb Manuel Reimer: Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity dazu. Wenn Gebäude und Funktion einmal unabhängig voneinander werden (Restaurant zieht auf andere Straßenseite um), dann verbleibt das uuid:building dort wo es war und das uuid:amenity zieht mit dem Restaurant auf die andere Straßenseite um. Wie soll das dann in der Praxis aussehen. Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann uuid nehmen, oder gleich uuid:building. In der Regel ist es wohl so, dass der erste uuid setzt und alle weiteren dann Unterwerte...aber woher weiß ich dann als Unterwertsetzer, worauf sich die uuid bezieht? Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
aighes wrote: Wie soll das dann in der Praxis aussehen. Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann uuid nehmen, oder gleich uuid:building. Erst der Datennutzer sollte ein UUID setzen. Warum sollte ein Mapper nur so aus Spaß an der Freude überall UUID-Tags drankleben? Und wenn der Datennutzer das Gebäude referenzieren will, dann direkt uuid:building. Ein reines uuid-Tag würde ich garnicht erst propagieren. In der Regel ist es wohl so, dass der erste uuid setzt und alle weiteren dann Unterwerte...aber woher weiß ich dann als Unterwertsetzer, worauf sich die uuid bezieht? Garnicht. Deshalb auch kein reines uuid-Tag. Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ? Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 12:09, schrieb Manuel Reimer: aighes wrote: Wie soll das dann in der Praxis aussehen. Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann uuid nehmen, oder gleich uuid:building. Erst der Datennutzer sollte ein UUID setzen. Warum sollte ein Mapper nur so aus Spaß an der Freude überall UUID-Tags drankleben? Das schreibt Manuel aber doch: Wenn ich ein Gebäude mit Restaurant indizieren möchte - also Datennutzer. Und wenn der Datennutzer das Gebäude referenzieren will, dann direkt uuid:building. Ein reines uuid-Tag würde ich garnicht erst propagieren. Also setze ich meine uuid:building? oder uuid:restaurant? oder uuid:buildingrestaurant? Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, sondern das Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname? Ich bin, ehrlich gesagt, immer noch nicht überzeugt, wie das funktionieren soll. In der Regel ist es wohl so, dass der erste uuid setzt und alle weiteren dann Unterwerte...aber woher weiß ich dann als Unterwertsetzer, worauf sich die uuid bezieht? Garnicht. Deshalb auch kein reines uuid-Tag. Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ? Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt? Langsam wird das System komisch... Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 12:09, schrieb Manuel Reimer: Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Betreiber ist der selbe. Ergo, wie du sagst eine uuid:amenity=1. Nun meint ein Mapper das ist aber blöd, mein Garmin zeigt das falsch an, ich teile das auf zwei Nodes auf. Was nun: beide nodes mit uuid:amenity=1 oder mit unterschiedlicher uuid:amenity? Aber egal wie ich es mache, als Betreiber des Portals würde ich doch nun gerne eine Meldung bekommen und mir die Sache anschauen um dann selber zu entscheiden, ob ich mich für das Cafe interessiere, das Restaurant oder gar für beides. Dementsprechend müsste ich dann meine Links anpassen. Wenn ich keine uuid hätte sondern nur die osm-id, dann würde es auf das gleiche hinauslaufen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Peter Wendorff wrote: Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, sondern das Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname? Nur uuid:amenity. Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt? Langsam wird das System komisch... Nicht nur die UUID passt nicht, sondern eventuell hat ja auch das Cafe einen anderen Namen wie das Restaurant. Zudem kann man nur so den Betreiber korrekt zuordnen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 13:01, schrieb Manuel Reimer: Peter Wendorff wrote: Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, sondern das Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname? Nur uuid:amenity. Also ist der Link kaputt, wenn das Restaurant dann Zur Dorflinde heißt und statt gutbürgerlicher Küche auf einmal Thailändisch kocht. Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt? Langsam wird das System komisch... Nicht nur die UUID passt nicht, sondern eventuell hat ja auch das Cafe einen anderen Namen wie das Restaurant. Zudem kann man nur so den Betreiber korrekt zuordnen. WENN das Cafe einen anderen Namen hat und von einem anderen Betreiber geführt wird, dann sind das meist in OSM sowieso zwei Nodes. Ein Cafe/Restaurant, das also nicht nur kocht, sondern eben gerade auch Torten, Kuchen und Eis anbietet, ist ja durchaus üblich, selbst als eine einzelne Einrichtung - unter anderem mit identischem Betreiber. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Peter, Ein Cafe/Restaurant, das also nicht nur kocht, sondern eben gerade auch Torten, Kuchen und Eis anbietet, ist ja durchaus üblich Hier hat unser Tagging-Schema noch Entwicklungsbedarf, da Schlüssel pro Objekt ja nur einmal verwendet werden dürfen. (es sei denn man macht so Konstrukte wie amenity=cafe;restaurant) Auch werden oft in einem Attribut verschiedene Klassen vermischt. (Funktion und Beschaffenheit bei Wegen beispielsweise) Und Objekte enthalten Eigenschaften, die additiv abgebildet werden (Betreiber, Küche, Hotel|Restaurant|Cafe|Bar, etc) aber eigentlich relational sind und normalisiert werden müssten, damit das mit der ID klappt. Anhand der ID-Frage wird das alles nur grad etwas deutlicher. Gruss, Markus PS: bitte keine Tagging-Disku lostreten - es geht um's System ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Rainer Am 27. Juli 2012 07:31 schrieb Rainer Kluge rklug...@web.de: On 26.07.2012 23:23, Stefan Keller wrote: Am 26. Juli 2012 18:57 schrieb Peter Wendorffwendo...@uni-paderborn.de: Vorausgesetzt, die PID/UUID wird mit kopiert Das stimmt. Dabei sind wir uns aber wohl aber einig, dass der Normalfall für den einfachen Mapper. Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal nicht den Normalfall meint. Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des Mappers funktionieren würde. Die allermeisten Spezialfälle die gegen die UUID/PID angeführt werden, müssen in der externen Datenbank gelöst werden. Solche hohe Ansprüche bei der noch die Absicht des Mappers einbezogen wird, erfüllt kein ID-System - und muss es auch nicht! Es kommt mir vor als ob wir hier die Objektorientierung neu erfinden (bzw. in Frage stellen) wollten, die gegenüber dem Relationalen Modell postuliert hat, dass nicht die Gesamtheit aller Werte eines Tupels das Tupel identifizieren, sondern dass jedem systeminternen Objekt eine ID zugeordnet wird. Das ist die OSM-ID. Diese soll reorganisiert werden können, ohne dass jedwelche Nutzer in Problem damit haben. Es gibt also tatsächlich gute Gründe, dass die OSM ID eine 100% OSM-interne Angelegenheit ist. Mit UUID/PID erhalten wir eine permanente/stabile OSM-ID gegen aussen (oder externe ID oder UUID/PID) und decken damit 80% der Fälle automatisch (nach der 80/20 Regel). Die restlichen 20% können in der externen Datenbank gelöst werden (dazu gab es hier bereits interessante Vorschläge) und müssen - wie gesagt - letztlich wieder von Menschen beurteilt werden. Ich sehe hier folgende Vorstellungen: Für die einen (A) wird die externe ID direkt in OSM mitverwaltet, bei der anderen ist eine Softwarekomponente dafür zuständig. Letztere wiederum organisiert sich (B1) eine solche externe ID, indem sie entweder versucht, mit den OIDs klar zu kommen - oder (B2) aber solche externe ID in OSM. Ich tendiere zu B2. Nun diskutieren wir die verbleibenden 20% der Fälle - und was auch immer herauskommt: 80% Automatisierung gegenüber vorher ist doch schon mal nicht schlecht, oder? In allen nachfolgenden Fällen ist der Editor auf einen Entscheidung des Bedieners angewiesen: - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem gelöschten oder ist es ein anderes, neues Objekt? Es ist identisch, denn die UUID/PID ist gleich. Jedwelche Ansprüche, ob das nun mit der Realität oder der Absicht des Mappers übereinstimmt überlassen wir den Fachdatenbanken/Nutzern. Wie gesagt: Der Normalfall ist, dass der Mapper etwas verändert (verschiebt, ergänzt, etc.) wenn es an allen Attributen (inkl. Geometrie) eine Änderung gibt und er löscht, wenn ein Objekt der Realität gelöscht wird. Das gilt selbstredend für gute Editoren und automatisierte Prozesse. - Ausschneiden und mehrmals Einfügen. Welches der eingefügten Objekte ist das verschobene Originalobjekt? Ähnlicher Spezialfall wie oben. Grundsätzlich tut man nach gesundem Menschenverstand nicht ausschneiden und grad wieder am selbern Ort dasselbe Objekt einfügen, nur um eine Vorlage zu haben für weitere Objekte (vgl. unten). Da müsste ein schlauer Editor beim Einfügen nur einem Objekt die UUID/PID vergeben und/oder ggf. eine Warnung ausgeben (er erkennt das an der noch festzulegenden Konvention. dass das Tag mit _id endet). Die anderen kriegen keine UUID/PID. - Kopieren und Einfügen, Löschen des Originals. Im Moment des Einfügens weiß der Editor noch nichts von dem späteren Löschen. Soll er die ID kopieren? Wenn ja, was passiert, wenn dann doch nicht gelöscht wird? Ein Konflikt beim Hochladen? Bei diesem Spezialfall gibt der Editor schon beim Einfügen eine Warnung aus (analog Fall vorher). LG, Stefan Am 27. Juli 2012 07:31 schrieb Rainer Kluge rklug...@web.de: On 26.07.2012 23:23, Stefan Keller wrote: Am 26. Juli 2012 18:57 schrieb Peter Wendorffwendo...@uni-paderborn.de: Vorausgesetzt, die PID/UUID wird mit kopiert Das stimmt. Dabei sind wir uns aber wohl aber einig, dass der Normalfall für den einfachen Mapper. Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal nicht den Normalfall meint. Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des Mappers funktionieren würde. In allen nachfolgenden Fällen ist der Editor auf einen Entscheidung des Bedieners angewiesen: - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem gelöschten oder ist es ein anderes, neues Objekt?
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung aber sicher nicht für die Anwendungsfälle zur datenbankmässigen Verknüpfung. Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören. Da ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet wird und gegen aussen eine UUID/PID angeboten wird. LG, Stefan Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 08:20, schrieb Tobias Knerr: Am 27.07.2012 08:00, schrieb Markus: Eine ID muss m.E. [...] 4. möglichst stabil mit dem OSM-Objekt verbunden sein 5. möglichst stabil mit dem realen Objekt verbunden sein 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie verbunden ist. Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit einer Query-basierten Lösung praktisch automatisch gelöst würde, wird von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu dieser Frage ist es schon prinzipbedingt nicht lösbar. Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht, wiederhergestellt, dupliziert wird, und wie es von einem. Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID eigentlich bezieht. ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Klar - das könnte man auch einfacher haben, weil es letztlich genau der Idee stabiler IDs nach overpass bzw. query2map entspricht und man dann keine ID mehr in OSM einpflegen braucht, aber die entsprechend zu referenzierenden Attribute mit der ID zu verknüpfen, ist soweit ich das bisher sehe, weitgehend alternativlos. Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf dieses Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr erkennbar. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Manuel Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Dann meinen wir dasselbe mit PID und deiner Auffassung von UUID. Üblich ist aber m.E. die Auffassung, dass UUIDs nur ein einziges Mal an ein Objekt gehängt werden. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity ... Das scheint mir aber zu weit zu gehen und hier verstehe ich Frederiks Bedenken Solch eine inflationäre Vergabe ist m.E. nicht nötig. Ich stelle mir das so vor, dass die Fachdatenbank einfach nimmt, was es in OSM gibt. Das löst ein Einfügen einer PID aus. Wenn eine andere Fachdatenbank damit nicht leben kann, dann muss sie das intern lösen. Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. LG, Stefan Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity dazu. Wenn Gebäude und Funktion einmal unabhängig voneinander werden (Restaurant zieht auf andere Straßenseite um), dann verbleibt das uuid:building dort wo es war und das uuid:amenity zieht mit dem Restaurant auf die andere Straßenseite um. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Wollte sagen: Da ist Variante B1 oben *sinnvoller*, bei der gegen die OSM-DB die OID verwendet wird und gegen aussen eine UUID/PID angeboten wird. Am 27. Juli 2012 16:16 schrieb Stefan Keller sfkel...@gmail.com: Hallo Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung aber sicher nicht für die Anwendungsfälle zur datenbankmässigen Verknüpfung. Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören. Da ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet wird und gegen aussen eine UUID/PID angeboten wird. LG, Stefan Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 08:20, schrieb Tobias Knerr: Am 27.07.2012 08:00, schrieb Markus: Eine ID muss m.E. [...] 4. möglichst stabil mit dem OSM-Objekt verbunden sein 5. möglichst stabil mit dem realen Objekt verbunden sein 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie verbunden ist. Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit einer Query-basierten Lösung praktisch automatisch gelöst würde, wird von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu dieser Frage ist es schon prinzipbedingt nicht lösbar. Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht, wiederhergestellt, dupliziert wird, und wie es von einem. Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID eigentlich bezieht. ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Klar - das könnte man auch einfacher haben, weil es letztlich genau der Idee stabiler IDs nach overpass bzw. query2map entspricht und man dann keine ID mehr in OSM einpflegen braucht, aber die entsprechend zu referenzierenden Attribute mit der ID zu verknüpfen, ist soweit ich das bisher sehe, weitgehend alternativlos. Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf dieses Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr erkennbar. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 16:16, schrieb Stefan Keller: Hallo Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung aber sicher nicht für die Anwendungsfälle zur datenbankmässigen Verknüpfung. Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören. Genau das, was ich will: Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes Objekt betrachten, also SOLL die ID doch kaputtgehen. Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes Objekt betrachten, also SOLL die ID kaputtgehen. Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches betrachten, also SOLL die ID kaputtgehen. Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht, reicht mir [amenity=restaurant;addr:street=Schlemmerstraße]. Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern muss. Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise nicht. Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter Kriterien, und die kann ich in Attributen fassen, die dann einer ID ähnlich sind. Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet wird und gegen aussen eine UUID/PID angeboten wird. Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API schon, ohne zusätzliche Tags oder Attribute. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Solche Fragen, ob es bei der Änderung eines Restaurantnamens nun dasselbe Objekt ist oder nicht, stellen sich bei allen Systemen, sogar bei simplen Adressdatenbanken. Das würde ich im Zweifelsfalle, den Fachdatenbanken überlassen. Alle sind sich ja einig, das OSM relativ grosszügig ist und man zunächst einfach mal das taggen, was man sieht. An dieser Stelle möchte ich nochmals eine Idee von Frederik adaptieren, die er schon am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org formuliert hat. ... Was aber eine gute Idee waere: Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese Datenbank permanente Schluessel - seien das UUIDs oder Nummern oder sonstwas. Zu OSM hin benutzt diese Datenbank das Overpass-Permanent-ID-Konzept (das nicht von Roland erfunden wurde, sondern ursrpuenglich mal von Tim Alder mit seinem query to map angedacht worden war). Jeder kann bei Bedarf einen Link in dieser Datenbank anlegen lassen und den dann ueberall benutzen. Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat dieses Vorgehen den Vorteil, dass alle Links in der Datenbank regelmaessig automatisiert ueberprueft werden koennen: Sind sie noch gueltig? Zeigen sie noch auf genau 1 Objekt, oder mittlerweile auf 0 oder 2? Es waere trivial, in dieser Datenbank eine Liste zu generieren mit allen kaputten Links; es waere sogar moeglich, diese nach Nutzungsintensitaet zu sortieren, so dass viel genutzte Links von Freiwilligen sofort repariert werden koennen, wenn sie kaputt gehen. Es waere sogar denkbar, in dieser Datenbank das letzte bekannte gute Ergebnis aus OSM zu cachen fuer jeden Link, so dass man, selbst wenn bei OSM was kaputt geht, dem Anfrager immer noch wenigstens eine alte Version ausliefern kann. Wie gesagt, bin ich immer noch der Meinung, dass die zwei anderen Alternativen vorziehen, nämlich dass sich das Interface (ich nenne es LinkedOSMDB) entweder (B1) halt mit OIDs herumschlägt oder (B2) eine PID auch im OSM-Objekt einführt. Analog zur Idee oben, könnte die LinkedOSMDB Listen anbieten, wo Freiwillige mithelfen beim Reparieren und Entscheiden, was nun Sache ist. LG, Stefan Am 27. Juli 2012 13:43 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 13:01, schrieb Manuel Reimer: Peter Wendorff wrote: Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, sondern das Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname? Nur uuid:amenity. Also ist der Link kaputt, wenn das Restaurant dann Zur Dorflinde heißt und statt gutbürgerlicher Küche auf einmal Thailändisch kocht. Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt? Langsam wird das System komisch... Nicht nur die UUID passt nicht, sondern eventuell hat ja auch das Cafe einen anderen Namen wie das Restaurant. Zudem kann man nur so den Betreiber korrekt zuordnen. WENN das Cafe einen anderen Namen hat und von einem anderen Betreiber geführt wird, dann sind das meist in OSM sowieso zwei Nodes. Ein Cafe/Restaurant, das also nicht nur kocht, sondern eben gerade auch Torten, Kuchen und Eis anbietet, ist ja durchaus üblich, selbst als eine einzelne Einrichtung - unter anderem mit identischem Betreiber. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Am 27. Juli 2012 16:52 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:16, schrieb Stefan Keller: Hallo Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung aber sicher nicht für die Anwendungsfälle zur datenbankmässigen Verknüpfung. Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören. Genau das, was ich will: Ok. Dann bin ich reden wir aber von ganz verschiedenen Anwendungsfällen :- Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes Objekt betrachten, also SOLL die ID doch kaputtgehen. Stimmt. Das ist ein gerechtfertigtes Löschen und einfügen. Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes Objekt betrachten, also SOLL die ID kaputtgehen. Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele zusammengetragen, wo die Koordinaten sich ändern, in dem ganze Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer dieser Verschiebung nicht traut, kann selber nachschauen - das aber nicht auf Kosten der anderen verlangen, dass die Bushaltestelle damit à priori eine andere sei. Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches betrachten, also SOLL die ID kaputtgehen. Das sind alle Systeme gleich. Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht, reicht mir [amenity=restaurant;addr:street=Schlemmerstraße]. Das ist kein Anwendungsfall, um den es mir hier geht. Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern muss. Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise nicht. Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter Kriterien, und die kann ich in Attributen fassen, die dann einer ID ähnlich sind. Nein: Ich möchte lediglich eine permanente/stabile ID anbieten und die Kriterien, nach denen das getan wird den Nutzern überlassen. Ich möchte einzig eine Lösung, welche nach aussen unabhängig ist von OSM-IDs und nach der OSM-DB eindeutig ist in Bezug auf das OSM-Objekt. Daher kommt eine (nicht von aussen ersichtliche) Kombination von Tags und ein Ausschluss nicht-mit-normalen-Tags-identifiziertbarer OSM-Objekte nicht in Frage. Dies gesagt, halte ich aber immer noch ein Türchen offen für Argumente, die für B1 sprechen, bei der die Interface-DB (LinkedOSMDB) sich mit OIDs herumschlägt. Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet wird und gegen aussen eine UUID/PID angeboten wird. Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API schon, ohne zusätzliche Tags oder Attribute. Die Overpass-API ist alles andere als stabil gemäss meinen Kriterien. Das wäre dann Lösungsvariante B3. LG, Stefan Am 27. Juli 2012 16:52 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:16, schrieb Stefan Keller: Hallo Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...Dann bauen wir die ID doch so auf, dass das eindeutig ist: projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...] = 12423528312313513412351341351 Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung aber sicher nicht für die Anwendungsfälle zur datenbankmässigen Verknüpfung. Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören. Genau das, was ich will: Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes Objekt betrachten, also SOLL die ID doch kaputtgehen. Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes Objekt betrachten, also SOLL die ID kaputtgehen. Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches betrachten, also SOLL die ID kaputtgehen. Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht, reicht mir [amenity=restaurant;addr:street=Schlemmerstraße]. Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern muss. Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise nicht. Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter Kriterien, und die kann ich in
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 16:23, schrieb Stefan Keller: Hallo Manuel Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Dann meinen wir dasselbe mit PID und deiner Auffassung von UUID. Üblich ist aber m.E. die Auffassung, dass UUIDs nur ein einziges Mal an ein Objekt gehängt werden. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity ... Das scheint mir aber zu weit zu gehen und hier verstehe ich Frederiks Bedenken Solch eine inflationäre Vergabe ist m.E. nicht nötig. Ich stelle mir das so vor, dass die Fachdatenbank einfach nimmt, was es in OSM gibt. Das löst ein Einfügen einer PID aus. Wenn eine andere Fachdatenbank damit nicht leben kann, dann muss sie das intern lösen. Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. Oh, das ist gut. Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt, z.B. die ID, die das Objekt schon aus osm hat. Solange mein Bot der schnellste ist, bin ich immer der erste und alle anderen müssen damit klarkommen. Danke - benutzen wir doch einfach die OSM-ID direkt und lassen alle Datenbanken damit klarkommen, das läuft nämlich auch hier wieder aufs gleiche raus: Die Funktionalität zum Klarkommen müssen dann alle unterstützen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Lieber Peter Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:23, schrieb Stefan Keller: ... Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. Oh, das ist gut. Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt, z.B. die ID, die das Objekt schon aus osm hat. Solange mein Bot der schnellste ist, bin ich immer der erste und alle anderen müssen damit klarkommen. Ich habe niemals von einem Bot gesprochen, sondern dass die Interface-DB immer dann eine PID vergibt, wenn ein OSM-Objekt verlinkt wird und zwar als PID gegen aussen und als PID auf dem OSM-Objekt. Diese PID wird dann von möglichst vielen via LinkdOSMDB genutzt. Ein OSM-Objekt - eine PID, fertig. Zudem: Mapper erkennen die ID-Eigenschaft und Freiwillige helfen, Spezialfälle zu fixen, wie sie oben z.T. oben diskutiert worden sind. Danke - benutzen wir doch einfach die OSM-ID direkt und lassen alle Datenbanken damit klarkommen, das läuft nämlich auch hier wieder aufs gleiche raus: Die Funktionalität zum Klarkommen müssen dann alle unterstützen. Ja; die Variante B1 mit der OSM-ID als Link zwischen Interface-DB und OSM behalte ich im Auge. LG, Stefan Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:23, schrieb Stefan Keller: Hallo Manuel Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Dann meinen wir dasselbe mit PID und deiner Auffassung von UUID. Üblich ist aber m.E. die Auffassung, dass UUIDs nur ein einziges Mal an ein Objekt gehängt werden. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity ... Das scheint mir aber zu weit zu gehen und hier verstehe ich Frederiks Bedenken Solch eine inflationäre Vergabe ist m.E. nicht nötig. Ich stelle mir das so vor, dass die Fachdatenbank einfach nimmt, was es in OSM gibt. Das löst ein Einfügen einer PID aus. Wenn eine andere Fachdatenbank damit nicht leben kann, dann muss sie das intern lösen. Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. Oh, das ist gut. Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt, z.B. die ID, die das Objekt schon aus osm hat. Solange mein Bot der schnellste ist, bin ich immer der erste und alle anderen müssen damit klarkommen. Danke - benutzen wir doch einfach die OSM-ID direkt und lassen alle Datenbanken damit klarkommen, das läuft nämlich auch hier wieder aufs gleiche raus: Die Funktionalität zum Klarkommen müssen dann alle unterstützen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
On 07/26/2012 11:41 AM, Frederik Ramm wrote: Ich hab jetzt bei den roten Sachen noch die Moeglichkeit eingebaut, sie von der Karte zu werfen, mit einem Muelleimer-Icon irgendwie ist alles was ich gestern gelöscht habe heute wieder da, und auch mein Löschliebling, die Humboldtstraße in Bielefeld, ist jetzt auf meinem Laptop wieder rot obwohl ich die heute morgen auf meinem Desktop noch einmal gelöscht habe? http://tools.geofabrik.de/osmi/?view=redactionbotlon=8.51703lat=52.02503zoom=16overlays=overview,bot_point_superseded,bot_line_superseded_cp,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 17:15, schrieb Stefan Keller: Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes Objekt betrachten, also SOLL die ID kaputtgehen. Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele zusammengetragen, wo die Koordinaten sich ändern, in dem ganze Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer dieser Verschiebung nicht traut, kann selber nachschauen - das aber nicht auf Kosten der anderen verlangen, dass die Bushaltestelle damit à priori eine andere sei. Wenn ich dich richtig verstehe, ist es dir/dem Projekt also egal, wenn das OSM-Objekt von Hamburg nach Berlin verschoben wird? Wenn ich das Projekt betreiben würde, würde mich diese Änderung schon interessieren. Mein Gedankengang wäre dieser: OSM-DB, gib mir mein Objekt mit der ID x Dann prüfe ich, ob das Objekt noch da ist, wo ich es vermute, ob es noch die Eigenschaften hat, die ich vermute und dann nutze ich diese Infos. Wenn nicht möchte ich eine Info bekommen und dann nachschauen/nachschauen lassen. Wie eng ich die Grenzen setze, muss ich mir dann überlegen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 17:31, schrieb Stefan Keller: Lieber Peter Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:23, schrieb Stefan Keller: ... Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. Oh, das ist gut. Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt, z.B. die ID, die das Objekt schon aus osm hat. Solange mein Bot der schnellste ist, bin ich immer der erste und alle anderen müssen damit klarkommen. Ich habe niemals von einem Bot gesprochen, sondern dass die Interface-DB immer dann eine PID vergibt, wenn ein OSM-Objekt verlinkt wird und zwar als PID gegen aussen und als PID auf dem OSM-Objekt. Diese PID wird dann von möglichst vielen via LinkdOSMDB genutzt. Ein OSM-Objekt - eine PID, fertig. Zudem: Mapper erkennen die ID-Eigenschaft und Freiwillige helfen, Spezialfälle zu fixen, wie sie oben z.T. oben diskutiert worden sind. Das funktioniert aber nicht. Ich bin dummerweise das zweite Projekt, das eine ID auf ein OSM-Objekt braucht, und dummerweise ist die aber anders definiert, weil ich wirklich das Gebäude aufgrund der historischen Bausubstanz meine, die PID aber dummerweise auf das Restaurant verweist. Wenn ich von der LinkdOSMDB keine ID für meine Zwecke kriege, habe ich nichts gewonnen. Wenn ich von der LinkdOSMDB nur dann eine ID kriege, wenn zufällig sonst niemand anders vorher eine hatte, habe ich nichts gewonnen. In beiden Fällen muss ich nämlich doch eine Fallback-Lösung implementieren, die der von mir gewünschten ID entspricht, womit wir wieder beim Anfang wären. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 19:20, schrieb Peter Wendorff: Am 27.07.2012 17:31, schrieb Stefan Keller: Lieber Peter Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:23, schrieb Stefan Keller: ... Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. Oh, das ist gut. Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt, z.B. die ID, die das Objekt schon aus osm hat. Solange mein Bot der schnellste ist, bin ich immer der erste und alle anderen müssen damit klarkommen. Ich habe niemals von einem Bot gesprochen, sondern dass die Interface-DB immer dann eine PID vergibt, wenn ein OSM-Objekt verlinkt wird und zwar als PID gegen aussen und als PID auf dem OSM-Objekt. Diese PID wird dann von möglichst vielen via LinkdOSMDB genutzt. Ein OSM-Objekt - eine PID, fertig. Zudem: Mapper erkennen die ID-Eigenschaft und Freiwillige helfen, Spezialfälle zu fixen, wie sie oben z.T. oben diskutiert worden sind. Das funktioniert aber nicht. Ich bin dummerweise das zweite Projekt, das eine ID auf ein OSM-Objekt braucht, und dummerweise ist die aber anders definiert, weil ich wirklich das Gebäude aufgrund der historischen Bausubstanz meine, die PID aber dummerweise auf das Restaurant verweist. Wenn ich von der LinkdOSMDB keine ID für meine Zwecke kriege, habe ich nichts gewonnen. Wenn ich von der LinkdOSMDB nur dann eine ID kriege, wenn zufällig sonst niemand anders vorher eine hatte, habe ich nichts gewonnen. In beiden Fällen muss ich nämlich doch eine Fallback-Lösung implementieren, die der von mir gewünschten ID entspricht, womit wir wieder beim Anfang wären. Hallo, nein, diese PID würde, wenn ich es richtig verstanden habe, auf das OSM-Objekt in Gänze. Sprich die Bauwerk-DB und die Restaurant-DB würden auf die gleiche PID linken. Die beiden Projekte müssen dann nur unterschiedlich auf eine Änderung reagieren. Daher hab ich ja das große Problem, dass ich keinen Vorteil gegenüber der OSM-ID sehe. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Aufruf zu einer Sommeraktion in MV - Meilensteine
Moin ! derzeit sind viele von Euch in MV im Urlaub unterwegs (deshalb das Posting in der bundesweiten ML) und ich wollte Euch um eine Mithilfe bitten. Wie dem einen oder anderen bekannt führe ich die Grenz- und Meilensteinkarte [1] und im angegeben Bereich sind viele Steine noch mit einem Fixme versehe (Lageverbesserung) und überhaupt fehlen Bilder der betreffenden Steine. Wenn Ihr diesen also begegnet, dann wäre es klasse die Lage zu verbessern und ein hübsches Bild zu erstellen (bei den mit dem roten Kreis ist das bereits geschehen). Ich habe es immer so gemacht das ich die Bilder bei Wikipedia hochgeladen habe. Wenn einer Bilder hat, aber keine Lust auf Wikipedia hat möge er mir diese Mailen. Ich lade die dann hoch (Autor bis Du, Lizenz gebe ich dann mit gemeinfrei an). Würde mich sehr freuen, wenn einige der grünen Kreise verschwinden würden. Im angrenzenden Bereich zwischen Ribnitz-Damgarten und Stralsund könnten weitere Steine stehen - wie auch in anderen Landesteilen. Wer auf dem Darß ist und interesse hat dem möchte ich einen Blog-Beitrag von mir [2] empfehlen. Dort ist übrigens im Osten der Insel noch der neue Deich und die damit verbundenen Weg einzumessen [3]. Gruß Jan :-) [1] http://www.tappenbeck.net/osm/maps/deu/index.php?id=1044zoom=10lat=53.94822lon=11.78469layers=BFTTTlang=de [2] http://blog.tappenbeck.net/2011/10/24/zingst-dreilandereck/ [3] http://www.tappenbeck.net/osm/maps/deu/index.php?id=1044zoom=14lat=54.42938lon=12.85955layers=BFTTTlang=de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Ja, kann ich nachvollziehen. Sehr ärgerlich. Am 27. Juli 2012 17:36 schrieb Hartmut Holzgraefe hartmut.holzgra...@gmail.com: On 07/26/2012 11:41 AM, Frederik Ramm wrote: Ich hab jetzt bei den roten Sachen noch die Moeglichkeit eingebaut, sie von der Karte zu werfen, mit einem Muelleimer-Icon irgendwie ist alles was ich gestern gelöscht habe heute wieder da, und auch mein Löschliebling, die Humboldtstraße in Bielefeld, ist jetzt auf meinem Laptop wieder rot obwohl ich die heute morgen auf meinem Desktop noch einmal gelöscht habe? http://tools.geofabrik.de/osmi/?view=redactionbotlon=8.51703lat=52.02503zoom=16overlays=overview,bot_point_superseded,bot_line_superseded_cp,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hi, On Fri, 27 Jul 2012 21:48:42 +0200 André Riedel riedel.an...@gmail.com wrote: Ja, kann ich nachvollziehen. Sehr ärgerlich. Keine Panik, die Sachen werden alle in einem File protokolliert, wenn sie geloescht werden, und dann beim Neubau der Datenbank wieder appliziert - eventuell ist da was schiefgelaufen, aber die Files sind auf jeden Fall noch da, ich guck mir das mal genauer an. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
