Am 26.03.2023 um 21:34 schrieb Lukas Toggenburger:
I've updated the GWR extracts
Thanks, Simon!
On a related note, Jonas (loremo) suggested at one point in time that we should include one of the GWR ids with the data for referencing updates/QA.
I once learned that it is frowned upon to include foreign keys to OSM, but did not agree with the reasoning. Would be fine with me...
I was just pointing out that Jonas had suggested this. As a tendency I would argue that given that the addresses themselves are nearly always an unique key it isn't really necessary for update purposes.
There seem to be two possibilities how we could do that:
- EGID + EDID (Eidgenössischer Gebäudeidentifikator + Eidgenössischer
Eingangsidentifikator)
or
- EGAID (Eidgenössischer Gebäudeadressidentifikator)
The former would seem to be more useful as it allows to determine if the entrances belong to the same building. Any comments? Tagging suggestion?
Could you explain a bit more? What is their purpose? How do they look like? When do they change? Etc. I guess, some background knowledge would be necessary in order to come to a well-founded conclusion.
They are all just integers, the entrance number is zero for buildings with just one entrance. I don't believe any of them have internal structure, they are just allocated sequentially. Entrance data:
EGID EDID EGAID DEINR ESID STRNAME STRNAMK STRINDX STRSP STROFFIZIEL DPLZ4 DPLZZ DPLZNAME DKODE DKODN DOFFADR DEXPDAT 1 0 100000334 20 10000533 Grossholzerstrasse Grossholzerstr. Gro 9901 1 8910 0 Affoltern am Albis 2676465.141 1235849.103 1 2023-03-21
2 0 100000335 1 10000537 Im Feld Im Feld Fel 9901 1 8910 0 Affoltern am Albis 2676541.16 1235979.043 0 2023-03-21 .....
and the building data:
EGID GDEKT GGDENR GGDENAME EGRID LGBKR LPARZ LPARZSX LTYP GEBNR GBEZ GKODE GKODN GKSCE GSTAT GKAT GKLAS GBAUJ GBAUM GBAUP GABBJ GAREA GVOL GVOLNORM GVOLSCE G ASTW GANZWHG GAZZI GSCHUTZR GEBF GWAERZH1 GENH1 GWAERSCEH1 GWAERDATH1 GWAERZH2 GENH2 GWAERSCEH2 GWAERDATH2 GWAERZW1 GENW1 GWAERSCEW1 GWAERDATW1 GWAERZW2 GENW2 GWAERSCEW2 GWAERDATW2 GEXPDAT 11513432 ZH 1 Aeugst am Albis CH540120777857 0 1573 1199 2679647.268 1237500.347 901 1004 1020 1121 2000 8019 166 32 7430 7530 860 2002-09-05 7630 7530 860 2002-09-05 2023-03-21 11513433 ZH 1 Aeugst am Albis CH587820017717 0 1543 1198 2680635.9 1236936.229 901 1004 1020 1110 2000 8019 90 21 7430 7530 860 2002-09-05 7650 7560 860 2002-09-05 2023-03-21 .....
Attribute documentation see https://dam-api.bfs.admin.ch/hub/api/dam/assets/7008785/master
Currently I'm just using the building data to get the municipality id GGDENR, which is, on the topic of foreign keys is what we maintain on the municipality boundaries (slightly misnamed for historical reasons).
Simon
Further because of the changes it would be possible to generate building type and level count information, it is a bit unclear how well this would map to OSM tags, but is somebody is interested we could look in to this.
I am generally interested. However, to me it's still unclear, even if we get the tagging and pre-processing all sorted out, how would we bring this data into OSM? I.e. what tools would we use and how much effort would this take? Would this effort better be spent on importing addresses or could we get both in one go?
Best regards
Lukas