subject:"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] Permanente/stabile OSM IDs!

2012-07-27 Diskussionsfäden Markus


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] Permanente/stabile OSM IDs!

2012-07-27 Diskussionsfäden 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.


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 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!

2012-07-27 Diskussionsfäden 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?


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!

2012-07-27 Diskussionsfäden 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.


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!

2012-07-27 Diskussionsfäden Markus


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.

Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID
eigentlich bezieht.

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] 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:

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

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

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] 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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-26 Diskussionsfäden Manuel Reimer


Rainer Kluge wrote:

Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme*
aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage war,
was fehlt dir noch, wenn du diese *Lösungen* anwendest.


Vielleicht die Software, die das ganze vollautomatisch macht?

Bei einer UUID brauche ich nur den OSM-Editor meiner Wahl um die UUID einzubauen 
und so die Verknüpfung herzustellen.


Wenn ich aber BBOX und wasweißich für jeden Bildstock in meiner DB speichern 
soll, dann brauche ich schon Stunden um diese Werte für jeden Bildstock manuell 
zu ermitteln und in die DB zu übertragen. Die verschiedenen Fälle (Node 
verschoben, verändert, gelöscht, ) wollen dann irgendwie ja auch erkannt werden.


Alles, was ich will, ist die Bildstöcke zu visualisieren, aber sicherstellen, 
dass nur unsere Bilder bei den Bildstöcken angezeigt werden.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Lieber Rainer,

Am 25. Juli 2012 19:15 schrieb Rainer Kluge rklug...@web.de:
 Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme*
 aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage
 war, was fehlt dir noch, wenn du diese *Lösungen* anwendest.

Bitte lies doch meine Beiträge hier auch nochmal. Ich denke Manuel's
Hinweis ist gerechtfertigt und bisher war die Diskussion hier durchaus
lösungsorientiert.

Peter Wendorff schrieb u.a.
 - Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu):
  Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig
  relativ leicht verifizieren, ob der neu erstellte node vielleicht
  der adäquate Ersatz ist.
 - Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag
  verloren: Du erkennst das, hast aber immer noch die ID und den Ausschnitt,
  die passen - aber prüfen musst du sowieso.

Bei diesen beiden Punkten versagt die OSM-ID und der Vorschlag sich
zur Sicherheit noch eine Koordinate oder gar einen Ausschnitt
(Suchradius) zu speichern und eine Lösung mit einer UUID/Projekt-ID
ist viel sinnvoller für die eingangs geschilderten Anwendungsfälle.

1. Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu)
= Mit UUID/Projekt-ID muss man da nichts nachgucken.

2. Die Tags eines bildstocks ändern sich, dabei geht das
bildstock-tag verloren = Das is genau einer der Schwachpunkte von
semantischen/zusammengesetzten IDs, weil die Chance dass einer von
mehreren Tags verloren geht grösser ist als bei einem und weil man es
ihnen nicht ansieht, dass sie zusammengehören (im Ggs. zu
UUID/Projekt-ID).

Zudem muss ich hier nochmals betonen, dass die
semantischen/zusammengesetzten IDs für genau solche Anwendungen, die
nur auf OSM-Objekte verlinken wollen, immer noch keine Lösung gibt,
denn viele Anwendungsfälle möchten auch auf OSM-Objekte zeigen, die
keine natürlich identifizierenden Tags haben, wie eben Bildstöcke,
Sitzbänke, Einzelbäume, RobyDogs, Startstromleitungsmasten,
Seilbahnkabel, etc. . Wieso soll OSM nicht offen sein für solche
Anwendungen?

Eine UUID, die generell über alle OSM-Objekte verteilt wird,
zusätzlicher Ballast ist, kann ich nachvollziehen.

Eine Projekt-ID will da ein Kompromiss sein und hat den Nachteil, dass
es ev. (in ferner Zukunft?) pro OSM-Objekt mehrere solche geben
könnte. Jedenfalls kann man das nicht abwertend als Privat-Keys
bezeichnen, wenn es freie Services gibt, die stabile OSM IDs anbieten
- wie das mit Frederiks Vorschlag (und meiner LinkedOSMDB) angedacht
ist.

Ganz wichtig scheint mir, dass wir von den ähnlichen Anwendungsfälle
reden. Die Lösung mit semantischen/zusammengesetzten IDs scheint sich
um die Fälle zu kümmern, bei denen eine externe Datenbank (hier
Wikipedia) ein OSM-Objekt in etwa einfängt, um es auf einem
Kartenausschnitt zu zeigen.

In Manuel's Fall der Bildstöcke, in OpenMetaMap und meinen Fällen geht
es darum, dass eine Fachdatenbank sein Objekte mit OSM-Objekten
(möglichst direkt!) verknüpfen will.

Konsens ist - glaube ich - Frederiks Vorschlag einer LinkedOSMDB,
die zwischen der Fachdatenbank und OSM sitzt. Nach einigem Nachdenken
könnte es nun auch sein, dass ich innerhalb der LinkedOSMDB von der
Privat wieder auf OSM-IDs schwenke. Der vorläufige Stand meiner Lösung
möchte ich im Thread LinkedOSMDB nebenan zusammenfassen.

LG, Stefan

Am 25. Juli 2012 19:15 schrieb Rainer Kluge rklug...@web.de:
 On 25.07.2012 12:32, Manuel Reimer wrote:

 Peter Wendorff wrote:

 Wo ist jetzt deine Lücke in dem Konzept?
 Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner 
 UUID auch nicht.

 Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern
 nicht verändert/angefasst wird.

 Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme*
 aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage
 war, was fehlt dir noch, wenn du diese *Lösungen* anwendest.

 Gruß
 Rainer



 ___
 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!

2012-07-26 Diskussionsfäden Manuel Reimer


Stefan Keller wrote:

Eine UUID, die generell über alle OSM-Objekte verteilt wird,
zusätzlicher Ballast ist, kann ich nachvollziehen.


Stimmt. Macht auch keinen Sinn. Der erste, der ein Objekt wirklich für $GRUND 
eindeutig identifizieren und mit eigenen Daten verknüpfen will, generiert eine 
UUID und klebt die an das Objekt.


Ich finde eine für den Anweundungszweck erzeugte UUID auf jedem Fall besser als 
eine spezielle eigene Projekt-ID. Eine einmal erzeugte UUID kann prinzipiell von 
mehreren Projekten genutzt werden, während eine spezielle Projekt-ID immer nur 
für ein Projekt brauchbar ist.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-26 Diskussionsfäden Rainer Kluge


On 26.07.2012 15:17, Stefan Keller wrote:

Peter Wendorff schrieb u.a.

- Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu):
  Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig
  relativ leicht verifizieren, ob der neu erstellte node vielleicht
  der adäquate Ersatz ist.
- Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag
  verloren: Du erkennst das, hast aber immer noch die ID und den Ausschnitt,
  die passen - aber prüfen musst du sowieso.


Bei diesen beiden Punkten versagt die OSM-ID


Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem Schlauch.

Zum ersten Punkt:

- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese ID 
gespeichert

- Jemand löscht diesen Bildstock
- Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und 
stellt fest, dass dieses nicht mehr existiert


Wo ist hier das Problem?

Zum zweiten Punkt:

- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese ID 
gespeichert

- Jemand löscht das Bildstock-Tag dieses Objekts
- Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu und stellt 
fest, dass das Bildstock-Tag weg ist


Wo ist hier das Problem?

Gruß
Rainer


___
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 26. Juli 2012 16:57 schrieb Rainer Kluge rklug...@web.de:
 Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem
 Schlauch.

An die Gefahr des Aneinandervorbeiredens habe ich auch schon gedacht
und möchte nochmals betonen, dass es mir nicht um den Fall geht wie
bei Wikipedia/WIWOSM, sondern um eine externe Datenbank, die eigene
Dinge verwaltet (z.B. Bilder und Historische Dokumente zu Bildstöcke)
und diese mit Tags und Geometrie ergänzt, die von OSM kommen. Diese
externe Datenbank hält sich über OSM à jour und gibt ihr auch etwas
zurück (komme später darauf zurück). Diese externe Datenbank (oder ein
LinkedOSMDB-Dienst) muss nun in Echtzeit auf ein einzelnes OSM-Objekt
zugreifen können und sie möchte klar sagen können: Ist das OSM-Objekt
wirklich neu, geändert oder gelöscht?

 Zum ersten Punkt:

 - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese 
 ID gespeichert
 - Jemand löscht diesen Bildstock
 - Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und 
 stellt fest, dass dieses nicht mehr existiert

 Wo ist hier das Problem?

Angenommen es handelt sich eigentlich um dasselbe Objekt, und das
Objekt wird nicht mehr am derselben Ort erstellt, dann ist die Chance
gross, dass man es verliert. Ich habe oben einige solche Situationen
zusammengetragen. Sagen wir, es wurde nur um 10m verschoben, aber
innerhalb von 10m gibt es noch weitere neue Objekte: Welches ist es
nun?

Mit einer Projekt-ID/UUID muss man nichts tun.

 Zum zweiten Punkt:

 - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese 
 ID gespeichert
 - Jemand löscht das Bildstock-Tag dieses Objekts
 - Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu
 und stellt fest, dass das Bildstock-Tag weg ist

 Wo ist hier das Problem?

Das ist ein kritischer, sogenannt bösartiger Fall: Das Hauptproblem
einer Lösung mit OSM-ID (oder ggf. OSM-ID+Koordinate) ist, dass OSM-ID
nicht stabil ist (:-).

Dieser Fall ist gerade auch ein schwacher Punkt der
semantischen/zusammengesetzten ID, denn dort ist gar nicht
offensichtlich, dass man einen Identifizierungs-Ansatz zerstört.

Hier schneidet die Projekt-ID immer noch besser ab: Sie ist gut
erkenntlich und kann an jedes Objekt, das referenziert werden soll,
gehängt werden.

LG, Stefan

Am 26. Juli 2012 16:57 schrieb Rainer Kluge rklug...@web.de:
 On 26.07.2012 15:17, Stefan Keller wrote:

 Peter Wendorff schrieb u.a.

 - Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu):
   Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig
   relativ leicht verifizieren, ob der neu erstellte node vielleicht
   der adäquate Ersatz ist.
 - Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag
   verloren: Du erkennst das, hast aber immer noch die ID und den
 Ausschnitt,
   die passen - aber prüfen musst du sowieso.


 Bei diesen beiden Punkten versagt die OSM-ID


 Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem
 Schlauch.

 Zum ersten Punkt:

 - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird
 diese ID gespeichert
 - Jemand löscht diesen Bildstock
 - Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen
 und stellt fest, dass dieses nicht mehr existiert

 Wo ist hier das Problem?

 Zum zweiten Punkt:

 - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird
 diese ID gespeichert
 - Jemand löscht das Bildstock-Tag dieses Objekts
 - Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu und
 stellt fest, dass das Bildstock-Tag weg ist

 Wo ist hier das Problem?


 Gruß
 Rainer


 ___
 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 Rainer

Am 26. Juli 2012 15:36 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 prinzipiell von mehreren Projekten genutzt werden, während eine spezielle
 Projekt-ID immer nur für ein Projekt brauchbar ist.

Stimmt nicht immer: Ich habe eine Projekt-ID im Kopf, die von mehreren
Projekten genutzt werden kann, da sie über einen freien Dienst wie
LinkedOSMDB (den es noch nicht gibt) genutzt werden könnte. Konkret
würde ich die Projekt-ID so gestalten wie die TOID von UK oder die
Swiss-OID (www.interlis.ch/oid/oid_d.php ).

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).

LG, Stefan

