I'm sure we're all working towards the same aims and in good faith - the recent edits were much smaller and I'd thought would be more inline with how you preferred them - there was no ulterior motive behind them.

I do occasionally fix things I come across unrelated to what I've intended to do, perhaps they should be in a new changeset, but I've always seen them as inconsequential. I do see you point on that though.

A third perspective will, I'm sure, be helpful. My offer to help you with targeted reverts, if needed, still stands.

Phil

I don't believe a revert is the best course of action here.

A significant number of the UPRNs are added completely manually (I have tooling to make this quicker, but it still requires selecting the object and UPRN), so they are not as easily replaceable as you suggest.

I combined improving geometry and adding UPRNs as I find the processes benefit each other. I do believe that adding UPRNs is a benefit in, and of, itself, but I think the combined workflow benefits are much greater.

I would like to suggest an alternative approach, and I hope you will reasonably consider it:

I'll look through all the objects with UPRNs that are either not a building, or building=yes and check that they make sense. For building=yes, I'll upgrade to a more specific tag where appropriate.

I'll continue doing this in smaller batches (geographically), as we've previously discussed.

Whilst I'm doing this I'll improve geometries - I find this benefits from having the UPRN details added.

A suspect this will make you less comfortable - but I believe this will alleviate the need you feel to manually revier every change. As a general approach, I believe that asking people to fix their own errors (where they are able) usually yields the best results for everyone. I would hope that this might also reduce the frustration that you feel - I never undertake anything wanting to negatively impact on other people.

After, say a month, then we could look at the total combined impact. If you still feel that parts should be reverted, then I'll work with you to do that (I have some tooling that would help in this).

I know this would be a leap of faith for you, but in the meantime, I'd ask you to avoid feeling the need to review all changes I make, or if you do, let me know what you'd like to be improved.

Phil

I think it depends - In most cases I agree with you (the numbers on my own street defy all attempt to put them into any logical sequence - even though there were all built at the same time), so where there is ambiguity adding in missing house numbers is best avoided, but I do think there are some limited cases (such as this one) where the gaps can be infilled with very minimal risk of error.

It is also quite common for people to survey both ends of a street and interpolate between.

Hi,

There are some building=yes objects with addresses that ideally shouldn't have. I try and pick these out and make the building more specific, but I will invariably have missed some.

Buildings on a site are tricky - I do put the UPRN on the site where it is clear. Ideally the parent/child relationships would be open data to make this much easier, but at the moment it is not.

Where there are multiple UPRNs for a building (for example a shop with a flat above) I add the UPRNs to the building. I do make efforts to avoid adding retired UPRNs though (based on the sequence they are in and alignment).

I try and align and split buildings at the time of adding UPRNs if they fall on the wrong UPRN, but some slip through, and I do review these on further passes.

I do intend to do a few more passes over the area to pick up errors that may have crept in earlier - so I think it would be much easier not to revert. After some discussion with other local mappers, they'll be in much smaller changesets (divided geographically).

Phil

Thanks for sorting (though you can always leave those to be fixed later when I return if you want).

The house numbers are inferred from the existing house numbers in a given postcode/street, the gaps in the number of houses left, and the consecutive UPRNs as a double check.

I think that was in error when making other buildings more specific. I'd spotted it when looking through in osmcha, so was going to undo that when I looked at the next nearby area.

Hi Pascal,

There had been quite a bit of discussion about the licensing, but the prevailing view is that it is compatible, provided it had been correctly licensed as OGL in the first place. These have been some datasets which contain other IP, so can't be fully licensed as OGL, but these are identified on the dataset.

Personally I think there are three main benefits - the data that can be derived (such as partial addresses), and the ability to match to other datasets (UPRNs now being the government standard), and the ability to use the UPRN dataset to see new features that may be missing from OSM. The identifiers are persistent and well managed, which makes them very stable to add to OSM.

There had been some discussion on the OSM forum in three UK section about this, evolving around a an import, and no objections were raised to improving the data itself, just valid caution about getting it correct.

Phil

Hi Pascal,

