Hallo!
Also gut, ich habe die EGID wieder rausgenommen. Ist der Import-Wiki-Artikel Eurer Meinung nach jetzt gut genug zum Vorstellen auf der Imports-Liste? https://wiki.openstreetmap.org/wiki/Canton_Basel-Stadt_Building_and_Address_Import
Gruss, Johannes
Am 08.10.2017 um 20:41 schrieb michael spreng:
Hallo
Ich möchte auch bitten, keine EGID. Ich habe Erfahrungen mit solchen externen schlüsseln aus den Haltestellen. Dort gibt es eine ID, die nützlich ist für Fahrplanabfragen. Und ich habe schon alles gesehen, was schief gehen kann. Das wird kopiert und verschoben. Das ist bei einem update keine Hilfe. Besser ist ein Vergleich der diese ID nicht verwendet.
Ein Vergleich ohne ID (externer Schlüssel) ist stabiler und einfacher in der Datenpflege.
Grüsse Michael
On 07/10/17 09:20, Johannes Singler wrote:
Hallo Michael!
Am 06.10.2017 um 13:14 schrieb Michael Reichert:
Hallo Johannes,
Am 2017-10-06 um 07:57 schrieb Johannes Singler:
- Sollen wir PLZ und Ort wirklich taggen, oder wird das zuverlässig
automatisch durch die verwendenden Tools, z. B. Nominatim, herausgefunden? Würde aber halt einfach nur Daten sparen...
In der Schweiz werden keine PLZ-Grenzen in OSM erfasst. Dazu gab es schon mehrfach Diskussionen. Also ist das Erfassen derselbigen an den Adressobjekten erforderlich.
Okay, gut. Den Ort (city:addr) dann auch? PLZ ohne Ort ist seltsam, oder?
- Sollen wir eine eindeutige ID taggen? Die Datensätze haben eine
sechsstellige Nummer "GWR_EGID" ("Eidgenössischer Gebäudeidentifikator"), die für Gebäude und Adresse gleich ist. Wenn ja, welchen OSM-Tag soll ich dafür verwenden? Außerdem scheinen die Adressen noch Straßen über eindeutige Nummern zu referenzieren. Das Importieren eindeutiger IDs wird hier befürwortet: https://blog.emacsen.net/blog/2014/03/13/the-maintenance-of-imported-data-in...
Wenn ein Fremdschlüssel nicht vor Ort verifizierbar ist, muss es gute Gründe geben, ihn dennoch in OSM einzutragen. Bei Importen meinen manche Importeure, dass es Updates erleichtert. Sie setzen dabei folgende Annahmen für wahr voraus:
- Es wird ein Update geben (und sie pflegen es ein).
Irgendwann *wird* es eines geben, die EGID ist so stabil wie die Gebäude, hält also Jahrzehnte. Dann kann man sie verwenden oder auch nicht.
- Die Mapper wissen, wie man korrekt mit dem Tag umgeht.
Viel kaputt machen kann man nicht, im schlimmsten Fall wird das Tag verloren gehen.
2.a Niemand verändert das GWR-EGID-Tag. In fünf Jahren kann man sich blind darauf verlassen.
Es wird immer Gebäude ohne EGID-Tag geben. Bei denen nimmt man dann einfach an, dass sie händisch eingetragen wurden. Wenn einige importierte das EGID-Tag verlieren, werden sie wie manuelle Änderungen betrachtet. Ich denke nicht, dass es davon viele geben wird. Und wieso sollte jemand den Wert eines solchen Tags *ändern*?
2.b Wenn jemand eine Adresse in OSM ergänzt, deren Gebäude seit dem Erstimport neu gebaut wurde, setzt er ein GWR-EGID-Tag.
Und wenn nicht, erkennt man es eben als manuellen Änderung, der dann belassen oder ersetzt wird, wie eine sonstige manuelle Änderung auch.
Es ist IMHO sinnvoller, beim Import eines Updates die Differenz zwischen den alten und neuen amtlichen Daten zu bilden und zu prüfen,
Aber wer hat dann die alten amtlichen Daten noch? Wir können sie nicht einfach irgendwo ablegen, denn sie lassen sich nicht komplett herunterladen, sondern nur stückweise.
ob diese Veränderungen schon ihren Weg in OSM gefunden haben. So ein Updateimport wäre manuell mit maschineller Unterstützung (Differenzbildung). Wäre er automatisch, würde das die anderen Mapper dazu verleiten, bis zum Update nichts zu tun, weil es ja sowieso die Maschine macht.
Der vorgeschlagene Prozess ist ja nur halb-automatisch, jeder Mapper kann gerne jederzeit neue Gebäude importieren. Auch wenn es nur einzelne sind, ist ja eben nicht schwierig, man braucht z.B. keine Programmierkenntnisse.
OSM darf sich gerne an freigegebenen Datenquellen bedienen, es sollte aber ein selbstständiger Datensatz sein, der auch zwischen den großen Updates gepflegt wird. Eine rein automatische Pflege ist nicht förderlich für die Motivation der Mapper, Fehler zu korrigieren, denke ich.
Dieser halb-automatische Ansatz motiviert doch besonders, die Karte zu pflegen. Ohne grosse Hürden kann ich auch gleich mal ein ganzes Viertel mit hoher Präzision abdecken, was mir persönlich sonst viel zu mühselig wäre.
Mit einem Neubau ändert sich die EGID. Man könnte also mittels eines Diffs zur aktuellen Karte einfach nachschauen, wo sich etwas geändert hat.
Gruss, Johannes _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch