date:20120727


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 
:

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!


Am 27.07.2012 17:31, schrieb Stefan Keller:

Lieber Peter

Am 27. Juli 2012 17:18 schrieb Peter Wendorff :

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 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] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-27 Diskussionsfäden Hartmut Holzgraefe

On 07/26/2012 11:41 AM, Frederik Ramm wrote:

> Ich hab jetzt bei den roten Sachen noch die Moeglichkeit eingebaut, sie
> von der Karte zu werfen, mit einem Muelleimer-Icon

irgendwie ist alles was ich gestern gelöscht habe heute wieder da, und
auch mein Löschliebling, die Humboldtstraße in Bielefeld, ist jetzt auf
meinem Laptop wieder rot obwohl ich die heute morgen auf meinem Desktop
noch einmal gelöscht habe?

http://tools.geofabrik.de/osmi/?view=redactionbot&lon=8.51703&lat=52.02503&zoom=16&overlays=overview,bot_point_superseded,bot_line_superseded_cp,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted

-- 
hartmut

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

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

Lieber Peter

Am 27. Juli 2012 17:18 schrieb Peter Wendorff :
> 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 :
> Am 27.07.2012 16:23, schrieb Stefan Keller:
>
>> Hallo Manuel
>>
>> Am 27. Juli 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.
>>
>> 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 16:23, schrieb Stefan Keller:

Hallo Manuel

Am 27. Juli 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.

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!

Hallo

Am 27. Juli 2012 16:52 schrieb Peter Wendorff :
> Am 27.07.2012 16:16, schrieb Stefan Keller:
>
>> Hallo
>>
>> Am 27. Juli 2012 08:55 schrieb Peter Wendorff :
>>>
>>> ...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
>>>
>>> projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
>>> = 12423528312313513412351341351
>>
>> Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung
>> aber sicher nicht für die Anwendungsfälle zur datenbankmässigen
>> Verknüpfung.
>> Die Änderung auch nur eines der Attributwerte (values) würde die ID
>> zerstören.
>
> Genau das, was ich will:

Ok. Dann bin ich reden wir aber von ganz verschiedenen Anwendungsfällen :->

> Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes
> Objekt betrachten, also SOLL die ID doch kaputtgehen.

Stimmt. Das ist ein gerechtfertigtes Löschen und einfügen.

> Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes
> Objekt betrachten, also SOLL die ID kaputtgehen.

Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele
zusammengetragen, wo die Koordinaten sich ändern, in dem ganze
Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass
es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle
verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer
dieser Verschiebung nicht traut, kann selber nachschauen - das aber
nicht auf "Kosten" der anderen verlangen, dass die Bushaltestelle
damit à priori eine andere sei.

> Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
> betrachten, also SOLL die ID kaputtgehen.

Das sind alle Systeme gleich.

> Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht,
> reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].

Das ist kein Anwendungsfall, um den es mir hier geht.

> Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht
> und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern
> muss.
>
> Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir
> auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise
> nicht.
> Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
> Kriterien, und die kann ich in Attributen fassen, die dann einer ID ähnlich
> sind.

Nein: Ich möchte lediglich eine permanente/stabile ID anbieten und die
Kriterien, nach denen das getan wird den Nutzern überlassen.
Ich möchte einzig eine Lösung, welche nach aussen unabhängig ist von
OSM-IDs und nach der OSM-DB eindeutig ist in Bezug auf das OSM-Objekt.
Daher kommt eine (nicht von aussen ersichtliche) Kombination von Tags
und ein Ausschluss nicht-mit-normalen-Tags-identifiziertbarer
OSM-Objekte nicht in Frage.

Dies gesagt, halte ich aber immer noch ein Türchen offen für
Argumente, die für B1 sprechen, bei der die Interface-DB (LinkedOSMDB)
sich mit OIDs herumschlägt.

>> Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
>> wird und gegen aussen eine UUID/PID angeboten wird.
>
> Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API
> schon, ohne zusätzliche Tags oder Attribute.

Die Overpass-API ist alles andere als stabil gemäss meinen Kriterien.
Das wäre dann Lösungsvariante B3.

LG, Stefan

Am 27. Juli 2012 16:52 schrieb Peter Wendorff :
> Am 27.07.2012 16:16, schrieb Stefan Keller:
>
>> Hallo
>>
>> Am 27. Juli 2012 08:55 schrieb Peter Wendorff :
>>>
>>> ...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
>>>
>>> projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
>>> = 12423528312313513412351341351
>>
>> Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung
>> aber sicher nicht für die Anwendungsfälle zur datenbankmässigen
>> Verknüpfung.
>> Die Änderung auch nur eines der Attributwerte (values) würde die ID
>> zerstören.
>
> Genau das, was ich will:
> Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes
> Objekt betrachten, also SOLL die ID doch kaputtgehen.
> Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes
> Objekt betrachten, also SOLL die ID kaputtgehen.
> Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
> betrachten, also SOLL die ID kaputtgehen.
>
> Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht,
> reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].
>
> Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht
> und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern
> muss.
>
> Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir
> auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise
> nicht.
> Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
> Kriterien,

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
 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 :
> 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:building&restaurant&name?
>>
>>
>> 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!

Am 27.07.2012 16:16, schrieb Stefan Keller:

Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff :

...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
= 12423528312313513412351341351

Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung
aber sicher nicht für die Anwendungsfälle zur datenbankmässigen
Verknüpfung.
Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören.

Genau das, was ich will:
Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als
anderes Objekt betrachten, also SOLL die ID doch kaputtgehen.
Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein
anderes Objekt betrachten, also SOLL die ID kaputtgehen.
Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
betrachten, also SOLL die ID kaputtgehen.

Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße
geht, reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].

Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM
drinsteht und sich niemand zusätzlich um die Pflege irgendeines
ID-Systems kümmern muss.

Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht
mir auch die alte OSM-ID für 80% der Fälle aus - das will ich aber
üblicherweise nicht.
Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
Kriterien, und die kann ich in Attributen fassen, die dann einer ID
ähnlich sind.

Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.
Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API
schon, ohne zusätzliche Tags oder Attribute.

Gruß
Peter

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

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

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 :
> Hallo
>
> Am 27. Juli 2012 08:55 schrieb Peter Wendorff :
>> ...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 :
>> 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 :
> 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 :
> 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!

Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff :
> ...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 :
> 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 Rainer

Am 27. Juli 2012 07:31 schrieb Rainer Kluge :
> On 26.07.2012 23:23, Stefan Keller wrote:
>> Am 26. Juli 2012 18:57 schrieb Peter Wendorff:
>>
>>> 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 :
> On 26.07.2012 23:23, Stefan Keller wrote:
>>
>> Am 26. Juli 2012 18:57 schrieb Peter Wendorff:
>>>
>>> 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!

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!


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:building&restaurant&name?


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 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:building&restaurant&name?


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


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:building&restaurant?
Wenn ich eigentlich nicht einen Link zu "das Restaurant da" meine, 
sondern das Restaurant zum Hirsch, dann setze ich 
uuid:building&restaurant&name?


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!

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!