I use a few sources, all of which have been released under the Open Government License.

OSMUK Cadastral Parcels give edges for splitting houses into terraces (as there is a lot of here), Open UPRN has a point generally in the centre of each building that links it to a UPRN (but with no other details), then ONS NSPL links the UPRN to a postcode (and various statistical identifiers that I don't use). A visual check that the postcode is the same for a single street gives the street name for the house, and allows any anomalies (generally a street name transition in the wrong place) to be investigated using OpenMap Local or Open USRN (though if OpenMap Local isn't clear). Postal towns then come from a lookup of the first part postcode, which I've created by looking at existing data in OSM and checking in other open sources where necessary.

Phil

Thanks for fixing this - I had thought the buildings were separate from the imagery, but appreciate your local knowledge.

It seemed to be in roughly the centre, so I assumed it was for the forecourt building, but it is possible it is for something else (the road through or the tanks being the most likely candidates).

My overly aggressive ant-spam filter meant that I didn't see the comments or your message until later on.

I'll have a look at structuring the changes into smaller sets, and look at the feedback.

Hi,

Thanks for looking though those changes.

I have been trying to batch changes, but I'm happy to split them into smaller areas. I tend to adjust the geometry at the same time, so it would be hard to separate those out, but I can focus on smaller areas so they are easier to review.

1 - This looks to be an error, I'll reinstate it.

2 - That appear to be one where I've selected the wrong half of a semi-dethatched house when pasting in the UPRN, accidentally overwriting the other import. I'll fix that and double check any others edited.

3 - I think that was an error - I'll fix that.

4 - I tend to use the cadastral parcels as definitive, and align the aerial imagery to that, but I haven't recorded the offsets as it does vary significantly (though less than it did previously).

I think you're right, and it's the road/bridge that those relate to. I'd missed those ones, but I'll fix them.

I've generally added UPRNs to school buildings (unless the a relation was already tagged). My thinking was that many schools have multiple UPRNs covering multiple buildings, and potentially one parent UPRN for the site, but it isn't always clear which one relates to the site. I don't have any strong opinion either way though.

Hi Robert,

Thank you for the helpful tips (and very helpful website) - I'll look to incorporate them to my process in the near future.

I've revised the area and changed the type of some buildings, so it should now be more as expected.

Phil

This might sound even worse to you - but what are you thoughts on adding the street UPRN to the nearest node on the street, and the street way? That would allow for the alignment benefits of the nodes (they tend to be well aligned at junctions) and add the UPRN to the related way itself.

I've come across the "all nodes on a road" approach when looking at looking at UPRNs that were in OSM multiple times - I've left them as they were, though I agree that's an odd approach.

I don't have hugely strong feelings between the two other approaches - the wiki seems to suggest both possibilities - "UPRNs being on multiple sections of the road OR at a single point on the road.". That said, in some cases (at junctions) it isn't always clear which road is linked to which UPRN without checking against the linked USRN.

Hi, there seem to be a few different approaches to street UPRNs (adding them to the way, to all the nodes in the way, or to a single node). I've tried to add them to a node close to the location of the UPRN (normally the end of the road, but occasionally in the middle). This probably requires some more discussion elsewhere, but my thinking was this was the simplest way of getting them in, then USRNs might get added at some later point to the way itself (or maybe a relation of ways.

This really interesting (if you can excuse my enthusiasm). It seems that that UPRN was at the end of the road, but has then been moved. I added it manually when it was at the junction between "Huntington Road" and "Brandsby Grove". It seems to be located there now, in the latest data I have. I don't record changes between the releases, and only the latest version is online, so I can't look back to see this over time. I notice that some sites show it at the other end of the road, showing a snapshot at some point.

I've seen UPRNs migrate as buildings are constructed, and the UPRN moved to the exact location, but not UPRNs that appear to relate to roads move.

I've now updated the casing in Bexhill and the database for any other updates.

Good spot, the PROPPER() function in Excel isn't quite cleaver enough to that. I'll update my database to correctly case prepositions, and separately, update the existing ones.