I have not been able to contribute much recently but I remain a regular user of OSM maps. Information sharing in the community now has multiple channels and I may have missed a crucial discussion - if so, please forgive me and re-direct me.
Today I was looking for information about a place in Western Australia and was surprised that I could not find the postcode as part of the information provided in OSM. Subsequently I looked a some familiar places in New South Wales and again found information, previously available, now gone. In regard to the Sydney suburb of Westmead, I saw the comment “NSW post codes are now all in boundary=postal_code Baulkham Hills (4RRG7X4F+M2)” but I am uncertain what this means or how one uses this information to find postcode.
I do recall that there are, in New South Wales, multiple places with the same name and that their respective postcodes provided an easy way to differentiate such places (for example Kingswood, Long Plain).
I feel a little sad that OSM seems a little less useful.
Taginfo Australia does not shows things are removed but just mot mapped that frequently.
On the other hand there are about 4 million buildings so if random quarter has a addr:postcode it should work probably reasonably but that probably not the case, likely some area’s have postcodes (about a quarter) and others not.
The changeset you’re referring to is part of a series of changesets that removed the postal_code=* tag from local administrative boundaries. As the changeset comment says, the postcode has moved to a boundary=postal_code relation that overlaps Westmead.
If you’re browsing the website manually, you can query for this postal code boundary. Right-click on the map, choose Query Features, and look for a “Postal Code” entry under the “Enclosing features” section of the sidebar. If you’re using a different tool to explore the data, it would help to know which one and what your use case might be.
Yes this is what happened. While it’s nice to have proper boundary=postal_code relations for each postcode, I think we should still retain postal_code=* on the existing admin_level=9boundary=administrative relations, in addition to the new boundary=postal_code relations.
To determine the postcode of a suburb/locality now requires a complex spatial operation, whereas if we include the postal_code=* tag as before it’s a clear tag lookup.
Certainly the wiki is not clear about this and just says that (“can also” could be read as both in addition to, or instead of).
postal_code=* is still valid and widely used, but you can also use boundary=postal_code on a way or on a relation
What do other’s think?
Retain the postal_code=* tag on admin_level=9 suburb/locality relations
Omit the postal_code=* tag on admin_level=9 suburb/locality relations
other
0voters
ping @TheSwavu in case you haven’t seen this thread yet.
Previously you had to do this because there was a mix of postal_code on the admin level 9 or in postal_code boundaries. That hasn’t changed. All that has happened is that it’s now clearer where to find them.
Do you have a use case that requires the postal_code to be on the admin boundary?
To answer @cleary question as far as I can tell the current tooling works just as well with postal_code boundaries. For example Nominatim can find:
Also works fine in Overpass, so if you want to find all the highway=* in Back Creek NSW 2390 then this will work.
I think that given the fact you have not been able to make a list of bounded localities with their postcodes by just dumping the postal_code on the admin level 9 for at least 5 years, this is not something that people commonly want to do. I also think that if you have a reason you want them to be duplicated you should say why, rather than having a popularity competition. If people want them on the admin boundary as well, then they can just be copied down. It’ll mean I’ll have to set up my QA workflow to check two sources of information and to keep them consistent, which is the primary reason I chose one of the places to keep them.
Now you need to fetch the full Mosman geometry, fetch the full postal code geometries, spatial intersects the postal_code boundaries, find all that intersect, hope that there’s no slivers of geometry getting caught.
Answering other just because I’m not from Australia but France.
In France the postal_code=* tag on admin_level= have been kept. Happy to see that it has been done that way (in France usually admin_level=8, sometimes admin_level=9).
I have read that before and I am not sure how many versions ago this applied. Based on this comment from Sarah in 2018, postal_code boundaries are used in preference to the calculated centroids. This lines up with the database schema description.
OK, let’s be clear here: not one single bit of data from removed from the database. It is now just in a different location.
I’m working on the same topic here in Austria (sadly, no kangaroos in the wild).
I believe that Nominatim only uses the calculated post code (distance to nearest post code centroid derived from point cloud) as a fallback if no other post code can be found for the feature anywhere near. The search also includes any surrounding boundaries with postal_code=* up to country level.
I remember seeing this in a discussion, but can’t find it at the moment. See also Nominatim database layout, where it states that the exact geometry is only kept for post code areas.
Regardless though, as a data consumer like Nominatim or anyone else, you still need to do a fair bit of processing to determine those postcodes per suburb/locality. I can understand the desire to just store this information in one place, and not duplicate it, and I’m not saying we must retain it on the suburb/locality, but just it was nice to have it there too as that made it easier for data consumers to just check the tag value.
Nominatim can work with both postcode areas and postcodes on admin boundaries when calculating the postcode for an OSM object.
Postcode areas get you more precise results when searching for a postcode. When an area is present, then that area is returned. If the postcode is only on the boundary, then Nominatim just returns the centroid, not the precise area.
Something that really surprised me when I started working for an org that has some big postcode data lookup requirements is that there’s no standard mapping of postcodes to suburbs or even states in Australia. E.g. 2042 encompasses both the suburbs of Newtown and Enmore, and 0871 spans three states - SA, NT, and WA.
So from a “principal of least surprise” perspective of the lay person editing OSM, I think it would be best if areas/relations such as suburbs were never tagged with postcodes, lest people think that is the right thing to do in general. Instead, `boundary=postal_code` seems like that is the way to go, but I’m not sure why that would need to be relation (to avoid redundant data maybe?).
If existing tools don’t make this easy to discover however, then surely the tools should be fixed, rather than the data muddied?
If the postcode is only on a boundary=administrative why only use the centroid, and not the full area? I mean if we have complete boundary=postal_code relations now it shouldn’t affect Nominatim results here, but if that wasn’t the case I’d expect the whole boundary=administrative area to be used not just a centroid.
Yes. I’m not saying to remove the boundary=postal_code relations, it’s great we have them now and I very much thank @TheSwavu for adding them.
In the case of 2042 encompassing both the suburbs of Newtown and Enmore, both those suburbs could have postal_code=2042 on them.
To rephase how I see it, it’s like we removed bridge=yes from the highway=* ways that pass over a man_made=bridge area. Sure data consumers could do a spatial intersects to derive the bridge=yes but it makes it a lot easier for data consumers if we add it, and it means those roads are always marked as bridge regardless of if the man_made=bridge area is moved.