Am 26. Juli 2012 15:36 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Stefan Keller wrote:

 Eine UUID, die generell über alle OSM-Objekte verteilt wird,
 zusätzlicher Ballast ist, kann ich nachvollziehen.


 Stimmt. Macht auch keinen Sinn. Der erste, der ein Objekt wirklich für
 $GRUND eindeutig identifizieren und mit eigenen Daten verknüpfen will,
 generiert eine UUID und klebt die an das Objekt.

 Ich finde eine für den Anweundungszweck erzeugte UUID auf jedem Fall besser
 als eine spezielle eigene Projekt-ID. Eine einmal erzeugte UUID kann
 prinzipiell von mehreren Projekten genutzt werden, während eine spezielle
 Projekt-ID immer nur für ein Projekt brauchbar ist.

 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!

2012-07-26 Diskussionsfäden Peter Wendorff


Am 26.07.2012 18:18, schrieb Stefan Keller:

Hallo Rainer,

Am 26. Juli 2012 16:57 schrieb Rainer Kluge rklug...@web.de:

Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem
Schlauch.

An die Gefahr des Aneinandervorbeiredens habe ich auch schon gedacht
und möchte nochmals betonen, dass es mir nicht um den Fall geht wie
bei Wikipedia/WIWOSM, sondern um eine externe Datenbank, die eigene
Dinge verwaltet (z.B. Bilder und Historische Dokumente zu Bildstöcke)
und diese mit Tags und Geometrie ergänzt, die von OSM kommen. Diese
externe Datenbank hält sich über OSM à jour und gibt ihr auch etwas
zurück (komme später darauf zurück). Diese externe Datenbank (oder ein
LinkedOSMDB-Dienst) muss nun in Echtzeit auf ein einzelnes OSM-Objekt
zugreifen können und sie möchte klar sagen können: Ist das OSM-Objekt
wirklich neu, geändert oder gelöscht?


Zum ersten Punkt:

- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese 
ID gespeichert
- Jemand löscht diesen Bildstock
- Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und 
stellt fest, dass dieses nicht mehr existiert

Wo ist hier das Problem?

Angenommen es handelt sich eigentlich um dasselbe Objekt, und das
Objekt wird nicht mehr am derselben Ort erstellt, dann ist die Chance
gross, dass man es verliert. Ich habe oben einige solche Situationen
zusammengetragen. Sagen wir, es wurde nur um 10m verschoben, aber
innerhalb von 10m gibt es noch weitere neue Objekte: Welches ist es
nun?

Mit einer Projekt-ID/UUID muss man nichts tun.

So wie du kann ich auch mein Mantra wiederholen:
Vorausgesetzt, die PID/UUID wird mit kopiert
Vorausgesetzt, man kann sich darauf verlassen, dass, WENN sie mitkopiert 
wird, wirklich das gleiche Objekt damit gemeint ist.
Vorausgesetzt, die PID/UUID ist für den Mapper korrekt an genau dem 
Objekt angebracht, das sie auch bezeichnen soll - also nicht 
gleichzeitig an Shop und Gebäude (obwohl das durchaus auch mal ein 
Objekt sein/werden kann) etc.


IMHO ziemlich viele vorausgesetzts, um das als sichereren Weg ohne 
genauso aufwändige Prüfung anzupreisen.

Zum zweiten Punkt:

- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese 
ID gespeichert
- Jemand löscht das Bildstock-Tag dieses Objekts
- Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu
und stellt fest, dass das Bildstock-Tag weg ist

Wo ist hier das Problem?

Das ist ein kritischer, sogenannt bösartiger Fall: Das Hauptproblem
einer Lösung mit OSM-ID (oder ggf. OSM-ID+Koordinate) ist, dass OSM-ID
nicht stabil ist (:-).

häh?
Hast du damit jetzt die Frage beantwortet, wo das Problem liegt und wo 
dein UUID-Ansatz besser wäre, oder hast du das als Ausnahme definiert 
und nimmst deshalb an, dein Ansatz müsse das nicht unterstützen?

Dieser Fall ist gerade auch ein schwacher Punkt der
semantischen/zusammengesetzten ID, denn dort ist gar nicht
offensichtlich, dass man einen Identifizierungs-Ansatz zerstört.
Die Semantische ID ist aber gerade momentan nicht die Konkurrenz zur 
nicht-semantischen UUID, sondern eine weitere Variante. Gefragt ist doch 
erstmal, warum zur OSM-ID ein zusätzliches System überhaupt Sinn macht, 
da liegt also der eigentliche Vergleichspunkt.

Hier schneidet die Projekt-ID immer noch besser ab: Sie ist gut
erkenntlich und kann an jedes Objekt, das referenziert werden soll,
gehängt werden.

Wie sieht sie denn aus, so dass sie gut erkenntlich ist?
Bedenke: Die meisten Mapper benutzen im alltäglichen Gebrauch nicht 
ständig die Dokumentation/das Wiki, sondern mappen drauflos, indem sie 
abgucken, was anderswo steht oder die Editor-Presets nutzen.

Beides kann ich für eine solche ID aber nicht als verständlich erkennen.

Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-26 Diskussionsfäden Rainer Kluge


On 26.07.2012 18:18, Stefan Keller wrote:

Zum ersten Punkt:

- Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird
diese ID gespeichert - Jemand löscht diesen Bildstock - Die
Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und
stellt fest, dass dieses nicht mehr existiert

Wo ist hier das Problem?


Angenommen es handelt sich eigentlich um dasselbe Objekt, und das Objekt
wird nicht mehr am derselben Ort erstellt, dann ist die Chance gross, dass
man es verliert. Ich habe oben einige solche Situationen zusammengetragen.
Sagen wir, es wurde nur um 10m verschoben, aber innerhalb von 10m gibt es
noch weitere neue Objekte: Welches ist es nun?


Erst mal: wenn das Objekt im Editor mit der Maus um 10m verschoben wird, dann
ändert sich die OSM-ID nicht. Nur wenn man ein Objekt als Kopie eines anderen
Objekts anlegt, wird eine neue OSM-ID vergeben. Bei Josm ist übrigens Löschen +
Einfügen gar nicht möglich, sondern man muss kopieren, einfügen und das Original
löschen. Ich frage mich wer so einen Aufwand wegen einer Verschiebung um 10m
treibt und warum. Aber sei's drum, jeder nach seiner Façon.


Mit einer Projekt-ID/UUID muss man nichts tun.


Doch. Ein Beispiel: Die Bildstöcke BS1 und BS2 liegen wenige Meter auseinander, 
sind aber etwa 10m von ihrer tatsächliche Position P1 bzw. P2 entfernt gemappt. 
Auch die relative Position der beiden Objekte zueinander ist nicht korrekt, BS1 
ist näher an P2 gemappt als an P1. Ein Mapper stellt die ungenaue Positionierung 
fest und zieht Bildstock 1 nach P2 Bildstock 2 nach P1. Woher soll der Mapper 
denn wissen, welcher der ungenau positionierten Bildstöcke auf welcher Position 
steht. Und schon wird ein falsches Foto angezeigt.


Ich habe übrigens nichts gegen UUIDS, man sollte sich nur davor hüten zu 
glauben, man würde es damit der hier diskutierten Anwendung einfacher machen. 
Man wird nicht umhin kommen, bei jeder Änderung der Position nachzuschauen und 
ggf. die DB manuell nachzuziehen.


Gruß
Rainer


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Peter

Am 26. Juli 2012 18:57 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 26.07.2012 18:18, schrieb Stefan Keller:
 Hallo Rainer,
 Am 26. Juli 2012 16:57 schrieb Rainer Kluge rklug...@web.de:
...
 So wie du kann ich auch mein Mantra wiederholen:

Was jetzt folgt, sind jetzt Voraussetzungen, die du aufgestellt hast,
nicht ich.

 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. Für Tools und Aktionen zur
Verbesserung der OSM-Infrastruktur, wie sie Frederik beschrieben hat
(ich zitiere unten), das das wohl selbstverständlich.

 Vorausgesetzt, man kann sich darauf verlassen, dass, WENN sie mitkopiert
 wird, wirklich das gleiche Objekt damit gemeint ist.

Stimmt. Das ist aber eine philosophische Frage, der wir uns alle bei
jeder Aenderung stellen müssen und die daher nicht spezifisch gegen
PID/UUID oder sonst einen Identifikationsansatz spricht.

 Vorausgesetzt, die PID/UUID ist für den Mapper korrekt an genau dem Objekt
 angebracht, das sie auch bezeichnen soll - also nicht gleichzeitig an Shop
 und Gebäude (obwohl das durchaus auch mal ein Objekt sein/werden kann) etc.

Das ist kein Argument gegen die PID/UUID, die ich meine: Jedes Objekt,
das in OSM für die externe Datenbank von Interesse ist, erhält eine
PID/UUID, sei es ein Shop oder ein Gebäude oder beides aufs Mal. Der
Umgang damit ist externen Datenbank überlassen und die Mapper sollen
mit den beiden (oder dem einen) machen was sie für richtig halten.


 Zum zweiten Punkt:

 - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird
 diese ID gespeichert
 - Jemand löscht das Bildstock-Tag dieses Objekts
 - Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu
 und stellt fest, dass das Bildstock-Tag weg ist

 Wo ist hier das Problem?

 Das ist ein kritischer, sogenannt bösartiger Fall: Das Hauptproblem
 einer Lösung mit OSM-ID (oder ggf. OSM-ID+Koordinate) ist, dass OSM-ID
 nicht stabil ist (:-).

 häh?
 Hast du damit jetzt die Frage beantwortet, wo das Problem liegt und wo dein
 UUID-Ansatz besser wäre, oder hast du das als Ausnahme definiert und nimmst
 deshalb an, dein Ansatz müsse das nicht unterstützen?

Ja; da war ich unklar: Dies ist tatsächlich ein Ausnahmefall der aber
alle Ansätze und alle Projekte, die sich auf irgendwelche Tags
verlassen, gleichermassen betrifft. Das muss letztlich
projektspezifisch gelöst werden. Beim PID/UUID-Ansatz könne das durch
einen Vandalismus-Detektor und eine Restaurierungs-Liste zuhanden von
Mapper gelöst werden.

 Dieser Fall ist gerade auch ein schwacher Punkt der
 semantischen/zusammengesetzten ID, denn dort ist gar nicht
 offensichtlich, dass man einen Identifizierungs-Ansatz zerstört.

 Die Semantische ID ist aber gerade momentan nicht die Konkurrenz zur
 nicht-semantischen UUID, sondern eine weitere Variante. Gefragt ist doch
 erstmal, warum zur OSM-ID ein zusätzliches System überhaupt Sinn macht, da
 liegt also der eigentliche Vergleichspunkt.

Was gegen die OID (und damit für mich für PID/UUID) spricht? Folgendes -
ich zitiere Frederik Ramm frede...@remote.org oben vom 22. Juli 2012 22:58:
===
 ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind

 Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen sollte,
 seine Daten auf mehrere Server auf verschiedenen Kontinenten aufzuteilen und
 daher alle Objekte auf neue Server mit neuen Nummernraeumen verteilt, sollte
 das niemanden stoeren.

 Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden Objekte
 umnumeriert, um nicht mehr genutzte Luecken wiederzuverwenden, sollte
 das keine Probleme verursachen.

 Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und neu
 einfuegt, sollte niemand davon etwas merken.
