whosonfirst-data
whosonfirst-data copied to clipboard
UK postcode districts
People will often refer to an area by the prefix of the postcode. So someone in London might refer to E9, to mean the area bounded by the postcodes beginning with E9. Postcode areas are in common use. Lots of people search using them on property and job sites, they appear in job descriptions, and a company might say they serve 'E5, E9, E8', for example.
In the UK, these are technically called postcode districts.
We have all the postcodes in WOF, but not the districts. I've taken the geometries from Wikipedia, via @missinglink's exporter. They're licensed under the same conditions as the existing GB postcodes, because they're derived from the same data. We're still missing the BT
areas for Northern Ireland, because they're under a more restrictive licence.
I've invented a new placetype postalregion
. That feels intuitively correct as nothing else quite fits, but I'm open to input here. In the hierarchy this would optionally sit between postalcode
and anything that can parent a postalcode
.
I've parented them by the United Kingdom country, not the England/Wales/Scotland macroregions, because it's possible for a postalregion
to span across macroregions, although the vast majority don't.
Looking for feedback from @thisisaaronland re: the invention of a new placetype, and @missinglink + @stepps00 for everything else.
Interesting idea, some questions come to mind:
- would this work in any other countries you're aware of?
- do
postalregion
features 'nest'? - is there a metadata relationship between the
region
and the childpostcode
record(s)?
Where would postalregion
fit in the hierarchy? I guess it could have a range of parent types, but if it only applies to the UK then maybe it could be more strict? [edit] sorry I re-read what you said and you covered this.
Great idea!
FYI: There's some related "new placetype" discussion between @thisisaaronland and myself in https://github.com/whosonfirst-data/whosonfirst-data/issues/2137.
While the placetype_local
name for this in the UK is postcode districts I can see the same thing being used in the USA and other countries, especially commonwealth related countries.
Let's be cautious about importing Wikipedia data because of the ShareAlike terms. Is the same data available on Wikidata (which has better CC-BY terms)?
I’m travelling this week and on mobile, so excuse brevity!
For the UK, it could be possible for these to nest. eg. HP would be a region that encompassed HP15, then HP15 1, then HP15 1AA. For my use case, I don’t think nesting these is necessary - referring to the postcode district is much more common than the postcode area, but it’s not unheard of.
If we merged this or something similar, I would rework the GB postalcodes repo so each postalcode was parented by the correct postalregion.
Re: licensing, from a glance it looks like there might be KML polygons available on Wikidata for the postcode areas: https://m.wikidata.org/wiki/Q5635760. I couldn’t spot district level polygons. But if we wanted to build these for multiple levels: area, district, subdistrict and sector, I’d probably go back to the source data and build polygons using voronoi for each level.
+1 for built polygons from Voroni base layer.
I think it's OK to do just the regions you originally proposed now, as long as the data architecture allows rest to be filled in as needed later.
In Canada these are referred to as "forward sorting areas", specifically the first three characters in a postal code.
https://github.com/whosonfirst-data/whosonfirst-data-postalcode-ca
For example, T6R
:
https://spelunker.whosonfirst.org/id/504804689/
And T6R 2R3
:
https://spelunker.whosonfirst.org/id/554865797/
Stats Canada publishes openly licensed data for the FSAs and the geometries for the postal codes were derived using the centroid of their FSA.
(@tomtaylor These are all likely out of date now so it would be worth having a conversation about whether any of the tooling you've written for dealing with GB updating postal codes can be used to deal with "another country".)
In both cases, the FSA and the postal code are parented by the locality of Edmonton. This was likely a decision born of expediency (c. 2016) since at the time postal codes were not seen as a priority relative to other things and it wasn't clear whether FSAs (or postal regions) were specific to Canada or generally applicable.
My hunch is that they are generally applicable so I guess I would be fine with a single, non-nested postal_region
place type (considered to be "optional" in the place type nomenclature). That would enable semantics for the basic concept of FSAs at a global level and if a specific project really needs to get in to the regional weeds (nested postal regions in the UK or the 3-4 part numeric identifiers for addresses in Japan whose name I've forgotten) then those might be better addressed in a project-specific placetype definition as @nvkelso mentioned in #2137
Thanks all. I went back to the drawing board and rebuilt the district geometries using the process outlined here: https://github.com/mhl/postcodes-mapit/
This produced contiguous polygons across the UK for all the postcode districts that can be licensed under the UK Open Government License 3.0, because they're derived from NSUL.
(It's also produced area and sector geometries, but these are less important although might be a good fit for a separate repo in the future.)
There's a few little oddities in them, where a postcode pops up outside of the main body, typically for major venues/businesses, but they're pretty good.
I've added a source for NSUL here, which needs a little tweak and is then ready to merge: https://github.com/whosonfirst/whosonfirst-sources/pull/205
FYI I'm going to merge this soon. I'm then going to update the postalcode repo with the latest GB postcodes. And then attach the postalcodes to the postalregions in a new hierarchy element.