Some time earlier this year when we were working on this years lot of municipality mergers I promised that I would produce some kind of analysis of the postal code tagging since it was likely that the merger work had broken it. Since early May the new release of the postal code boundaries is available and I've done some initial work see http://qa.poole.ch/ch-plz/.
While the information is useful (disambiguation of places with the same names for example) I don't believe importing* the polygons into OSM makes any sense at all, they are at the same time too close and too different from the administrative boundaries making maintenance a nightmare and just asking for unintentional damage. I would think that the best solution would be to add the postal code to the house addresses in places where we have multiple post codes in use.
Any other opinions?
Simon
* while the data is freely usable, if we do decide to import we would need to clarify the attribution requirements first.
Hi Simon
I think also that importing the polygons does'nt make sense for OSM.
What's wortwhile is to offer is an enhanced dataset for the PLZ data, since the data sources (PLZO_OS) at the original place cadastre.ch are not very accessible (I'm missing a shapefile/Spatialite which contains PLZ4, place name and polygon).
nightmare and just asking for unintentional damage. I would think that the best solution would be to add the postal code to the house addresses in places where we have multiple post codes in use.
The PLZ boundaries define concisely (meaning at building level) where the boundaries are. What do mean by "places where we have multiple post codes in use"?
Yours, Stefan
2013/5/26 Simon Poole simon@poole.ch:
Some time earlier this year when we were working on this years lot of municipality mergers I promised that I would produce some kind of analysis of the postal code tagging since it was likely that the merger work had broken it. Since early May the new release of the postal code boundaries is available and I've done some initial work see http://qa.poole.ch/ch-plz/.
While the information is useful (disambiguation of places with the same names for example) I don't believe importing* the polygons into OSM makes any sense at all, they are at the same time too close and too different from the administrative boundaries making maintenance a nightmare and just asking for unintentional damage. I would think that the best solution would be to add the postal code to the house addresses in places where we have multiple post codes in use.
Any other opinions?
Simon
- while the data is freely usable, if we do decide to import we would
need to clarify the attribution requirements first.
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Am 26.05.2013 15:17, schrieb Stefan Keller:
... e we have multiple post codes in use. The PLZ boundaries define concisely (meaning at building level) where the boundaries are. What do mean by "places where we have multiple post codes in use"?
There are essentially two to three disjoint concepts for human settlements in use in Switzerland: muinicipalities (Gemeinden, you could argue that these are not really places, but in practice they are used as such), places (Orte) and postal places (Ortschaften). There is no one to one relationship betweens these, for example on average there are 1.5 places to a municipality (increasing) and a majority cover more than one postal code area. The example I give on the website is a nice example where part of the territory of Spreitenbach is in the postal code area of Dietikon and parts of Dietikon are in the area of Schlieren which in turn has areas in ....
Simon
PS: for the reasons above, I'm not really convinced that assigning names to the postal places is a useful concept
Am 26.05.2013 16:54, schrieb Simon Poole:
.... PS: for the reasons above, I'm not really convinced that assigning names to the postal places is a useful concept
Just a further note, the last revision of the data last year contained the "names" and I still have it available if necessary.
-
Simon Poole -
Stefan Keller