===

 Hier schneidet die Projekt-ID immer noch besser ab: Sie ist gut
 erkenntlich und kann an jedes Objekt, das referenziert werden soll,
 gehängt werden.

 Wie sieht sie denn aus, so dass sie gut erkenntlich ist?
 Bedenke: Die meisten Mapper benutzen im alltäglichen Gebrauch nicht ständig
 die Dokumentation/das Wiki, sondern mappen drauflos, indem sie abgucken, was
 anderswo steht oder die Editor-Presets nutzen.
 Beides kann ich für eine solche ID aber nicht als verständlich erkennen.

Für die (noch fiktive) LinkedOSMDB, die eine stabile IDs anbieten
würde, wäre das linkdedosmdb_id= Dort sieht jeder die Zeichen
_id. Aber natürlich kann niemand verhindern, dass ganze Tags von
Mapper gelöscht werden - genauso wie niemand verhindern kann ganze
OSM-Objekte grundlos gelöscht werden.

Die meisten der (an sich guten) Punkte sind Probleme, die alle Ansätze haben.

Irgendwie stehen wir immer noch ohne Lösung da:
* Die einen sagen, nehmt OID und ignorieren die fundamentalen Probleme
(wie oben beschrieben).
* Die anderen schlagen semantische IDs vor, die inhärent nur für
benennbare, individuelle OSM-Objekte gelten.
* Und beide können sich nicht mit den Nachteilen

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-26 Diskussionsfäden Rainer Kluge


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?


- Ausschneiden und mehrmals Einfügen. Welches der eingefügten Objekte ist das 
verschobene Originalobjekt?


- 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?


Gruß
Rainer


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-25 Diskussionsfäden Peter Wendorff


Am 24.07.2012 10:32, schrieb Georg Feddern:

Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli
2012 13:34 an Georg.
Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine
Herausforderung zu sein, so einen Node zu verschieben und die ID
beizubehalten.


JOSM - utilsplugin2 - Punkt extrahieren
Wenn man sich denn überhaupt der Problemstellung bewusst ist, dass die 
ID unbedingt mitverschoben werden muss.

Das ist der Knackpunkt.
ProblemSTELLUNG trifft es ganz gut - denn bisher sehe ich dieses Problem 
immer noch nicht, bzw. nur konstruiert aus der Idee, die osm-id als 
permanente ID verwenden zu wollen.


Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-25 Diskussionsfäden Peter Wendorff


Am 24.07.2012 12:05, schrieb Manuel Reimer:

Stefan Keller wrote:

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
verliert (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID


Eben. Die Tendenz geht dahin, dass ein Mapper ggf. alle Tags 
übernimmt. Erst recht auch die, die er nicht kennt.


Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? 
Dann
frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen 
BBox.


Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
wurde, dann ist es weg, ausserhalb der BBOX.


Nicht nur das. Ich müsste für alle Bildstöcke (ca. 30 Stück) eine BBox 
ermitteln und speichern. Zudem gibt es Stellen, an denen Bildstöcke 
relativ nah beieinander stehen.

Du kannst ja die ID als zusätzliches Kriterium problemlos mitziehen.
Wenn sich nur eine ID ändert, wird es dann wohl ein entsprechendes 
Ersetzen sein; nur, wenn beide IDs auf einmal weg sind, dafür aber 
andere Bildstöcke in der BBox stehen, wird es problematisch.


Die BBoxen zu ermitteln ist auch nicht weiter schwierig: Abhängig von 
der Dichte würde ich da einfach eine Standardgröße, z.B. 50 Meter 
rundrum oder so benutzen - für Städte und Dörfer aber z.B. einige 
Kilometer, für Bushaltestellen 100m und so weiter.


Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-25 Diskussionsfäden Manuel Reimer


Peter Wendorff wrote:

Du kannst ja die ID als zusätzliches Kriterium problemlos mitziehen.
Wenn sich nur eine ID ändert, wird es dann wohl ein entsprechendes Ersetzen
sein; nur, wenn beide IDs auf einmal weg sind, dafür aber andere Bildstöcke in
der BBox stehen, wird es problematisch.


Teilweise stehen mehrere Bildstöcke relativ nahe. Ich möchte aber jedem sein 
korrektes Bild zuordnen.


Ich finde nach wie vor die Idee mit den UUIDs am ehesten attraktiv. Im Idealfall 
übernimmt der Mapper, der etwas an dem Objekt macht, einfach alle Tags. Wenn er 
das UUID-Tag nicht kennt, dann wird er im Wiki fündig. Wenn er es dennoch killt, 
dann kann ich, als Nutzer dieses Tags, dieses dann ggf. immer noch wieder 
reparieren.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-25 Diskussionsfäden Peter Wendorff


Am 25.07.2012 10:41, schrieb Manuel Reimer:

Peter Wendorff wrote:

Du kannst ja die ID als zusätzliches Kriterium problemlos mitziehen.
Wenn sich nur eine ID ändert, wird es dann wohl ein entsprechendes 
Ersetzen
sein; nur, wenn beide IDs auf einmal weg sind, dafür aber andere 
Bildstöcke in

der BBox stehen, wird es problematisch.


Teilweise stehen mehrere Bildstöcke relativ nahe. Ich möchte aber 
jedem sein korrektes Bild zuordnen.
Liest du eigentlich, was andere Leute schreiben, oder bist du von deiner 
Idee einfach zu überzeugt?


Ein Ausschnitt von 15x15 Metern hat 5 Bildstöcke, eingetragen als osm 
nodes mit den IDs 123, 124, 125, 126, 127.

Du speicherst als Link für den ersten Bildstock sowas wie
n123[bildstock-tag]@ausschnitt' (wobei ausschnitt' ein Ausschnitt von 
10x10 Metern mit der dir bekannten letzten korrekten Koordinate des 
Bildstocks im Zentrum ist).
Für den zweiten speicherst du n124[bildstock-tag]@ausschnitt'' - und so 
weiter.


In diesem Moment kannst du eindeutig zuordnen.
Was kann jetzt passieren?
- Ein Bildstock wird hinzugefügt: Kein Problem, du benutzt die IDs zur 
Zuordnung deiner Bildstöcke - stellst aber evtl. zusätzlich fest, dass 
deiner Datenbank eventuell noch ein neuer Bildstock fehlt.
- Ein Bildstock wird gelöscht: Kein Problem - die anderen werden 
aufgrund der ID weiterhin korrekt zugeordnet, der gelöschte wird korrekt 
als identifiziert und nachgucken musst du sowieso, ob das jetzt ein 
Fehler in OSM ist oder der Bildstock tatsächlich nicht mehr existiert.
- Ein Bildstock wird verschoben: Du erkennst das, weil die ID auf einmal 
an anderer Stelle steht.
- Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu): Du 
erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig 
relativ leicht verifizieren, ob der neu erstellte node vielleicht der 
adäquate Ersatz ist.
- Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag 
verloren: Du erkennst das, hast aber immer noch die ID und den 
Ausschnitt, die passen - aber prüfen musst du sowieso.


Gelöst ist also:
- Das Verlinken genau eines Objekts, selbst wenn dazu keine ID existiert.
- Das Tracken von Änderungen und das Nachvollziehen derselben.
- Es werden keine aus Sicht von OSM unsinnigen FremdIDs gebraucht, die 
kein Mensch außer dir kontrollieren kann.


Wo ist jetzt deine Lücke in dem Konzept?
Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner 
UUID auch nicht.


Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-25 Diskussionsfäden Manuel Reimer


Peter Wendorff wrote:

Wo ist jetzt deine Lücke in dem Konzept?
Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID
auch nicht.


Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern nicht 
verändert/angefasst wird. Wenn der Fall doch eintritt, dann packe ich die UUID 
wieder rein und fertig.


Es geht mir ja darum, ein bestimmtes Objekt zu referenzieren. Auch dann, wenn 
das Objekt heute noch ein Node, morgen aber eine Fläche ist. Bei Bildstöcken 
wird kaum jemand eine Fläche draus machen, aber bei Gebäuden ist das nicht 
unüblich einen erst nur hilfsweise eingesetzten Node später durch den 
Gebäudeumriss zu ersetzen.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-25 Diskussionsfäden Rainer Kluge


On 25.07.2012 12:32, Manuel Reimer wrote:

Peter Wendorff wrote:

Wo ist jetzt deine Lücke in dem Konzept?
Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID
auch nicht.


Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern nicht
verändert/angefasst wird.


Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme* 
aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage war, 
was fehlt dir noch, wenn du diese *Lösungen* anwendest.


Gruß
Rainer


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-24 Diskussionsfäden Stefan Keller

Hallo Werner

Interessant, was du da in deinem Mail vom 24. Juli 2012 00:38 schreibst.

Letztlich sagst du damit, dass jedes OSM Objekt identifiziert oder
zumindest verfolgt werden kann, wenn man vom ihm 1. die OSM ID(?),
2. die Version und 3. das Change-Datum (aus der Historie) verwaltet,
oder?

D.h. dass eine externe Datenbank jedem OSM Objekt eine eigene
(permanente/stabile) ID zuordnen könnte, was meine Frage eingangs
löst. Ich bin ein wenig verunsichert, weil du schreibst ... habe ich
mal einen Prototypen geschrieben, der ... aus der OSM-DB ein Objekt zu
jedem Zeitpunkt ermitteln kann..

Was ich - bzw. Linked Open Data und Projekte wie query-to-map oder
OpenMetadata ja möchten, ist eine eindeutige, permanente ID - solange
es das Objekt gibt.

Weiter hast du geschrieben:
 Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr aufwändig.

Ja; das habe ich auch gemerkt, als ich ein Extrakt (z.B. ein Land) mit
aktuell halten wollte.
Ist es nun mit deine Prototyp möglich oder nicht?

 Anmerkungen:
 * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die
   Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden.

Du meinst es braucht eine zeitliche Toleranz, eine Zeitspanne (von
z.B. einigen Minuten)?

 * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction
   Bot verändert wurden.

Ok. Aber was kann der Bot anders machen als das was unbedarfte Mapper
und Editoren tun (löschen+neu einfügen sollte ja erkannt werden mit
deinem Ansatz)?

Grüsse, Stefan


Am 24. Juli 2012 00:38 schrieb Werner Hoch werner...@gmx.de:
 Hallo,

 Am Sonntag, den 22.07.2012, 21:22 +0200 schrieb Stefan Keller:
 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs
 ungewollt/unfreiwillig?

 Oben wird die Overpass Permanent ID erwähnt
 (http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ) und
 dort steht: ...you shouldn't use an object ID, because the OSM IDs
 may change at any time. Das würde ich gerne mal näher analysieren:

 Ein klarer Fall für ein Löschen und Neu-Einfügen (mit neuer ID)
 scheint mir zu sein, wenn das auch in der realen Welt der Fall ist:
 Wenn z.B. ein Gebäude abgerissen und neu erstellt wird, oder ein
 wichtiger Einzelbaum gefällt und neu gepflanzt wird.

 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 ist
 aber kein logisch zwingender Grund, sondern technischer Mangel.

 Dieses Problem lässt sich umgehen, wenn man nicht mit der Version des
 Weges arbeitet, sondern zusätzlich mit einem Datum.

 Ein way X lässt sich zu jedem Zeitpunkt und immer gleich aus OSM (und
 der OSM-Historie) extrahieren.
 Dieses Objekt(mit Datum) ist stabil. Diese Information ließen sich
 cachen und bei Bedarf gegen die Objekte mit aktuellerem Datum
 abgleichen.

 Wie kommt man an das Objekt mit ObjektID+Datum?
 -- alle referenzierten Objekte mit dem entsprechenden Datum ermitteln.
 Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr
 aufwändig.

 Vor einigen Jahren habe ich mal einen Prototypen geschrieben, der über
 die API aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann:
 Beschreibung:
 http://www.h-renrew.de/h/osm/tools/osmhistory.html
 Quelltext:
 https://github.com/werner2101/python-osm

 Anmerkungen:
 * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die
   Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden.
 * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction
   Bot verändert wurden.

 Grüße
 Werner



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-24 Diskussionsfäden Georg Feddern


