Hi,
we at Geofabrik added a postcode view to our OSM Inspector today. It shows the coverage of postal code boundary polygons and looks for potential mapping mistakes.
It covers the whole world although some countries might not have postal codes or have a postal code system which cannot be modelled using polygons.
See our blog entry and the wiki page for details. The source code can be found on Codeberg.
Best regards
Michael
Hi, thanks!
What are the specific differences between the old version and this new release?
Best regards
Michael - wildmaps
| Feature | old version | new version |
|---|---|---|
| has postcode view |  |
 |
Nice tool, thanks. One question (don’t know if bug or feature): On overlapping polygons, both entries (eg. Valid postcode poly and Intersecting postcode poly) link to the same (the boundary=postal_code) polygon. I would expect to have a link to the intersecting polygon on the respective entry as this would make fixing issues easier.
Currently I need to copy&paste the other_idvalue and manually paste it.
Thanks
If you click on the map, a query will be sent for all layers. OSM Inspector is not only a validation tool but it is intended to look into details of OSM mapping which are not covered by other applications.
Unfortunately, this is a limitation of the current frontend. There is no quick fix. If you use JOSM, you can press Ctrl+Shift+O to download a single OSM object (with or without members). The ID field will be filled automatically from your clipboard if it is a valid integer.
Hi, do I understand correctly that this view does not check for inconsistent addr:postcodes inside the postcode relations?
Yes, OSMI Postcodes view does not check if addr:postcode=* matches postal_code=* on a boundary relation.
Would it be possible to exclude data from Switzerland from the view?
With very few exceptions it is rubbish and displaying it as is will just motivate people to make things worse. Currently it isn’t really possible to model Swiss post code polygons in a fashion that is supported by OSM tools, so even the small number that are “in principle correct” are not actually useful.
That seems to be the wrong way to go about it. The bad data doesn’t go away just because OSMI doesn’t show it. If postcode polygons are not useful for Switzerland, then the existing ones should be deleted and you should add a note in the wiki to say that they are not applicable for your country.
In an ideal world, yes. In the real world people will see the empty bits and try to colour things in and there is literally no way to avoid the positive feedback to add something broken outside of not displaying it in the first place.
PS: most of the polygons are actually municipality boundaries that have a postal_code stuck on them, which in general is wrong, but people still think that is the way it should be (there are nearly 6’000 post code polygons, but just over 2’000 municipalities).
One challenge is that the representation on a map of a “Valid postcode polygons” doesn’t mean that it is in any way correct. An example in the UK is CF around Cardiff. In that example someone’s just stuck postal_code=CF on that (in a sense not wrong - every non-special geographical postcode probably is CF), but a glance outside that admin area shows that CF postcodes are very much also a thing.
Essentially, UK postcodes just do not work like this.
Sounds like the inspector is pretty good at highlighting incorrect tagging of postcodes on areas…
After two postings pointing out that it is pretty bad at exactly that.
No, I think highlighting that there are postcode areas mapped where there should be none is quite good. If you believe that postcodes are not areas in your region, then your goal will be to simply have a blank map on the postcode view.
I didn’t know that was a question of religion. In the UK they are not, in Switzerland they are, but can’t be modelled properly by current OSM tagging.
Let’s tone down the sarcasm a notch, and assume good faith on the part of everybody.
Whether postcode areas make sense, whether postcodes can go onto the admin boundary relations or whether they only should be added in form of addr:postcode, is something that needs to be decided differently for every country. Nobody claims that there is a single solution for the entire world. It’s exactly why we have different forms of tagging postcodes.
The OSMI view makes visible where postcode areas and postcodes on admin areas exist. That is no statement about whether that is correct tagging or not for a country, it just shows what is in the database. And that is a good thing to do because postcode tagging is really in a bad state in OSM and can profit from more visibility.
What the Swiss community (as well as every other community) should be doing based on this, is have a look at the data that exists and at the local situation and make an informed decision of which kind of postcode tagging is valid for your country. If postcodes on admin areas are wrong in Switzerland and postcode area modelling is not possible, then the solution for you is likely the addr:postcode-only tagging. But what would I know, it’s really for the Swiss community to discuss.
Now, if the conclusion in the community was a no-area policy and that was also documented somewhere, then I could imagine that you could ask the kind people from Geofabrik if they could mark postcode areas in Switzerland in their OSMI view as errors so that people can start cleaning up the data. That would make so much more sense than coming here and demanding that OSMI simply hides all the bad data. The data you see in OSMI is being used by data consumers after all. Hiding it won’t change anything.
That is what we have been doing (and yes it has been discussed many times).
Hi,
OSM Inspector aims to show all postcode polygons which would be picked up and used by data consumers. Currently it renders them on a layer called “valid postcode polygons” and does not care if polygons make sense in that country/postcode system or not.
A postcode polygon is considered valid if all three conditions are true:
postal_code=* and either boundary=administrative or boundary=postal_code.It seems that using the word “valid” here could lead to the misunderstanding that the polygon is not just technically valid but also somehow “correct” in the context of usual postcode mapping in the respective country. It is probably best if we just drop the word, and just call them “postcode polygons” without “valid”.
For us as the makers of a QA tool it would be good if the community were to document their approach to post code tagging somewhere (specifically, if post code boundary mapping is desirable in that country or not). Perhaps Key:postal_code would be a good place for this (ideally also linking to any public discussion that resulted in the decision).
We could then add a layer “polygons with warnings” rendering postcode polygons in countries
where they are not wanted by the community. With that change, postcode polygons would either appear on the valid or the warnings layer.
We would like to make the OSMI postcode view work for everyone and we’re happy to tweak it to the needs of the community, or accept your pull requests on Codeberg.
Best regards
Michael
CY certainly extends a lot further north into the valleys. My grandmother had a CF postcode in the Merthyr valley.
SY (Shrewsbury) extends to the Welsh coast.
Interestingly, it works on Swiss municipalities, if one just enumerates all applicable postcodes.