Hallo zusammen,
2015 wurde in Basel mit dem Import von Gebäudeumrissen und Adressen von den Geodaten des Kantons Basel-Stadt begonnen. Die Ergebnisse waren IMHO sehr überzeugend, aber leider wurde das Projekt nicht fertiggestellt und ist in der Zwischenzeit eingeschlafen.
Ich würde gern daran weitermachen, und habe mal mit einem Viertel angefangen, das sehr einfach ist, weil es bisher dort keinerlei Gebäudeumrisse gibt. Das OSM-File ist zum Review der Einfachheit halber angehängt.
Der Import ist beschrieben unter https://wiki.openstreetmap.org/wiki/DE:Switzerland:Basel-Stadt#Datenimport_v... ich habe diesen Abschnitt aktualisiert. Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten? Soll ich das ganze noch auf der imports-Liste ankündigen? Erscheint mir wenig sinnvoll für so lokale Daten auf einer internationalen Liste, und die Doku ist auch nur auf Deutsch vorhanden... ausserdem wurde das Projekt letztlich schon vor längerem begonnen.
Alles okay so? Dann würde ich das so hochladen und in der nächsten Zeit mit dem Hirzbrunnen-Quartier weitermachen, wo >1000 Häuser und Adressen fehlen: https://www.openstreetmap.org/#map=16/47.5661/7.6167
Gruss, Johannes
Hallo Johannes,
Am 2017-10-01 um 19:29 schrieb Johannes Singler:
Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten?
Nein, das ist schon so gut, wie du es vorgeschlagen hast. Wenn sich mehrere Leute ein Benutzerkonto teilen, ist nicht klar, wer einen schlechten Änderungssatz verbockt hat.
Soll ich das ganze noch auf der imports-Liste ankündigen? Erscheint mir wenig sinnvoll für so lokale Daten auf einer internationalen Liste, und die Doku ist auch nur auf Deutsch vorhanden... ausserdem wurde das Projekt letztlich schon vor längerem begonnen.
Wenn es dort schon einmal diskutiert worden ist, ist eine erneute Diskussion nicht mehr notwendig, wenn sich nichts seither geändert hat. Ansonsten rate ich persönlich ausdrücklich dazu, es zu diskutieren und auf Englisch zu dokumentieren. Gewisse Mapper aus der deutschsprachigen Community verlangen auch von den Amerikanern, mit jedem Gebäudeimport in einer Kleinstadt das Prozedere zu durchlaufen. Daher sollte die deutschsprachige Community auch selbst mit gutem Vorbild vorangehen. Es schadet nicht, wenn niemand noch einmal darüberschaut. (Es kann auch sein, dass du binnen zwei bis drei Wochen nichts hörst, was als "niemand hat etwas zu kritisieren" gewertet werden kann)
Viele Grüße
Michael
PS Wenn du aus Basel oder der Agglomeration kommst, schadet es nicht, das in der Importdiskussion zu erwähnen. Es ist gern gesehen (manche Leute werden andernfalls besonders kritisch), wenn Importe von den "Betroffenen", also denen, die in den nächsten Jahren damit leben müssen, ausgehen.
Hallo!
Am 02.10.2017 um 20:36 schrieb Michael Reichert:
Hallo Johannes,
Am 2017-10-01 um 19:29 schrieb Johannes Singler:
Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten?
Nein, das ist schon so gut, wie du es vorgeschlagen hast. Wenn sich mehrere Leute ein Benutzerkonto teilen, ist nicht klar, wer einen schlechten Änderungssatz verbockt hat.
Soll ich das ganze noch auf der imports-Liste ankündigen? Erscheint mir wenig sinnvoll für so lokale Daten auf einer internationalen Liste, und die Doku ist auch nur auf Deutsch vorhanden... ausserdem wurde das Projekt letztlich schon vor längerem begonnen.
Wenn es dort schon einmal diskutiert worden ist, ist eine erneute Diskussion nicht mehr notwendig, wenn sich nichts seither geändert hat.
Ich befürchte, dass es damals nicht wirklich zur Diskussion gestellt wurde. Es ist zwar hier gelistet https://wiki.openstreetmap.org/wiki/Import/Catalogue aber in den Imports-Mail-Archiven finde ich nichts dazu.
Ansonsten rate ich persönlich ausdrücklich dazu, es zu diskutieren und auf Englisch zu dokumentieren. Gewisse Mapper aus der deutschsprachigen Community verlangen auch von den Amerikanern, mit jedem Gebäudeimport in einer Kleinstadt das Prozedere zu durchlaufen. Daher sollte die deutschsprachige Community auch selbst mit gutem Vorbild vorangehen. Es schadet nicht, wenn niemand noch einmal darüberschaut. (Es kann auch sein, dass du binnen zwei bis drei Wochen nichts hörst, was als "niemand hat etwas zu kritisieren" gewertet werden kann)
Okay, dann werde ich mich mal an dem doch größeren Prozedere versuchen. Hier ein Entwurf der entsprechenden Wiki-Seite:
https://wiki.openstreetmap.org/wiki/Canton_Basel-Stadt_Building_and_Address_...
Kommentare dazu?
Gruss, Johannes
Hello,
Le 01. 10. 17 à 19:29, Johannes Singler a écrit :
Ich würde gern daran weitermachen
Thank you !
ich habe diesen Abschnitt aktualisiert. Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten?
If you work as "a team", same software, same process, you can share one account or have your own import login. if not, I think it is better you use your own login.
Soll ich das ganze noch auf der imports-Liste ankündigen?
it could be fair to send a message like "next part is done + location" so interested mappers are informed.
Alles okay so?
2 proposals: - put the source tag to the changeset instead of duplicating it on each object. - if a building has only one address, put the address on the building instead of putting it on the entrance.
Regards, Marc
Hi Marc!
Am 02.10.2017 um 23:06 schrieb marc marc:
Hello,
Le 01. 10. 17 à 19:29, Johannes Singler a écrit :
Ich würde gern daran weitermachen
Thank you !
ich habe diesen Abschnitt aktualisiert. Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten?
If you work as "a team", same software, same process, you can share one account or have your own import login. if not, I think it is better you use your own login.
I think the workflow should also serve future little improvements and updates (following real-world changes). And as nobody knows who will do those then, let's use separate accounts.
Alles okay so?
2 proposals:
- put the source tag to the changeset instead of duplicating it
on each object.
Okay, good point, we will do that then.
- if a building has only one address, put the address on the building
instead of putting it on the entrance.
I don't agree here. Why spoil that helpful information? Even knowing on what side of the building the entrance is, is helpful (as it determines the street). And it's even more consistent for buildings with multiple addresses, IMHO. And technically mapping the addresses to the buildings would be an additional step, right? I would like to keep the workflow as simple as possible and with JOSM as the only tool, so that it's even worth to import just a few buildings, if needed at some point in time in the future to fix a blind spot, or a newly added block.
Johannes
Fragen, die von meiner Seite in der Zwischenzeit aufgekommen sind:
* Macht es Sinn, die Adressen auf die Gebäudeumrisse zu verschieben? Wenn ja, muss man sie wohl auch verschmelzen, da sonst wohl Rundungsfehler darüber entscheiden, ob sie zum Gebäude gezählt wird, z. B. hier: http://qa.poole.ch/?zoom=17&lat=47.56069&lon=7.57077&layers=TTFFB0 Man könnte sie einfach an Ort und Stelle lassen. Ich habe noch keine Adresse gesehen, die nicht klar innerhalb des Gebäudes lag. * 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... * 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...
Gruss, Johannes
Am 01.10.2017 um 19:29 schrieb Johannes Singler:
Hallo zusammen,
2015 wurde in Basel mit dem Import von Gebäudeumrissen und Adressen von den Geodaten des Kantons Basel-Stadt begonnen. Die Ergebnisse waren IMHO sehr überzeugend, aber leider wurde das Projekt nicht fertiggestellt und ist in der Zwischenzeit eingeschlafen.
Ich würde gern daran weitermachen, und habe mal mit einem Viertel angefangen, das sehr einfach ist, weil es bisher dort keinerlei Gebäudeumrisse gibt. Das OSM-File ist zum Review der Einfachheit halber angehängt.
Der Import ist beschrieben unter https://wiki.openstreetmap.org/wiki/DE:Switzerland:Basel-Stadt#Datenimport_v...
ich habe diesen Abschnitt aktualisiert. Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten? Soll ich das ganze noch auf der imports-Liste ankündigen? Erscheint mir wenig sinnvoll für so lokale Daten auf einer internationalen Liste, und die Doku ist auch nur auf Deutsch vorhanden... ausserdem wurde das Projekt letztlich schon vor längerem begonnen.
Alles okay so? Dann würde ich das so hochladen und in der nächsten Zeit mit dem Hirzbrunnen-Quartier weitermachen, wo >1000 Häuser und Adressen fehlen: https://www.openstreetmap.org/#map=16/47.5661/7.6167
Gruss, Johannes
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
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.
- 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:
1. Es wird ein Update geben (und sie pflegen es ein). 2. Die Mapper wissen, wie man korrekt mit dem Tag umgeht. 2.a Niemand verändert das GWR-EGID-Tag. In fünf Jahren kann man sich blind darauf verlassen. 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.
Es ist IMHO sinnvoller, beim Import eines Updates die Differenz zwischen den alten und neuen amtlichen Daten zu bilden und zu prüfen, 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. 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.
Viele Grüße
Michael
[1] basiert auf Gejammere von Datennutzern, weil sie in Muttenz und Gebäude vermisst haben.
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
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
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
Hallo Johannes
Habe mir die wiki Seite angeschaut. Dein Beispiel http://www.jsingler.de/osm/Landauerhof.osm hat die Eingänge noch nicht auf den Umrissen. Ich finde es gut dass es Eingänge sind, aber sie sollten Teil der Umrisse sein. (Neuen node auf dem Umriss erstellen, neuen node und Eingang markieren und mit 'M' verschmelzen)
Bei den changesed tags sollte auch ein description=https://wiki.openstreetmap.org/wiki/Canton_Basel-Stadt_Building_and_Address_... Tag auf die Wiki Seite verweisen.
Der Rest sieht gut aus. Danke Michael
On 12/10/17 22:01, Johannes Singler wrote:
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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo!
Am 14.10.2017 um 12:36 schrieb michael spreng:
Hallo Johannes
Habe mir die wiki Seite angeschaut. Dein Beispiel http://www.jsingler.de/osm/Landauerhof.osm hat die Eingänge noch nicht auf den Umrissen. Ich finde es gut dass es Eingänge sind, aber sie sollten Teil der Umrisse sein. (Neuen node auf dem Umriss erstellen, neuen node und Eingang markieren und mit 'M' verschmelzen)
Wäre mir im Prinzip auch lieber, und das war auch der ursprüngliche Plan. Aber "Neuen Node auf dem Umriss erstellen" ist nicht automatisch, und schon gar nicht exakt reproduzierbar. "Move Node onto Way" in JOSM ist hilfreich, aber es hängt von der aktuellen Zoomstufe ab, ob es was und was es genau macht. Naja, ich befürchte, wir müssen es machen, weil es in der Beschreibung von entrance gefordert wird, daher habe ich den entsprechenden Schritt eingefügt. Ergebnisse sind auch aktualisiert.
Bei den changesed tags sollte auch ein description=https://wiki.openstreetmap.org/wiki/Canton_Basel-Stadt_Building_and_Address_... Tag auf die Wiki Seite verweisen.
Habe ich eingefügt.
Der Rest sieht gut aus. Danke Michael
Danke fürs Kommentieren, Johannes
On 12/10/17 22:01, Johannes Singler wrote:
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
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
-
Johannes Singler -
marc marc -
Michael Reichert -
michael spreng