Moin,

Am 23.07.2012 23:41, schrieb Stefan Keller:

Hallo Henning

Am 23. Juli 2012 18:45 schrieb aighes o...@aighes.de:

Am 23.07.2012 17:41, schrieb Stefan Keller:



Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?

Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli
2012 13:34 an Georg.
Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine
Herausforderung zu sein, so einen Node zu verschieben und die ID
beizubehalten.


JOSM - utilsplugin2 - Punkt extrahieren
Wenn man sich denn überhaupt der Problemstellung bewusst ist, dass die 
ID unbedingt mitverschoben werden muss.

Das ist der Knackpunkt.




Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht
mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte
dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen.

Es gibt etliche Gebiete, die ab Orthofotos abdigitalisiert wurden und
die um mehrere Meter (bis zu 30!) falsch sind, weil die Orthofotos
falsch waren.
Da steht man mit BBox sprichwörtlich im Schilf.



Also als konkretes Beispiel halte ich eine Suche nach einer 
Bushaltestelle innerhalb von 50 m jetzt nicht unbedingt für 
problematisch, ganz abgesehen davon, dass diese einen konkreten Namen 
haben (sollten).
Bei ganz genau einer bestimmten von 4 Sitzbänken nebeneinander fehlt mir 
persönlich so ein bisschen die Notwendigkeit der Objektunterscheidung - 
aber nun gut, dass mag jemand anders sehen.


Bist Du wirklich sicher, dass sich der Aufwand, ggf. hundert(e) von 
Projekt-IDs einzupflegen und auch zu warten, lohnt, um ggf. ein(zelne) 
Objekt(e) auch außerhalb ihrer Positions-Box (möglicherweise in Timbuktu 
statt in Deutschland) wiederzufinden?


Um bei Deinem Beispiel zu bleiben:
Ein Projekt verweist (meinetwegen per Projekt-ID) auf diese 
Bushaltestelle, die als einzelnes Objekt auf dem Straßen-way in OSM 
vorhanden ist.
Jetzt wird diese Bushaltestelle in OSM als zwei Objekte abseits der 
Straße verändert.
Welches Objekt soll jetzt die Projekt-ID bekommen, beide Haltestellen 
oder nur eine ganz bestimmte? Oder die stop-area-Relation? Oder gehört 
diese ID womöglich zum Node der Straße?
Das bist dann nicht Du, der das dann entscheiden muss! Derjenige, der 
das externe Projekt kennt und entsprechende Schlüsse ziehen kann.
Sondern das ist Mapper Joe, der von Deinem Projekt keine Ahnung hat und 
nur so eine komische Projekt-ID als Tag vorfindet.


Du must in jedem Fall hinterherarbeiten, ganz egal ob
a) die ID dann mehrfach vorhanden ist
b) die ID jetzt gar nicht mehr vorhanden ist, aber das Objekt sich noch 
in der Box befindet
c) oder das Objekt mit oder ohne ID nicht mehr in der Positions-Box 
gefunden wird


Denn ich gehe stark davon aus, dass es Dir nicht egal ist, ob sich 
_Dein_ Objekt mit der ID plötzlich in Timbuktu befindet.
D. h. Du prüfst doch sowieso gegen, ob sich das Objekt noch in einer 
gewissen Box befindet.

Warum dann nicht gleich so?

Gruß
Georg



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-24 Diskussionsfäden aighes


Am 24.07.2012 09:56, schrieb Stefan Keller:

Letztlich sagst du damit, dass jedes OSM Objekt identifiziert oder
zumindest verfolgt werden kann, wenn man vom ihm 1. die OSM ID(?),
2. die Version und 3. das Change-Datum (aus der Historie) verwaltet,
oder?
Nein...du kannst mit ID und Datum immer das Objekt bekommen, dass du in 
deine DB eingetragen hast.


Bsp.: Du verknüpfst gestern eine Bushaltestelle mit deiner DB. Heute 
lösche ich die Bushaltestelle und trage eine neue ein. Dann kannst du 
aus der History DB das Objekt so bekommen, wie es gestern war. Was ich 
dann mit dem Objekt gemacht habe, kannst du auch in Erfahrung bringen, 
aber das muss dann nicht mehr das Objekt sein, auf das sich deine DB 
bezieht.


Da diese weiterverfolgung nicht geht, kannst du dir aber auch gleich die 
Daten aus OSM kopieren und in deine DB einfügen. Da ist der Aufwand 
geringer. Denn so eine History-DB ist mit Sicherheit nicht ohne ;)


Henning
___
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:

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
verliert (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID


Eben. Die Tendenz geht dahin, dass ein Mapper ggf. alle Tags übernimmt. Erst 
recht auch die, die er nicht kennt.



Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.


Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
wurde, dann ist es weg, ausserhalb der BBOX.


Nicht nur das. Ich müsste für alle Bildstöcke (ca. 30 Stück) eine BBox ermitteln 
und speichern. Zudem gibt es Stellen, an denen Bildstöcke relativ nah 
beieinander stehen.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!


aighes wrote:

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
verliert (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID

Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?


$GEBAEUDE ist aktuell noch als Node eingezeichnet und jemand zeichnet den 
Gebäudeumriss ein und überträgt alle Tags vom Node auf den neu geschaffenen Way.


Beispiele gibt es viele. Problem ist und bleibt, dass man, wenn man direkt Daten 
von der OSM-Datenbank in einem Projekt verwenden will, irgendwie eine Referenz 
auf bestimmte Objekte benötigt.


Prinzipiell ist es nämlich in zweierlei Hinsicht praktisch, Geodaten direkt in 
der OSM-DB zu pflegen. Zum einen gibt es hier gute Tools um die via GPS 
ermittelten Daten in der Karte einzutragen und auch zu benennen und/oder mit 
weiteren Infos zu versehen. Zum anderen profitiert auch die OSM gleich mit, wenn 
solche Daten direkt in deren DB gepflegt und verwaltet werden. Auch andere 
Projekte könnten so die Daten (z.B. alle Bildstöcke) anzeigen.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!


Roland Olbricht wrote:

Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto
und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich
(z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als
url=... oder website=... ein.

Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine
Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck
des Tags ohne Recherche erkennbar ist.


... aber es kann keiner einem anderen Mapper verbieten eine andere Webseite oder 
einen anderen Link auf ein Bild zu hinterlegen.


Ich hatte ursprünglich tatsächlich vor, die Verknüpfung zwischen Object-ID und 
Bild auch in der OSM zu pflegen, habe mich aber bewusst dagegen entschieden, 
weil ich auf unserer Vereinskarte auch nur unsere Bilder sehen will. Ich will 
vermeiden, dass jemand ein vermeintlich schöneres Bild an einen Bildstock hängt 
und dieses dann auf dem Weg auf unsere Karte kommt.


Aus dem Grund kommen auch nur Position und Name (ggf. noch start_date, wenn 
bekannt) aus der OSM-DB. Die Verbindung zwischen Bild und OSM-ID mache ich dann 
auf unserem Server.


Gruß

Manuel


___
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:

* Bisher haben wir von externen Datenbanken gesprochen - also
Mehrzahl: Gehört so eine externe Datenbank nicht eigentlich zur OSM
Infrastruktur?


Nicht, wenn der Betreiber der externen DB ganz bewusst verhindern will, dass 
jemand seine Daten ändert.


In meinem Fall eben Verknüpfung zwischen OSM-ID (da ich aktuell noch diese 
nutze, da kein anderes Merkmal brauchbar) und einem Foto. Die Summe der Daten 
visualisiere ich dann auf einer Karte für unseren Heimat- und Geschichtsverein.


Ich will ganz bewusst verhindern, dass jemand ein anderes Bild für das für mich 
interessante Objekt hinterlegt. Auf unserer Karte will ich auch nur unsere 
Bilder sehen.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Peter Wendorff


Am 22.07.2012 22:57, schrieb Stefan Keller:

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.

Dann verstehe ich nicht, warum sie eine Referenz braucht.
Wenn die externe Datenbank entscheidet, wie OSM das zu modellieren hat 
bzw. zu welchem Modell/welchen Daten sie verlinkt, dann kann sie auch 
direkt eine Kopie des Objekts halten.


Bei Änderungen in OSM ist sie aufgeschmissen, aber das ist sie ja bei 
deiner Lösung sowieso im Zweifelsfall.


Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Peter Wendorff


Am 22.07.2012 23:34, schrieb Stefan Keller:

Hallo Henning (aighes)

Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de:

Am 22.07.2012 22:45, schrieb Stefan Keller:

Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:

Oder wenn jemand das Objekt nun
anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das
Gebäude die ref der Straße.

Verstehe ich nicht.

Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
Datenbank für alle sein kann und einfach vollgestopft werden soll mit
Tags, die von externen Projekten kommen. Der einzige Tag den ich
vorschlage ist diese eine Projekt_ID.

Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil
gegenüber der normalen Objekt-ID.

Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht genügt).


Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem
Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die
Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm
nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört,
oder zu dem Objekt Restaurant.

Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet.
Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht,
dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität
überein (und die externe Datenank registriert das) oder mit dem Mapper
Mit dem Mapper stimmt alles, denn OSM-IDs sind Schall und Rauch und nur 
zur akuten Verwendung zwischen Objekten stabil - und an der Stelle hat 
der Mapper definitiv nichts falsch gemacht.
Der betreffende Mapper ist eben vielleicht kein Datenbank-Fetischist, 
weiß unter Umständen nichtmal, was eine ID ist, und braucht das auch 
nicht wissen.

:- Will anständigerweise sagen, er war sich seiner unbedarften
Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt
das Restaurant wieder (mit seiner Projekt-ID) und löscht die
Projekt-ID beim Parkbank.
Das Projekt - egal ob du damit jetzt den OSM-Server oder einen 
beliebigen Editor meinst, weiß aber nunmal gar nicht, ob der mapper 
damit wirklich das Objekt verändert hat.
Vielleicht ist die Bushaltestelle gar nicht durch ein anderes Objekt 
ersetzt worden, sondern nur durch ein neues Taggingschema, das die 
Software noch nicht kennt - deshalb aber ja nicht verboten ist.


Deine Lösung erfordert also entweder festgelegte Tagging-Regeln, damit 
solche Ersetzungsregeln auch nur ansatzweise funktionieren (denn auch 
ein nachträgliches hinzufügen/hinterherziehen neuer Taggingvarianten 
würde sonst ja das brechen von IDs nicht verhindern), oder aber es 
funktioniert schlichtweg nicht.


Dass sich ein Objekt in zwei jeweils nur einzelne Aspekte dessen 
beschreibende teilt, ist damit übrigens auch noch nicht gelöst.

Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem
Namen xyz in der BBox... zu fragen.

Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke
leider kaum. Daher ist die Idee der kombinierten Tags unzureichend.

Ich mappe am Montag vier Bänke auf dem Marktplatz.
Eine davon (!) bekommt am Dienstag eine ID nach deinem Schema vom 
schlafbank-projekt ;).


Ich komme Freitags wieder vorbei und da stehen immer noch vier 
Parkbänke, aber nicht an der gleichen Stelle.
Es ist definitiv nicht zu erkennen, ob die Bänke jetzt verschoben worden 
sind, oder ob das andere Bänke sind.


Was soll ich als Mapper jetzt mit der ID machen?
Was soll ich mit den Bänken machen? verschieben oder löschen und neu 
zeichnen?

Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine
Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher
Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob
die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können
ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge
haben).

