For some time Mapbox has kindly hosted a postcode points layer for me. Each year I have entered this layer into their community programme and they have accepted, thus giving me substantial reduction on running costs. I thank them for their support over the last few years.
I have just refreshed the data to use NSUL postcode data from March 2026. As part of this, I have taken the opportunity to refresh the process I have in place and to migrate fully to vector tiles. As vector tiles are small I am moving them from Mapbox to OSM UK servers.
The old layer:
I will be removing this soon. Please move to the new layer (see below).
To use the new layer:
JOSM
Under “Imagery preferences…” add an MVT layer that points to the style JSON. It should look like this: mvt:https://tiles.osmuk.org/nsul-postcodes/nsul-postcode-points-style.json. The tiles should load across multiple zoom levels but z14 is the only tile it actually serves to you. I recommend using the layer when zoomed in so as to not load too much data and slow JOSM down too much.
ID Editor
Unfortunately, as far as I know, ID does not support styling of Vector point layers. I am hoping in time that this layer acts as a case study as to why ID should support them. In the mean time use in ID is no longer an option. (I didn’t look like any ID editors were using the old Mapbox hosted layer so hopefully not a problem).
As for the data itself, I have created the vector tiles so that all data is retained. It is possible for multiple postcodes to be at exactly the same location. In this case they are concatenated together or it simply states “More than 3 postcodes” when concatenation would result in a very long text string.
I hope I have the balance right. Feedback welcome but no promises as my free time to work on these things is low.
This is great, thank you very much for your work on it
The dots for the actual points, as well as the fact that it’s a vector layer allowing to zoom in further and disambiguate the points is very helpful, and obviously updated NSUL data is useful too
At the top of the Imagery dropdown menu there is a function to “Re-order imagery layers” (`)[1]. If you have it in the toolbar the tooltip says that it “Re-orders non-overlay imagery layers”. In effect it takes the uppermost layer that isn’t an overlay an puts it at the bottom of the list of imagery so you can cycle through them all very quickly. It’s very useful for figuring out what’s going on with weirdly shaped buildings in blurry imagery.
I have just updated this to use the latest (June 2026) NSUL data. The tiles are also now compressed so that they take up less space on our server. You shouldn’t have to do anything or notice this change but if you do experience issues please let me know.
P.S. As this is on our staging server, it could be offline if we are working on something.
Does the data contain addresses as well or just rough locations of postcodes? Would be interested in a bot for adding postcodes to addresses as it’s often a hassle to work out what the postcode for an address is.
To save you the hassle of downloading a huge data file just for the user guide, please see attached. To quote:
The National Statistics UPRN Lookup (NSUL) relates the Unique Property Reference Number (UPRN) for each GB address to a range of current statutory administrative, electoral, health and other statistical geographies
So it’s basically a set of CSVs (11 in total: 1 for Scotland, 1 for Wales, 9 for England’s regions) containing all UPRNs and data that has been linked to them. These are mostly admin, electoral and health and policing regions (none of which I use) but they have also assigned the postcode to each UPRN. No other address data is assigned.
I have a JOSM tool to add UPRNs, and then as a result postcodes and potentially street names (after checking for possible issues, such as multiple streets for a postcode), and postal towns. It does still require a check that the results are sensible, and I don’t think it would be possible to avoid this check with the current range of data. I have some map css styles to help with this.
It would need some polishing, but I’d ultimately like to make this available to anyone.
If this is something people are interested in, I can move it up the “to-do” list.
I haven’t been importing anything while I’ve been clearing up the mess Uber made of London’s sidewalks, but I’ll be resuming soon. I may need to make a minor tweak to change from ONSUD to NSUL, as the former hasn’t been updated for ages. At some point I’m also planning to make the Codeberg repository public.
You need to be a little bit careful using postcodes from NSUL. They take all the UPRNs (incuding historic ones that are no longer current, and one’s that don’t have proper addresses) and assign a postcode to each one using an algorithm. If the UPRN has an address with a postcode that is currently in use, then that postcode is returned. If not, then a closest postcode is usually used instead.
This means that historic UPRNs can maintain a still-in-use postcode that is no longer correct for that location, and historic and very new UPRNs can be assigned postcodes that are not correct at all for that location. You can also often get groups of UPRNs over the same building that have different postcodes, so you need to work out which one(s) correspond to the (current) properties/users of the building.
That said, in the vast majority of cases everything is fine, and for each property, there’s a single UPRN for it and it has the correct postcode in NSUL. But any sort of automated imports need to be aware of the issues above.
The other thing that adding postcodes can help with is getting the street names in addresses. Almost always a single postcode unit only contains addresses from a single street. So being able to see all UPRNs with that postcode often allows you to deduce the street name for each address. This can be useful with houses without numbers that are on corners of streets, where you’d otherwise might not be sure which street it was formally on.
Those issues also apply to ONSUD and I believe were covered in the initial discussion of the import at the end of last year. As the import only affects properties where there is only one UPRN in the containing Land Registry INSPIRE polygon, I’m reasonably confident that the problem of disused UPRNs intentionally being kept in the “open” data isn’t a significant one here.
It works best in areas which have a lot of houses which haven’t been split into flats, but even in areas with a large number of HMOs, there usually enough to manually match addr:postcode → addr:street (we could possibly do more in this respect with OS Open USRN, OS Open Roads and OS Open Linked Identifiers). For me, this is a much higher priority than trying to capture every UPRN.
I find you can identify the correct UPRN in these cases by looking at the links from UPRNs to USRNs. For example, the area below has been demolished and then rebuilt with a new street layout. You can see the old layout in the blue dots.
When you’ve been reading the docs for this data have you seen any indication of how much delay there typically is between something getting built and ending up in the data?
I did a partial survey in late May for a development that an anonymous note claims people started moving into in December, but they don’t seem to have points yet even though something seems to be showing on the mathmos.net tool.[1]
As it turns out these don’t seem to have good alignment with the OS OpenMap Local (April 2026) centrelines for the few roads they have mapped so I won’t be using them to realign my address nodes after all, but the lag is still useful information. ↩︎
I didn’t look but I have uploaded the documentation (PDF) in my earlier comment if you want to check. You might also find by looking at what is said on the source website (ONS Open Geography Portal)
