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" (die andern drei genügten den Anforderungen nicht). > 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? 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. >>> 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. Projekt-IDs wurden ja vom Projekt dem OSM-Objekt zugeordnet und gehören dazu wie name oder ref oder network oder irgendein anderes Attribut (nur dass Projekt-ID eben fürs Projekt eindeutig sind). Der Unterschied ist, dass mit Projekt-IDs das Objekt ein Löschen und Neuerfassen (mit denselben Attrbuten) "übersteht" und dies nicht nur (wie beim Overpass-Permanent-ID-Konzepts) für OSM-Objekte gilt, die name, ref und/oder network - oder eine wilde und stetig ändernde Kombination davon. LG, Stefan _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