Der Mapper hat hier die freie Wahl! Er soll einfach den Tag
irgendwohin tun - nur in (wie üblich) nicht löschen. Das Projekt
kümmert sich (hoffentlich) drum.
Womit sich der Kreis schließt und das Projekt von den stabilen IDs 
überhaupt nichts gewonnen hat - denn jede Änderung an Objekten mit 
diesen IDs muss das Projekt manuell nachvollziehen und bei Bedarf 
korrigieren.


Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Manuel Reimer


Frederik Ramm wrote:

ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die
sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM
einschraenkt.


Mag ja sein, aber es gibt aktuell keine echte Alternative, ein Objekt in der OSM 
korrekt zu referenzieren. Es ist nunmal so, dass OSM-Intern die ID als 
Datenbank-Schlüssel verwendet wird und solange Mapper ein Objekt nicht komplett 
löschen und neu erzeugen (oder einen Node durch einen Way ersetzen, wie z.B. bei 
Gebäuden) ist die ID auch stabil.



UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der
Link-Stabilitaet unseren Mappern aufbuerden.


Und? Warum sollte nicht derjenige, der Daten aus der OSM nutzt, sich um die 
Dauerhaftigkeit dieser ID kümmern?


Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, 
auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine 
Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit 
kurzem Text und einem Foto auf.


Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache 
ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner 
DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen 
eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die 
Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim 
Umbauen von Node auf Way alle Tags mit um. Dann passt es direkt wieder.


Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten 
Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als Bildstock 
auszeichnet. Ein start_date (sofern bekannt) wäre nicht eindeutig und Namen 
sind nur für die wenigsten Bildstöcke bekannt.



Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens nie
schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID fuer die
ganze Bachstrasse, oder eine fuer jeden Teil-Way? Wenn ich ein
denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem Way
eine UUID, und spaeter zieht das Restaurant um auf die andere Strassenseite -
woher weiss ich dann, ob ich die UUID mit umziehen muss (weil sie in einem
Restaurantfuehrer verwendet wird) oder nicht (weil sie in einem
Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs pro Objekt,
eine fuer jeden Aspekt...


Und?

http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID#UUID_Tagging

Gibt dann halt ein uuid:building für das Gebäude und ein uuid:amenity für 
das Restaurant. Entweder beidem am Way des Gebäudes oder das uuid:building am 
Gebäude und das uuid:amenity auf dem Node für das Restaurant. Und für meine 
Bildstöcke wäre uuid:historic das richtige Tag.


Aus der Liste würde ich lediglich sowas wie uuid:operator ersatzlos streichen. 
Das muss in Chaos enden sobald jemand einen Operator mit UUID versehen will, 
der z.B. Deutschlandweit aktiv ist.


Ich finde die Idee gut. Ich habe auch schon mehrfach darüber nachgedacht einfach 
eine eigene ID als Tag in die OSM-DB zu schreiben und mich dann selber um das 
Pflegen meines Tags zu kümmern. Ebenso könnte ich aber auch ein allgemeines 
uuid:*-Tag verwenden. Würde mein Problem auch lösen und wäre dann kein 
Spezialtag, das ich erfunden habe.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden aighes


Am 23.07.2012 12:38, schrieb Manuel Reimer:
Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte 
gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und 
Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim 
Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto 
auf.


Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + 
Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, 
dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun 
UUIDs, dann könnte ich stattdessen eine von einem Mapper 
kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt 
wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen 
von Node auf Way alle Tags mit um. Dann passt es direkt wieder. 


Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das 
benötigte Objekt eine andere OSM-ID bekommt und bei UUID musst du 
eingreifen, wenn jemand das Objekt mit der UUID ändert. Wo ist der 
Vorteil der UUID?


Das Permanent ID Konzept taugt für mich garnicht, denn für die 
meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node 
als Bildstock auszeichnet.
Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann 
frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Georg,

Am 23. Juli 2012 06:31 schrieb Georg Feddern o...@bavarianmallet.de:
 Am 23.07.2012 00:09, schrieb Stefan Keller:
 Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht
 solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der
 Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines
 Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten,
 dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und
 allen Tags) erhalten bleibt und bitte ein neuer Node in den Way
 eingefügt wird und nicht - wie offenbar aktuell - der Node im Way
 erhalten wird und die Haltestelle eine neue Node-ID erhält.

 Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern,
 nur um eine OSM-interne ID an den für irgendeinen Auswerter vermeintlich
 richtigen Ort zu plazieren, wenn es doch reicht, nur zwei Objekte (H-node,
 way-node-Tags) zu verändern?
 Wer sagt, dass die Haltestelle wichtiger ist als der node in der Straße -
 der (rein hypothetisch) ein Vermessungspunkt sein könnte?

Du scheinst Objekte von OSM (Strukturen) höher zu gewichten als
Objekte der der realen Welt.
Die Sachlage ist so: Die Haltestelle hier
http://www.openstreetmap.org/browse/node/1832873388
war vorhin ein Node zweier Ways:
http://www.openstreetmap.org/browse/node/983813495/history
Was der Mapper (bzw. JOSM) offensichtlich gemacht haben, ist, dass die
Haltestelle neu erzeugt wurde.
Die Absicht des Mappers ist und war aber eindeutig die Haltestelle von
der Strassenmitte an die Seite zu verschieben.

 Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke
 geht, die keinen Namen haben!

Genau. Und bitte unter Beibehaltung der OSM ID - OSM und Nachnutzern zuliebe.

 Bei solchen Argumenten fällt mir irgendwie immer ein, das auch Koordinaten
 eindeutige IDs sind ...
 Diese IDs sind dann immer eindeutig ... und passende Objekte können auch in
 einem gewissen Suchradius gefunden werden.
 Die dann extern auf andere IDs gemappt werden können, so man unbedingt will.

Stimmt: Koordinaten sind auch Identifikatoren - und darum verlieren
ein Objekt genau diese identifizierendes Attribut wenn es verschoben
wird. Daher gibt es IDs.

 Und wenn das OSM-Objekt dann verschoben wird,
 - stimmte entweder die vorherige Projekt-ID erst gar nicht (die Parkbank mit
 der Projekt-ID 123 musste sich an der Koordinate xyz befinden!)
 - oder das Projekt-Objekt wurde tatsächlich verschoben (neue Koordinate =
 externe Zuordnung anpassen!)

Die Projekt-ID 123 bleibt in beiden Fällen hoffentlich erhalten, wenn
das Objekt nur verschoben wird - die Kundennummer einer Adresskartei
bleibt ja auch erhalten, wenn der Kunde eine andere Adresse bezieht.

 - oder es ist der ganz typische OSM-Fall: Der Mapper hat das OSM-Objekt
 komplett verändert (Projekt muss eh sein Objekt auch als OSM-Objekt
 wiederherstellen!)

Ja; wo platt is is platt - da bleibt es dem Projekt nur noch zu cachen
und zu kontrollieren, ob da wirklich in der Realität auch etwas platt
gemacht wurde.

 Aber wir erwarten doch auch nicht, das Mapper sich
 für Sitzbänke und Briefkästen irgendwelche ref-Attribute ausdenken
 müssen - dazu braucht's m.E. Projekt-IDs, oder?

 Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten
 ref-Attribut?

Ausgezeichnete Frage: Es sind drei Dinge, die eine Projekt-ID von
einem ref-Attribut unterscheiden:
Eine Projekt-ID...
1. ist eine einzige ID, die für das Projekt eindeutig ist (ref ist oft
erst mit network zusammen eindeutig - wenn überhaupt)
2. ist eine ID ist nicht sprechend und wird z.B. niemals Spaces
enthalten (wie das mit A 533 der Fall ist)
3. steht für das OSM Objekt selber (sozusagen als Mini-UUID und als
OSM-ID Ersatz) und ist (für OSM) nicht eine Referenz (ref) als Teil
eines Ganzes

Aber wie ich schon Frederik antwortete: Ich muss mir überlegen, ob
eine Kombination von Attributen (name+ref+network) den gleichen Nutzen
bringt wie eine Projekt-ID - für von Mappern ausgewählte Objekte - was
lange nicht alle sind: Parkbänke, Einzelparkplätze, etc. z.B. haben
weder Namen noch ein ref-Tag.

LG, Stefan


Am 23. Juli 2012 06:31 schrieb Georg Feddern o...@bavarianmallet.de:
 Moin,

 Am 23.07.2012 00:09, schrieb Stefan Keller:

 Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org:
 Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht
 solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der
 Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines
 Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten,
 dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und
 allen Tags) erhalten bleibt und bitte ein neuer Node in den Way
 eingefügt wird und nicht - wie offenbar aktuell - der Node im Way
 erhalten wird und die Haltestelle eine neue Node-ID erhält.


 Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern,
 nur um eine OSM-interne ID an den für irgendeinen Auswerter vermeintlich

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Peter

Am 23. Juli 2012 09:02 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 22.07.2012 23:34, schrieb Stefan Keller:

 Hallo Henning (aighes)

 Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de:

 Am 22.07.2012 22:45, schrieb Stefan Keller:

 Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:

 Oder wenn jemand das Objekt nun
 anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das
 Gebäude die ref der Straße.

 Verstehe ich nicht.

 Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
 Datenbank für alle sein kann und einfach vollgestopft werden soll mit
 Tags, die von externen Projekten kommen. Der einzige Tag den ich
 vorschlage ist diese eine Projekt_ID.

 Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen
 Vorteil
 gegenüber der normalen Objekt-ID.

 Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht
 genügt).

 Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem
 Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält
 die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es 
 ihm
 nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich
 gehört, oder zu dem Objekt Restaurant.

 Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet.
 Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht,
 dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität
 überein (und die externe Datenank registriert das) oder mit dem Mapper

 Mit dem Mapper stimmt alles, denn OSM-IDs sind Schall und Rauch und nur zur
 akuten Verwendung zwischen Objekten stabil - und an der Stelle hat der
 Mapper definitiv nichts falsch gemacht.

Ja, schon Frederik hat in die Richtung argumentiert. Wie ich ganz zu
Beginn schon gesagt habe: Entweder das Projekt kann mit unstabilen
OSM-IDs leben - oder es muss sich was einfallen lassen.

 Der betreffende Mapper ist eben vielleicht kein Datenbank-Fetischist, weiß
 unter Umständen nicht mal, was eine ID ist, und braucht das auch nicht
 wissen.

Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines
kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und
wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen
ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich
nochmals komplett neu zu erfassen.

 :- Will anständigerweise sagen, er war sich seiner unbedarften
 Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt
 das Restaurant wieder (mit seiner Projekt-ID) und löscht die
 Projekt-ID beim Parkbank.

 Das Projekt - egal ob du damit jetzt den OSM-Server oder einen beliebigen
 Editor meinst, weiß aber nunmal gar nicht, ob der mapper damit wirklich das
 Objekt verändert hat.

Mit Projekt meine ich z.B. eine Parkbänke- oder eine
Einzelparkplatz-Datenbank. Die vergibt nun solche Projekt-IDs jedem
OSM-Objekt, das es interessiert als stabile Alternative zur OSM-ID.

 Vielleicht ist die Bushaltestelle gar nicht durch ein anderes Objekt ersetzt
 worden, sondern nur durch ein neues Taggingschema, das die Software noch
 nicht kennt - deshalb aber ja nicht verboten ist.

