The aim of this import process is to increase the number of UK postcodes recorded in OSM quickly and accurately. Very large numbers of UPRNs have been added to OSM in the last year, but I am not aware of any previously documented or discussed import process.
The import will add UK postcodes (addr:postcode, or postal_code for buildings which are not addressable in a meaningful sense) and Unique Property Reference Numbers (`ref:GB:uprn`) to buildings and other addressable features within England and Wales, UK.
Postcodes and UPRNs will only be added to features which meet the following criteria:
The feature intersects a Land Registry INSPIRE polygon and it is well aligned (at least 95% of the feature is within the INSPIRE polygon
There is only one UPRN which intersects the feature. If there are multiple UPRNs, there is no way compatible with OSM’s licence to determine which belongs to the whole feature and which to units or flats within.
Uploads will initially be limited to 100 modified features or 10 distinct postcodes, whichever is reached first. These may be increased later, but only after consultation with the community.
An earlier attempt to do something similar in 2013, ONS Postcode Import was not deemed suitable for import as “The planned import could have assigned incorrect postcodes if buildings were not mapped correctly or on mixed use buildings (e.g. residential over commercial).” This preceded the release of both the Land Registry INSPIRE polygons and OS Open UPRN (2022), which are used here to prevent this issue arising.
Can you add some more details, with examples, of what will actually happen.
Give examples of a “feature intersects a Land Registry INSPIRE polygon”
I assume you mean an osm area (eg building=*)? I believe the data is point data (node), so why attach to an area. Address and postcode data is commonly present on nodes.
What checks do you carry out to check if the postcode is already present on a node, and avoid replicated? How do you deal with areas where addresses are added to nodes, rather than buildings?.
Above reads a bit negative, but thanks for trying to do something
I’ve been adding a UPRNs (and latterly, some address details) using a method that’s quite close to this, but relies on some more manual steps. Your method might be able to eliminate some of these though potentially missing some potential candidates for UPRNs in the process.
A few things that I’ve found, that you may well be aware of, which may be helpful:
Which objects are assigned a UPRN varies quite significantly between areas. For example, some areas assign a UPRN to individual garages in a block, then to the block of garages itself. Others don’t assign them to garages at all.
Some items have two UPRNs at different locations, this seems to often be the case for small local distribution substations, with one in the centre and one at a corner.
Buildings with multiple flats tend to have a set of UPRNs at the same point. I have added these all where they have the same location and postcode, and where they can fit into the attribute.
There are quite of lot of UPRNs that I’ve not been able to determine what they relate to, but which happen to fall within a building. Normally this causes there to be more than one UPRN to be inside that object, and the one that relates to the building can be determined either by its geometry (normally in the centre of the building, or parallel to others in street), or by its sequence relative to neighbouring buildings.
Historic UPRNs are often included. It is often possible to determine the current one by the sequence and geometry. Quite a few demolished and rebuilt streets have this issue.
There are a lot of blocks of terraces that are almost perfectly aligned to cadastral parcels, but out by one or two houses.
I have a slightly different approach to tooling, and I’ve been meaning to tidy it up and publish it. I’m happy to do that if it would be helpful.
I load this heatmap into JOSM as a tile layer to check for alignment, then have some scripts in JOSM to pull UPRNs from a web service, and applying them to objects after various checks. After this I check the alignment with a mapcss style that highlights UPRN and address details, and adjust any that don’t appear to be correct. At this stage I often tidy up building geometries and split buildings if needed.
I plan on turning these script into a JOSM plugin at some point, as it’s essentially written as one already, though haven’t done that yet.
Houses tend not to be mapped as nodes and this is where we can probably capture a significant number of postcodes and (outside the import process) associate them with streets. There are also addressable features under shop, amenity, leisure and tourism which *may* be mapped as polygons. Addresses associated with nodes can’t be associated with UPRNs or postcodes by this method.
That’s easy to do: check whether either the INSPIRE polygon or building contains a node with any addr tags and exclude them from the import. I’ll update my osm2pgsql.lua file and SQL post-processing accordingly tomorrow [EDIT: now done]. In reality, this isn’t likely to be a big problem, as a block of flats with the address tagged on the entrance(s) or a shop unit within a building will usually result in there being more than a single UPRN anyway.
Excluding larger numbers of candidates isn’t a problem for this project, as the aim is to improve the proportion of postcodes mapped in OSM above the current 30%. I’m not trying to capture all the UPRNs.
I’ve seen some examples of this, but with the extra UPRNs still falling within the building outline. That’s probably more luck than design, so I’ll adjust the process to exclude INSPIRE polygons which contain more than one UPRN.
Yes, in most cases. There will be some buildings which are misaligned or badly drawn which still fit >95% within their parent Land Registry INSPIRE polygon which will be matched, but that won’t introduce any incorrect matches.
The main aim of the import process is to capture a large number of missing postcodes accurately and quickly. Following each import, tags like addr:street will be added in manual edits where I can be confident of the association. This is more a “free the postcode” project than an attempt to match everything or fix misaligned buildings.
Small substations seems to be a special case, as they often (but not always) have a UPRN in a corner of the plot of land, and at the centre. They are in different ranges though, so presumably allocated independently.
In some cases, if the UPRNs link to the same postcode, it might still be possible to carefully import just the postcode.
Semi-detached houses that haven’t been split will be picked up by your cadastral parcel check for private houses, but for council houses or recently built houses may reside within a single cadastral, so filtering to cadastral parcels with a single UPRN should safely excluded catching half of a misaligned semi-dethatched house in a single parcel.
Some residential buildings have extra UPRNs representing annexes, that might not necessarily be separately addressable. Some areas seem to also allocate additional UPRNs to residential properties that have a business based at the address, even if it’s not necessarily a public facing part of the business.
You might need to be careful at misaligned buildings at the corners of road junctions with, or where the postcode changes midway through a terrace but the terrace is misaligned by an entire building.
That’s something which should be easy to spot in JOSM with the OSMUK LR Polygons layer and to exclude before hitting the upload button. [EDIT: Wiki updated to include this.]
One gotcha I found when mapping near a friend - PR26 9JE. Friend lives on Drinkwater Lane around the corner from Drinkwater Road - bothe are well signposted. This postcode covers properties on both the Lane and the Road. The Council address of friends property is Drinkwater Road PR26 9JE as is the Royal Mail address, however all the residents believe they live on Drinkwater Lane and have their mail addressed as Drinkwater Lane. Postie has to sort it (pun intended)
Hopefully those are the sorts of places where all the properties have addr:street already set, as delivery problems often seem to be the motivation for people to make their first OSM edit. The proposed import won’t touch any address tags other than addr:postcode in any case, so it shouldn’t be a problem there.
In any subsequent manual edits, I’m more likely to add a fixme and/or a note where there appears to be some ambiguity.
Sample of Land Registry INSPIRE polygons after those containing nodes with address tags have been filtered out (pink fill), around Forest Gate, London E7:
As you’re mainly interested in postcodes, what happens to this if you include cadastral that have multiple UPRNs inside that all share the same postcode?
That’s something I’ll definitely look at at a later date and probably not as part of this proposal, as I only really need a few matches for each postcode unit in order to have a good chance of manually matching them with addr:street.
After matching buildings and some other addressable polygons which are ≥95% within their Land Registry INSPIRE polygon, and which have a single UPRN within the building, the result in QGIS is below. Red and magenta are candidates to have both addr:postcode and ref:GB:uprn added, those in green already have the correct postcode, but will have ref:GB:uprn added, other colours can be ignored.
The same part of Forest Gate, London E7. Buildings here tend to be well-aligned and most already have addr:housenumber and addr:street, with a few addr:postcode added from CodePoint Open (mostly thanks to @spiregrain ).
An example from an area with very poor postcode coverage. The HR postcode area only has 10% of geographic units mapped, with the HR5 postcode district at only 6.5%. It contains a single postcode sector HR5 3 which includes Kington. After import, most residential streets can be matched to postcodes. The town centre has almost no import candidates as buildings haven’t been split (and even if they were, multiple occupiers and UPRNs would exclude many), but we also have FHRS data for addresses and postcodes there.
Thanks for the shout-out. Is it actually helpful to this import method to have the code-point open addr:postcodes in place? (Perhaps it provides something to check against?)
i.e. is it worth rattling through the remaining few here and in similar places?
It’s definitely worth continuing to add postcodes from CodePoint Open and FHRS, because it will get the postcodes into OSM and improve the mapping stats sooner rather than later. Even if this proposal succeeds, it could take weeks before I get to that corner of Manor Park. It will also be helpful to check against existing postcodes before uploading.
@JassKurn Have I satisfied your points above, or is there any other information you need?
