I’ve been mapping some buildings in Littlehampton, and I’ve come across some apartment buildings[1] so far that have enough units to cause the ref:GB:uprn field to exceed 255 characters. I’ve worked around it by mapping them as a range (e.g xxxxxx-yyyyyy) as they’ve all be consecutive.
Is this acceptable, or is there a better way?
[1] Way: Liberty House (1501129214) | OpenStreetMap
Thanks & Regards
Stephen
Is there any benefit to adding these UPRNs to OSM anyway? We do not know what these ranges or long lists of UPRNs apply to, adding them to the building is surely wrong in most cases, as in most cases a UPRN is assigned to an address, not a building.
We know the postcode of the building if they all have the same postcode.
Although for a building with a large number of UPRNs, like a block of flats, it may have its own postcode(s) and Code-Point Open might be more useful. According to the OS documentation, it’s not the geometric centroid, but “the co-ordinate of the nearest delivery point to the calculated mean position of the delivery points in the postcode unit”.
You can add the postcode without the UPRN.
It potentially potentially gives a simple way to check which addresses have been mapped, without needing to parse and compare address fields, which are not always standardised. (Datadaptive’s council tax datasets usually include UPRNs, and a tool I’m working on to help import those datasets uses UPRNs in OSM as one way of indicating which addresses have already been mapped.)
You can’t just litter OSM with bad data for your QA tool, it’s the same as tagging for the renderer. 1 2. To be clear, I’m not arguing against ref:GB:uprn here, I’ve added a hell of a lot of them. I’m against adding them when it’s not clear what they apply to, it’s not helping anything, if anything it’s making “OSM as a lookup for UPRNs” worse by being less accurate.
I’m also not clear how this will help you, this is a typical UPRN in OSM, are you gonna count it as mapped? This is a typical address in OSM, are you going to count it as unmapped? As we’ve discussed before I’ve had releative success by geocoding the addresses, a successful geocode means the address is mapped, not the uprn.
I’m not sure that ‘bad data’ or not knowing what they apply to are relevant here. We have 30 UPRNs for 30 flats, all contained in one building. Since we’re not mapping the internals of the building we can’t assign each UPRN to a single way. While the UPRN might not be as well used as postcodes, it does make it very simple for mapping tools to query.
I’d like to map them as a list with flat 1’s UPRN being first, etc.., but the size limitation prevents that (for some reason the sequential 30 UPRNs have been assigned to the flats in a random order).
Are they all accessed from the same door?
Yes, from what I can tell there’s only one entrance.
Just as a slight update, the UPRNs have been sequentially allocated, flat 1 has the lowest UPRN, flat 30 the highest UPRN.
There’s a very weird bug with JOSM that causes features in a GeoJSON file with the same co-ordinates to be merged into one node BUT the individual fields get merged with different orderings, so the ADDR and UPRN fields from Datadaptive’s files each had 30 entries, but they no longer correlated to each other. I’ve only just caught this while mapping another apartment block.
I think that’s probably by design, so that e.g. neighbouring areas that share boundary points will get a single node in OSM rather than duplicate nodes. But it’s not always the right thing to do.
I work around this in some GeoJSON files I prepare for use in JOSM, by artificially moving each duplicate node by a very small amount.