Verboten ist nichts - nur bitte die Arbeit anderer (also hier u.a. die
Projekt-ID) stehen lassen (ausser die Bushaltestelle wurde in der
Realität aufgehoben).

 Deine Lösung erfordert also entweder festgelegte Tagging-Regeln, damit
 solche Ersetzungsregeln auch nur ansatzweise funktionieren (denn auch ein
 nachträgliches hinzufügen/hinterherziehen neuer Taggingvarianten würde sonst
 ja das brechen von IDs nicht verhindern), oder aber es funktioniert
 schlichtweg nicht.

Meine Lösung umfasst alle Eigenschaften des
Overpass-Permanent-ID-Konzepts, grenzt es ein, damit der Tag als ID
erkenntlich wird und weitet es aus auf sämtliche OSM-Objekte.

 Dass sich ein Objekt in zwei jeweils nur einzelne Aspekte dessen
 beschreibende teilt, ist damit übrigens auch noch nicht gelöst.

 Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit
 dem Namen xyz in der BBox... zu fragen.

 Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke
 leider kaum. Daher ist die Idee der kombinierten Tags unzureichend.

 Ich mappe am Montag vier Bänke auf dem Marktplatz.
 Eine davon (!) bekommt am Dienstag eine ID nach deinem Schema vom
 Schlafbank-projekt ;).

 Ich komme Freitags wieder vorbei und da stehen immer noch vier Parkbänke,
 aber nicht an der gleichen Stelle.
 Es ist definitiv nicht zu erkennen, ob die Bänke jetzt verschoben worden
 sind, oder ob das andere Bänke sind.

Nun kommen wir der Sache näher (interessantes Projekt: Schlafbänke
:-): Du musst dich als reiner OSM-Mapper in diesem Falle um nichts
kümmern - nur die Bänke erfassen (es könnten auch Einzelparkplätze
sein). Das Schlafbank-Projekt (vgl. Frederiks Vorschlag der externen
DB oben) hat am Montag erkannt, dass vier Bänke erfasst wurden und
hat eines davon  in seine DB übernommen und in OSM mit der ID
markiert und identifiziert

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Rainer Kluge


On 23.07.2012 14:22, Stefan Keller wrote:

Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines
kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und
wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen
ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich
nochmals komplett neu zu erfassen.


Der Vergleich mit einer Kundendatenbank hinkt. Gibt es keine Referenz per 
interner ID von und zu einem Kundensatz, dann kann dieser problemlos gelöscht 
und neu angelegt werden. Wenn aber die Kundendaten über eine interne ID noch mit 
Bestelldaten verknüpft sind, dann kann der Kundendatensatz nicht gelöscht 
werden. Vergleichbares ist bei den hier diskutierten Beispielen in OSM nicht 
möglich, da die Verknüpfung in der externen Anwendungsdatenbank realisiert ist.



Der Mapper soll nun natürlich gemäss seiner Wahrnehmung der Realität
entscheiden, was nun mit den Bänken geschehen sein könnte:
Entscheidet er sich dafür, dass sie verschoben wurden, soll er das mit
den vier Bänken tun (unter Beibehaltung der Projekt-ID bei der einen).
Meint er, das seien vier brandneue, löscht er die vier (inkl.
Projekt-ID) und erfasst vier neue (ohne Projekt-ID). Das
Schlafbank-Projekt kriegt ja beides mit und muss reagieren.


Nein, der gemeine Mapper nimmt die alten Bänke, verschiebt sie, ändert deren 
OSM-Tags und fasst deine Projekt-ID dabei nicht an. Er tut OSM damit was Gutes, 
weil er 4 OSM-IDs spart. Oder er macht sich Gedanken über diese Projekt-ID, 
verliert Zeit mit der Suche nach deren Bedeutung und dem Umgang mit ihr, ist 
verunsichert und lässt alles beim Alten, schliesslich will er ja nichts kaputt 
machen. Beides ist sicher nicht im Sinne des Schlafbankprojekts.


Gruß
Rainer






___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Peter Wendorff


Am 23.07.2012 13:34, schrieb Stefan Keller:

Hallo Georg,

Am 23. Juli 2012 06:31 schrieb Georg Feddern o...@bavarianmallet.de:


Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten
ref-Attribut?

Ausgezeichnete Frage: Es sind drei Dinge, die eine Projekt-ID von
einem ref-Attribut unterscheiden:
Eine Projekt-ID...
1. ist eine einzige ID, die für das Projekt eindeutig ist (ref ist oft
erst mit network zusammen eindeutig - wenn überhaupt)
eine Projekt-ID lässt sich dagegen nicht osm-intern z.B. über ein 
network-Tag überprüfen, sondern nur mithilfe einer sonstwo verstreuten 
Datenbank des betreffenden Projekts. Ohne dieser Datenbank ist sie 
genausowenig eindeutig.

2. ist eine ID ist nicht sprechend und wird z.B. niemals Spaces
enthalten (wie das mit A 533 der Fall ist)
was hat das jetzt damit zu tun? abgesehen davon, dass ich durchaus in 
meinem Projekt IDs mit Spaces erzeugen könnte; nicht besonders gut les- 
aber machbar.

3. steht für das OSM Objekt selber (sozusagen als Mini-UUID und als
OSM-ID Ersatz) und ist (für OSM) nicht eine Referenz (ref) als Teil
eines Ganzes

Aber wie ich schon Frederik antwortete: Ich muss mir überlegen, ob
eine Kombination von Attributen (name+ref+network) den gleichen Nutzen
bringt wie eine Projekt-ID - für von Mappern ausgewählte Objekte - was
lange nicht alle sind: Parkbänke, Einzelparkplätze, etc. z.B. haben
weder Namen noch ein ref-Tag.

amenity=bench + in_bbox()
amenity=parking_slot (oder wie auch immer da jetzt der aktuelle Stand 
ist) + has_coordinate(lat, lon)


wie jemand anders ja schon festgestellt hat, ist die Koordinate durchaus 
auch eine ID.


Wenn ich die Parkplätze untereinander unterscheiden will, sollte ich 
vielleicht geometrische abfragen innerhalb des Gesamtparkplatzes 
(amenity=parking) darauf ausführen, so dass ich sowas formulieren kann wie:


amenity=parking_slot at [amenity=parking, parking=surface, in_bbox()] 
[3rd-row, 42nd column].


Ob das aber wirklich noch jemand machen will, ohne sich die 
entsprechenden Dinger lokal zu speichern...


Gruß
Peter

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Stephan Wolff


Moin!

Am 22.07.2012 22:58, schrieb Frederik Ramm:

Hallo,

ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind,
auf die sich niemand sonst verlassen darf, weil dies die
Handlungsmoeglichkeiten bei OSM einschraenkt.


+1


Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant,
und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf
die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit
umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder
nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir
brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt...


Die Unklarheit der Zuordnung ist allerdings kein spezifisches Problem 
der UUIDs, sondern tritt bei allen Tags (name, height, url, ...) auf.

Selbst wenn ein Mensch die Zuordnung meist richtig macht, kann eine
Software das in der Regel nicht.
Nur wenn man generell Gebäude und Gebäudenutzer als getrennte
OSM-Objekte anlegt, gibt es solch Probleme nicht.


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.


Ohne eine eindeutige Kombination aus name, ref, network, etc. wird es
schwierig. Bei der A 516 wird es wohl funktionieren, die B 1 ist
schon schwieriger, bei Bahnstrecken oder anderen ausgedehnten Objekten
ohne ref wird es oft unmöglich.


Was aber eine gute Idee waere:

Man baut eine externe Datenbank als Interface zwischen der
Oeffentlichkeit und OSM auf.
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?


Das setzt voraus, das es zu jedem realen Objekt genau ein OSM-Objekt
gibt. Vor- und Nachteile hatten wir gerade im Thread Relationen aus
der Sicht der Auswertung - Segen oder Fluch?? diskutiert.

Viele Grüße
Stephan






