Seperate to this high quality import, but very much with the same aims, I’ve been writing up a import proposal for the more ad-hoc additions I’d been doing previously. For various reasons, this has taken me longer than planned.
My seperate import proposal (when I finish it…) will be to combine the creating, splitting and aligning of buildings with adding UPRNs (with additional tooling in JOSM), which I think would cover many of the ones that are not yet ready to be matched in this very careful import. I also have some QA tools for UPRNs that can pick up common issues (such as duplicates on dethatched houses), so I intend to make those available at the same time.
I’m hoping that my import proposal, combined with this existing import, will improve the number of addressable buildings with UPRNs.
I think that this import missing some candidate UPRNs is not a significant problem, as they can be added as geometries change, or as tooling evolves.
This import won’t change incorrectly assigned UPRNs, because performing an automated edit of incorrectly assigned UPRNs and postcodes is out of scope for the proposal. These obviously do need fixing, but doing that isn’t an import and a separate proposal will be required.
Maybe I’m misinterpreting your phrasing, but not importing every UPRN is not a problem. The value of an automated import is that the import process is known to be safe to run automatically, so the cost of running it again in future is low, and that will successfully import more UPRNs as the underlying geometry improves.
Turning an automated import into one with manual steps (even moreso 20 minutes for each suburb of each town) does not scale, either for the person running the import, or the people having to then verify the manual changes done as part of the import.
As Robert says, an import process should typically also not be changing existing data (such as duplicate UPRNs) in the OSM database. That data might have been added by someone who knew better. That work is best left to validation tools, and people checking what they flag up.
Disregard the part about the pre-existing errors I meant it more are a comment rather than a criticism.
My issue with the current state of this import is that in my opinion is quality is so low that it is borderline pointless. If the misses were more clustered where say one street has all assigned correctly but the next street is missing most, I wouldn’t have a issue but the fact that the misses are spread out so evenly where every other house is a miss makes this import a waste of effort as someone in the future will have to go through every single street and look at every single house to fix every single miss making the entire import a wasted effort. There is no area on any scale that can be considered complete after this import has passed through.
This is my second issue, the fact that this import is progressing at such a slow rate that I can match its speed with a tool assisted manual import while also have near 0 misses.
2 days ago, rskedgell_import added 1390 ref:GB:uprn tags over a 24 hour period mostly if not all in the Merthyr area with a high miss rate via a automated import.
2 months ago, I added all uprns in my town of Rhymney. adding 2015 in two changesets totalling about 2 hours of work using a tool assisted manual import missing no non-ambiguous uprns.
Sorry for my hostile demeanour but this Import has so much more potential than is currently being exploited and it irritates me and considering OSM prioritizes quality over quantity then maybe this import should be stopped and replaced with a manual import so that less effort is wasted
I think it’s worth separating the concepts of “quality” and “completeness”. If you’re saying it’s a low-quality import, that suggests it’s adding UPRNs which are not correct. Is that the case? If so, that’s catastrophic and would be a reason to stop and re-check the import and potentially revert things.
Bear in mind that Robert is a volunteer and his priorities and time might not align with yours. If you really want 100% of UPRNs mapped, and feel you can do a better job, then by all means go ahead. But being hostile to people on the internet about the fact they’re doing something different from what you want them to do is not cool.
I think it might be worth going back to this, where the aim was stated not to be full coverage of UPRNs, but to increase the number of postcodes:
I can’t see any harm in multiple processes and approaches to add UPRNs and associated data running in parallel - they all move forward towards the same aim.
I personally find that a heatmap of UPRNs is a good way to see misaligned/unsplit areas that might want some more work on the geometry.
I do want to apologise, I do believe my criticism is valid but I could have conveyed it in a better less hostile way. I’m not really sure why I started to get so emotionally invested in this import but after reflection I recognise the error of my way so I apologise to all that had to put up with me in this thread and hope we can be more constructive going forward.
In the end of the day, Osm is free for anyone to add what they want and I’m in no position to dictate where people to direct their effort. @rskedgell please continue this import if it’s what you want to do and please don’t take my words to hearts.
My issue is that you haven’t read the import proposal. The purpose isn’t to capture every UPRN, but to use them as a stepping stone to capture postcodes. Since last October the percentage at the bottom of the table at Postcode Stats | Robert Whittaker's OpenStreetMap Stuff has increased from about 30% to 45% (obviously that’s not just down to me).
You may consider that pointless. I consider reading any more of your comments pointless and have muted you [EDIT: unmuted after @kitsee’s comment this morning was pointed out to me].
There are, as you have noticed, some properties which should be candidate matches, but are missed. At this stage, there are so many missing postcodes in OSM for which there are successful matches that refining the process isn’t necessary.Yet.
I’ve still got over 250 postcode sectors where the import process will result in at least 1000 added UPRNs/postcodes. As I start to run out of easier targets, then I’ll need to make more refinements.
At the moment, I’d consider my contribution to increasing the number of mapped postcodes in OSM by 50% over the last 9 months to be fairly good progress. It may be a little over-cautious, but I want to minimise the risk of importing incorrect data.
