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