___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Henning/aighes

Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de:
 Am 23.07.2012 12:38, schrieb Manuel Reimer:

 Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
 gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
 als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht
 ein Popup mit kurzem Text und einem Foto auf.

 Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto
 mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich
 in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich
 stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder
 einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so
 nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann
 passt es direkt wieder.


 Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte
 Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn
 jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID?

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
verliert (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID

 Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten
 Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als
 Bildstock auszeichnet.

Das ist genau der Grund, der für die Projekt-ID spricht.

 Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
 frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.

Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
wurde, dann ist es weg, ausserhalb der BBOX.

LG, Stefan


Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de:
 Am 23.07.2012 12:38, schrieb Manuel Reimer:

 Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
 gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
 als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht
 ein Popup mit kurzem Text und einem Foto auf.

 Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto
 mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich
 in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich
 stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder
 einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so
 nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann
 passt es direkt wieder.


 Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte
 Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn
 jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID?


 Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten
 Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als
 Bildstock auszeichnet.

 Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
 frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.

 Henning



 ___
 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!

2012-07-23 Diskussionsfäden aighes



Am 23.07.2012 17:41, schrieb Stefan Keller:

Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de:

Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
Gefahr grösser als mit der UUID, dass das Projekt das Objekt
verliert (da es einer gelöscht und mit denselben Tags neu erstellt
hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
überprüfen. Daher die UUID, bzw. die Projekt-ID

Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?


Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox.

Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
wurde, dann ist es weg, ausserhalb der BBOX.
Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl 
nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall 
sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen 
Objekt passen.


Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, 
wäre es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man 
will also wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden 
kopieren der UUID merkt man davon leider nicht viel.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Roland Olbricht

Hallo Manuel,

 Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
 gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
 als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht
 ein Popup mit kurzem Text und einem Foto auf.

Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto 
und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich 
(z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als 
url=... oder website=... ein.

Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine 
Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck 
des Tags ohne Recherche erkennbar ist.

Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit 
für Suchmaschinen und macht gezielt Werbung für Euer Projekt.

Viele Grüße,

Roland
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Henning

Am 23. Juli 2012 18:45 schrieb aighes o...@aighes.de:
 Am 23.07.2012 17:41, schrieb Stefan Keller:
 Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
 Gefahr grösser als mit der UUID, dass das Projekt das Objekt
 verliert (da es einer gelöscht und mit denselben Tags neu erstellt
 hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
 überprüfen. Daher die UUID, bzw. die Projekt-ID

 Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?

Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli
2012 13:34 an Georg.
Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine
Herausforderung zu sein, so einen Node zu verschieben und die ID
beizubehalten.
Siehe auch Frederiks Antwort vom vergangenen August dazu:
http://permalink.gmane.org/gmane.comp.gis.openstreetmap/59050

 Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
 frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen
 BBox.

 Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
 wurde, dann ist es weg, ausserhalb der BBOX.

 Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht
 mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte
 dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen.

Es gibt etliche Gebiete, die ab Orthofotos abdigitalisiert wurden und
die um mehrere Meter (bis zu 30!) falsch sind, weil die Orthofotos
falsch waren.
Da steht man mit BBox sprichwörtlich im Schilf.

LG, Stefan


Am 23. Juli 2012 18:45 schrieb aighes o...@aighes.de:
 Am 23.07.2012 17:41, schrieb Stefan Keller:
 Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de:

 Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die
 Gefahr grösser als mit der UUID, dass das Projekt das Objekt
 verliert (da es einer gelöscht und mit denselben Tags neu erstellt
 hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so
 überprüfen. Daher die UUID, bzw. die Projekt-ID

 Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist?


 Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann
 frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen
 BBox.

 Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben
 wurde, dann ist es weg, ausserhalb der BBOX.

 Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht
 mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte
 dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen.

 Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, wäre
 es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man will also
 wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden kopieren der
 UUID merkt man davon leider nicht viel.


 Henning


 ___
 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 Roland

Am 23. Juli 2012 22:47 schrieb Roland Olbricht roland.olbri...@gmx.de:
 Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto
 und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich
 (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als
 url=... oder website=... ein.

 Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine
 Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck
 des Tags ohne Recherche erkennbar ist.

 Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit
 für Suchmaschinen und macht gezielt Werbung für Euer Projekt.

Genau in die Richtung geht auch mein Vorschlag, denn die URL (url=...
oder website=...) wird damit zu einem Identifikator im Sinne meiner
Projekt-ID. Ich würde statt BasisURL+UUID aber nicht die UUID nehmen -
die ist mir zu lang - sondern einen kürzeren Identifikator, den ich
innerhalb meines Projekts eindeutig und permanent halte.

Das Problem ist wieder, dass nur wenige Sitzbänke Sehenswürdigkeiten
sind und auch nicht alle bebildert sind, so dass man eine URL oder
sonst etwas identifizierendes dran hängen kann.

Was es braucht, ist einen erkennbaren Identifikator, der für alle für
das externe Projekt relevanten OSM Objekte gilt. Daher mein Vorschlag
einer Projekt-ID (z.B. schlafbank_id=...).

Das geht in Richtung Linked Data, daher spreche ich von jetzt an
alternativ von Projekt-ID/Linked Data ID. Die Projekt-ID ist
eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen
Projekt) permanent.

Frederik sprach in [1], dass UUID database bloat seien; das kann ich
nachvollziehen. Das gilt aber für Projekt-ID/Linked Data ID nur
bedingt, denn ein solches Projekt (bzw. externe Datenbank) gibt OSM
etwas zurück für den minimalen Ballast den OSM tragen muss.

LG, Stefan

[1] http://permalink.gmane.org/gmane.comp.gis.openstreetmap/59050


Am 23. Juli 2012 22:47 schrieb Roland Olbricht roland.olbri...@gmx.de:
 Hallo Manuel,

 Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte
 gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten
 als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht
 ein Popup mit kurzem Text und einem Foto auf.

 Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto
 und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich
 (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als
 url=... oder website=... ein.

 Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine
 Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck
 des Tags ohne Recherche erkennbar ist.

 Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit
 für Suchmaschinen und macht gezielt Werbung für Euer Projekt.

 Viele Grüße,

 Roland
 ___
 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 Frederik

Am 24. Juli 2012 00:03 habe ich in meiner Antwort an Roland nochmals
darauf hingewiesen, dass ich einen erkennbaren Identifikator meine,
der für alle für das externe Projekt relevanten OSM Objekte gilt und
auch für solche funktioniert, die keine besonderen Merkmale haben.
Daher mein Vorschlag einer Projekt-ID (z.B. schlafbank_id=...), was in
Richtung Linked Data geht. Diese Projekt-ID/LinkedData-ID ist
eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen
Projekt) permanent.

In diesem Sinne gibt die externe Datenbank (die ähnlich deinem
Vorschlag gemeint ist) etwas zurück für den minimalen Bloat den OSM
wegen der Projekt-ID/LinkedData-ID tragen muss.

Was ich bei deinem Vorschlag einer externen Datenbank noch etwas
konkretisieren möchte ist folgendes:
* Wie geht man hier mit OSM Objekten um, auf die kein fuzzy link
definiert werden kann (wie z.B. Sitzbänke)?
* Du sprichst davon, dass jedermann stored queries auf fuzzy links
(im Sinne Tim Alders query-to-map) anlegen kann: An welche
Query-Syntax hast du gedacht?
* Wieso sollten solche queries/fuzzy links nicht gerade von den
Betreibern der externen Datenbank in OSM eingetragen werden?
* Bisher haben wir von externen Datenbanken gesprochen - also
Mehrzahl: Gehört so eine externe Datenbank nicht eigentlich zur OSM
Infrastruktur?

LG, Stefan


Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org:
 Hallo,

ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf
 die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten
 bei OSM einschraenkt.

 Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen sollte,
 seine Daten auf mehrere Server auf verschiedenen Kontinenten aufzuteilen und
 daher alle Objekte auf neue Server mit neuen Nummernraeumen verteilt, sollte
 das niemanden stoeren.

 Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden Objekte
 umnumeriert, um nicht mehr genutzte Luecken wiederzuverwenden, sollte
 das keine Probleme verursachen.

 Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und neu
 einfuegt, sollte niemand davon etwas merken.

 Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde
 zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das
 Leben schwerer zu machen - m.E. keine gute Idee.

 UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der
 Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper soll
 sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X ist, und
 wenn das Restaurant umzieht auf die andere Strassenseite, dann loescht er
 das und legt es neu an, oder er schiebt es rueber, ganz wie es gerade am
 geeignetsten erscheint.

 Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens
 nie schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID
 fuer die ganze Bachstrasse, oder eine fuer jeden Teil-Way? Wenn ich ein
 denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem
 Way eine UUID, und spaeter zieht das Restaurant um auf die andere
 Strassenseite - woher weiss ich dann, ob ich die UUID mit umziehen muss
 (weil sie in einem Restaurantfuehrer verwendet wird) oder nicht (weil sie in
 einem Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs
 pro Objekt, eine fuer jeden Aspekt...


 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.


 Ich halte das fuer die beste Loesung, die wir haben, weil hier derjenige,
 der den Link setzt, entscheiden muss, was ihm wichtig ist, und die Mapper
 sich nicht damit herumschlagen muessen.

 Das Problem der unvermeidbaren Unzulaenglichkeiten wird dadurch nicht
 geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der
 anderen Strassenseite neu zeichne, wird das immer noch gefunden.


 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.


 Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme wie
 das UUID-Konzept.

 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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-23 Diskussionsfäden Werner Hoch

Hallo,

Am Sonntag, den 22.07.2012, 21:22 +0200 schrieb Stefan Keller:
 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs
 ungewollt/unfreiwillig?
 
 Oben wird die Overpass Permanent ID erwähnt
 (http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ) und
 dort steht: ...you shouldn't use an object ID, because the OSM IDs
 may change at any time. Das würde ich gerne mal näher analysieren:
 
 Ein klarer Fall für ein Löschen und Neu-Einfügen (mit neuer ID)
 scheint mir zu sein, wenn das auch in der realen Welt der Fall ist:
 Wenn z.B. ein Gebäude abgerissen und neu erstellt wird, oder ein
 wichtiger Einzelbaum gefällt und neu gepflanzt wird.
 
 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 ist
 aber kein logisch zwingender Grund, sondern technischer Mangel.

Dieses Problem lässt sich umgehen, wenn man nicht mit der Version des
Weges arbeitet, sondern zusätzlich mit einem Datum.

Ein way X lässt sich zu jedem Zeitpunkt und immer gleich aus OSM (und
der OSM-Historie) extrahieren.
Dieses Objekt(mit Datum) ist stabil. Diese Information ließen sich
cachen und bei Bedarf gegen die Objekte mit aktuellerem Datum
abgleichen.

Wie kommt man an das Objekt mit ObjektID+Datum?
-- alle referenzierten Objekte mit dem entsprechenden Datum ermitteln.
Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr
aufwändig.

Vor einigen Jahren habe ich mal einen Prototypen geschrieben, der über
die API aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann:
Beschreibung:
http://www.h-renrew.de/h/osm/tools/osmhistory.html
Quelltext:
https://github.com/werner2101/python-osm

Anmerkungen:
* Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die  
  Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden.
* Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction
  Bot verändert wurden.

Grüße
Werner



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Pascal Neis


Hi Stefan,

Stefan Keller schrieb:

Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen
OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken.


ich denke du suchst sowas in der Art, oder?
Dauerhafte Links nach OSM - Overpass API
http://blog.openstreetmap.de/2012/03/dauerhafte-links-nach-osm/

viele gruesse
pascal

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Jo

Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe
vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei.

Polyglot
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden aighes


Am 22.07.2012 21:38, schrieb Jo:

Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe
vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei.
Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit 
OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche 
spezifischen Tags an Objekte hängt?


Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht 
und ein neues ohne all die ref-Tags erstellt? Oder wenn jemand das 
Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf 
einmal das Gebäude die ref der Straße.


Henning


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Walter Nordmann


schau dir mal die sache mit den uuids an. ich glaube, dass das ein
interessanter Ansatz ist.

https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID

von diesem thread find ich gerade nicht den anfang: 
http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html

uuid für osm geistert schon lange bei uns rum, ist aber irgendwie
eingeschlafen.

Gruss
walter

p.s. sorry, bin gerade knapp dran mit zeit.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Peter Wendorff


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

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Pascal

Am 22. Juli 2012 21:30 schrieb Pascal Neis pascal.n...@gmail.com:
 Hi Stefan,

 Stefan Keller schrieb:

 Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen
 OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken.


 ich denke du suchst sowas in der Art, oder?
 Dauerhafte Links nach OSM - Overpass API
 http://blog.openstreetmap.de/2012/03/dauerhafte-links-nach-osm/

Jein; das Problem dieses Vorschlags ist, dass er zusammengesetzte,
z.T. sprechende Schlüssel vorschlägt. Vgl. meine Ausführungen unten.

LG, Stefan

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Simon Poole


Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID

Am 22.07.2012 22:19, schrieb Walter Nordmann:
 schau dir mal die sache mit den uuids an. ich glaube, dass das ein
 interessanter Ansatz ist.

 https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID

 von diesem thread find ich gerade nicht den anfang: 
 http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html

 uuid für osm geistert schon lange bei uns rum, ist aber irgendwie
 eingeschlafen.

 Gruss
 walter

 p.s. sorry, bin gerade knapp dran mit zeit.



 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.html
 Sent from the Germany mailing list archive at Nabble.com.

 ___
 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 Jo/aighes und Henning

Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:
 Am 22.07.2012 21:38, schrieb Jo:

 Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe
 vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei.

Fast genau: Ich aber statt ref:myproject=(foreign key) lieber
schreiben ref:myproject=(unser_projekt_OSM_ID).
Der Unterschied ist minim, denn ich will der OSM nicht meine Objekt
unterjubeln, sondern das OSM Objekt in unserer externen DB verwenden
und den Mappern gleichzeitig signalisieren, dass es dieses externe
Projekt gibt.

 Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit
 OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche
 spezifischen Tags an Objekte hängt?

Also nochmals um das klarzustellen: Anwendungen, die mit der OSM ID
wie sie jetzt ist klarkommen, brauchen nichts zu tun.
Anwendungen hingegen, die OSM nicht mit eigenen Daten belasten und
z.B. selber weitere Attribute verwalten wollen, sind auf (für sie)
permanente/stabile/dauerhafte OSM IDs angewiesen. Dazu dient dieser
Vorschlag.

 Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und
 ein neues ohne all die ref-Tags erstellt?

Das würde in meinem Fall ein Achtung da hat jemand unser Objekt
gelöscht signalisieren und er müsste dem nachgehen, was Sache ist.
Jedenfalls hoffe ich nicht, dass es unlautere Absichten sind, denn
bestehende Tags sollten ja erhalten bleiben, wenn das Objekt z.B. nur
verschoben wird (vgl. das DIDOK-Beispiel oben).

 Oder wenn jemand das Objekt nun
 anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude
 die ref der Straße.

Verstehe ich nicht.

Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
Datenbank für alle sein kann und einfach vollgestopft werden soll mit
Tags, die von externen Projekten kommen. Der einzige Tag den ich
vorschlage ist diese eine Projekt_ID.

LG, S.

Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:
 Am 22.07.2012 21:38, schrieb Jo:

 Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe
 vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei.

 Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit
 OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche
 spezifischen Tags an Objekte hängt?

 Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und
 ein neues ohne all die ref-Tags erstellt? Oder wenn jemand das Objekt nun
 anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude
 die ref der Straße.

 Henning



 ___
 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!

2012-07-22 Diskussionsfäden Tobias Knerr

Am 22.07.2012 21:22, schrieb Stefan Keller:
 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.

Viele Bearbeitungsoperationen kann man in der Tat so durchführen, dass
eine ID erhalten bleibt, aber das ist keine Garantie, dass ein Mapper
auch diesen Weg wählen wird - und es gibt auch keine Pflicht, das zu tun.

Zudem gibt es Änderungen der Darstellungsform (Umbau von Node auf
Fläche, oder von geschlossenem Way auf Relation), bei denen der Erhalt
einer ID schon vom Prinzip her nicht möglich ist. Ebensowenig kann etwa
beim Auftrennen eines der Ways einer Straße die Liste der IDs für die
Straße erhalten bleiben.
 
 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 ändert schon etwas: IDs sind versteckte Eigenschaften, die der
Mapper bedenkenlos ändern darf und oft wird. Tags sind hingegen
Eigenschaften, bei denen beim Bearbeiten klar sein sollte, dass das
nach außen, also für Datennutzer, Folgen haben wird und man sich daher
beim Ändern Gedanken machen muss.

 Mein Minimalvorschlag ist, dass nur eine klar am Tagnamen erkennbare
 projektspezifische ID eingeführt wird, die niemals mehr verändert wird
 (ausser sie geht mit dem OSM Objekt unter). Die externe Datenbank
 verwaltet die Beziehung zwischen ihren Objekten und dem so
 bezeichneten OSM-Objekt selber. Bei OpenMetaMap steht zurzeit OSM ID
 (für keyA bzw. Object ID); da wäre nun nur noch eine
 openmetamap_osm_id nötig.

Diese Option scheitert schon daran, dass es auf lange Sicht zu viele
Datenbanken geben dürfte, die mit OSM interagieren wollen. Das geht gut,
solange es sich um einige wenige, bekannte Projekte handelt - z.B. bei
den existierenden Wikipedia-Links -, aber wenn jetzt außer Flickr noch
dutzende weitere kommerzielle Fotoportale OSM-Verlinkungen einführen
wollen, würden diese Tags ausufern.

Es ist außerdem auch nicht klar, welche Eigenschaft dem Verlinker nun
wichtig ist. Wenn ein Restaurant umzieht, ist es dann noch dasselbe
Restaurant? Die Definition von dasselbe ist vermutlich für jedes der
verlinkten Projekte anders, und man kann nicht erwarten, dass der Mapper
die Kriterien jedes der Projekte kennt.

Bei einer Query hingegen ist das ganz automatisch definiert - da müssen
in der Query eben genau die Eigenschaften eingebaut sein, die für den
Verlinker das Objekt ausmachen.

Von daher denke ich weiterhin, dass die Identifikation über
Eigenschaften aus der realen Welt (was auf geeignete Queries in z.B.
Overpass hinausläuft) die richtige Lösung ist. Solche Probleme wie dein
Beispiel mit Leerzeichen sind vorhersehbar, so dass man sich in vielen
Fällen darauf vorab einstellen kann.

Gruß,
Tobias

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Andreas Neumann

Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche
OSM-ID schon ändert. Was am meisten bestand hat, sind IDs aus
offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich:

Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt
wurden. Es gibt auch für jede Straße eine offizielle ID (die man z.B.
bei der Fahrrad-Kodierung verwendet) oder halt auch für jede Ortschaft.
Das bedeutet aber, dass man da erstmal einen externen Katalog finden muss.

Natürlich ginge es auch eine ID aus einem eigenen Katalog zu verpassen,
um es mit dem eigenen Projekt zu verknüpfen, jedoch bevorzuge ich schon
offizielle Identifikationsmerkmale, und nicht zig ref:*=* zu ein und dem
selben Objekt Der Übersichtlichkeit wegen ;).

MfG Andreas

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Simon

2012/7/22 Simon Poole si...@poole.ch:

 Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID

Das wäre genau so eine Projekt ID, die ich meinte!

Stefan


2012/7/22 Simon Poole si...@poole.ch:

 Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID

 Am 22.07.2012 22:19, schrieb Walter Nordmann:
 schau dir mal die sache mit den uuids an. ich glaube, dass das ein
 interessanter Ansatz ist.

 https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID

 von diesem thread find ich gerade nicht den anfang:
 http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html

 uuid für osm geistert schon lange bei uns rum, ist aber irgendwie
 eingeschlafen.

 Gruss
 walter

 p.s. sorry, bin gerade knapp dran mit zeit.



 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.html
 Sent from the Germany mailing list archive at Nabble.com.

 ___
 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

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Peter

Am 22. Juli 2012 22:30 schrieb Peter Wendorff wendo...@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 wendo...@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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden Frederik Ramm


Hallo,

   ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, 
auf die sich niemand sonst verlassen darf, weil dies die 
Handlungsmoeglichkeiten bei OSM einschraenkt.


Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen 
sollte, seine Daten auf mehrere Server auf verschiedenen Kontinenten 
aufzuteilen und daher alle Objekte auf neue Server mit neuen 
Nummernraeumen verteilt, sollte das niemanden stoeren.


Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden 
Objekte umnumeriert, um nicht mehr genutzte Luecken 
wiederzuverwenden, sollte das keine Probleme verursachen.


Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und 
neu einfuegt, sollte niemand davon etwas merken.


Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde 
zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das 
Leben schwerer zu machen - m.E. keine gute Idee.


UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren 
der Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper 
soll sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X 
ist, und wenn das Restaurant umzieht auf die andere Strassenseite, dann 
loescht er das und legt es neu an, oder er schiebt es rueber, ganz wie 
es gerade am geeignetsten erscheint.


Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines 
Erachtens nie schluessig dargelegt werden, was die UUID genau sein soll. 
Eine UUID fuer die ganze Bachstrasse, oder eine fuer jeden Teil-Way? 
Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, 
und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf 
die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit 
umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder 
nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir 
brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt...



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.


Ich halte das fuer die beste Loesung, die wir haben, weil hier 
derjenige, der den Link setzt, entscheiden muss, was ihm wichtig ist, 
und die Mapper sich nicht damit herumschlagen muessen.


Das Problem der unvermeidbaren Unzulaenglichkeiten wird dadurch nicht 
geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der 
anderen Strassenseite neu zeichne, wird das immer noch gefunden.



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.


Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme 
wie das UUID-Konzept.


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.


Und das beste: Man muss OSM nicht mit seinen Privatkeys ueberfluten, um 
das machen zu koennen.


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] Permanente/stabile OSM IDs!

2012-07-22 Diskussionsfäden aighes


Am 22.07.2012 22:45, schrieb Stefan Keller:

Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:

Oder wenn jemand das Objekt nun
anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude
die ref der Straße.

Verstehe ich nicht.

Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
Datenbank für alle sein kann und einfach vollgestopft werden soll mit
Tags, die von externen Projekten kommen. Der einzige Tag den ich
vorschlage ist diese eine Projekt_ID.


Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen 
Vorteil gegenüber der normalen Objekt-ID.


Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem 
Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält 
die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil 
es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an 
sich gehört, oder zu dem Objekt Restaurant.


Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit 
dem Namen xyz in der BBox... zu fragen.


Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat 
eine Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was 
vorher Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder 
nicht, ob die ID nun zur Bundestraße gehört oder zu der Straße an diesem 
Ort (können ja auch mehrere ID's an dem Way sein, die jeweils 
unterschiedliche Bezüge haben).


In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht 
bemerkt wird und wenn er bemerkt werden würde, dann würde er auch 
bemerkt, wenn man nach der OSM-ID gegangen wäre.


Henning
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

Hoi Andreas

Am 22. Juli 2012 22:52 schrieb Andreas Neumann andr-neum...@gmx.net:
 Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche
 OSM-ID schon ändert.

Genau. Siehe auch meine Antwort an Peter oben.

 Was am meisten bestand hat, sind IDs aus
 offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich:

 Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt
 wurden.

Solch ein offizieller Katalog wären genau solch ein Projekt einer
externen Datenbank.
Meine Idee ist es nun aber, dass dieser Katalog weiterhin bestehen
bleibt und nicht meint, er könne OSM mit einem Import beglücken und
durch OSM ersetzt zu werden.
Mein Vorschlag zielt darauf ab, dass diese Schulhäuser in OSM getaggt
und wenn nötig/möglich eingetragen werden (sagen wir als
Gebäudepolygone), OSM dann aber auch genutzt werden kann, um den
Katalog aktuell zu halten.

LG, Stefan

Am 22. Juli 2012 22:52 schrieb Andreas Neumann andr-neum...@gmx.net:
 Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche
 OSM-ID schon ändert. Was am meisten bestand hat, sind IDs aus
 offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich:

 Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt
 wurden. Es gibt auch für jede Straße eine offizielle ID (die man z.B.
 bei der Fahrrad-Kodierung verwendet) oder halt auch für jede Ortschaft.
 Das bedeutet aber, dass man da erstmal einen externen Katalog finden muss.

 Natürlich ginge es auch eine ID aus einem eigenen Katalog zu verpassen,
 um es mit dem eigenen Projekt zu verknüpfen, jedoch bevorzuge ich schon
 offizielle Identifikationsmerkmale, und nicht zig ref:*=* zu ein und dem
 selben Objekt Der Übersichtlichkeit wegen ;).

 MfG Andreas


 ___
 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 Henning (aighes)

Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de:
 Am 22.07.2012 22:45, schrieb Stefan Keller:
 Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:

 Oder wenn jemand das Objekt nun
 anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das
 Gebäude die ref der Straße.

 Verstehe ich nicht.

 Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
 Datenbank für alle sein kann und einfach vollgestopft werden soll mit
 Tags, die von externen Projekten kommen. Der einzige Tag den ich
 vorschlage ist diese eine Projekt_ID.

 Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil
 gegenüber der normalen Objekt-ID.

Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht genügt).

 Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem
 Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die
 Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm
 nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört,
 oder zu dem Objekt Restaurant.

Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet.
Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht,
dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität
überein (und die externe Datenank registriert das) oder mit dem Mapper
:- Will anständigerweise sagen, er war sich seiner unbedarften
Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt
das Restaurant wieder (mit seiner Projekt-ID) und löscht die
Projekt-ID beim Parkbank.

 Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem
 Namen xyz in der BBox... zu fragen.

Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke
leider kaum. Daher ist die Idee der kombinierten Tags unzureichend.

 Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine
 Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher
 Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob
 die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können
 ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge
 haben).

Der Mapper hat hier die freie Wahl! Er soll einfach den Tag
irgendwohin tun - nur in (wie üblich) nicht löschen. Das Projekt
kümmert sich (hoffentlich) drum.

LG, Stefan

Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de:
 Am 22.07.2012 22:45, schrieb Stefan Keller:

 Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de:

 Oder wenn jemand das Objekt nun

 anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das
 Gebäude
 die ref der Straße.

 Verstehe ich nicht.

 Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine
 Datenbank für alle sein kann und einfach vollgestopft werden soll mit
 Tags, die von externen Projekten kommen. Der einzige Tag den ich
 vorschlage ist diese eine Projekt_ID.


 Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil
 gegenüber der normalen Objekt-ID.

 Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem
 Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die
 Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm
 nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört,
 oder zu dem Objekt Restaurant.

 Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem
 Namen xyz in der BBox... zu fragen.

 Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine
 Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher
 Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob
 die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können
 ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge
 haben).

 In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht bemerkt
 wird und wenn er bemerkt werden würde, dann würde er auch bemerkt, wenn man
 nach der OSM-ID gegangen wäre.


 Henning
 ___
 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!