Then even by street (or place), seeing how many of the elements have a house number or name tagged (or unit or flats) to give the percentage that is fully addressed.
I’ve created a project to analyse the address tagging across the UK and I have found it useful to find gaps in address tagging and fix them.
Our address coverage is fairly patchy, but with a bit of work a lot can be tidied up, which I have tried to show in the DH postcode area, although it is still far from finished.
I have tried not to make the site prescriptive at all, nothing tells you how something should be tagged, only how it currently is tagged, and thereby highlighting issues.
I wasn’t planning to, no. Some of the processing is done by postcode area (e.g. “DH”, the first part of the full postcode, e.g. “DH1 2AB”), which makes sense as a first way to divide areas in the UK, but there aren’t many other countries with postcodes quite like here.
Then also many countries seem to have addressing oddities, such as addr:parentstreet here, or even if it is just the way that addresses are formatted when written on an envelope (switch on the option in the settings).
addr:suburb (if set) might be appended with a hyphen to addr:city or replace it completely (different local conventions), but that is optional. We don’t use addr:parentstreet in Germany.
I’d appreciate if you’d expand this tool to other countries like Germany, but I totally understand if that is too much effort and you want to keep the focus on the UK. Thanks anyway for the development of all your QA tools!
That sounds sufficiently similar that it would be easy enough to adapt to.
I am discovering that there is the non-zero maintenance effort to having such tools, as much as they can be made to automatically update the data. This effort is increased with greater exposure and usage. So I would like to keep the focus on the UK, but would be more than happy to provide help to someone looking to fork the project for a different country about what needs changing and setting up (I understand that “just fork it” is not really helpful).
I don’t understand what you think should be replaced
addr:suburb, addr:locality, addr:hamlet, addr:village and addr:town are considered as synonyms, and detected in that order, with the first one taken for the ‘suburb’ area.
These tags are widely enough used in the UK that they need to be considered and parsed as synonymous, even though I consider that in almost all cases we should simply have addr:suburb where some smaller unit than the postal town is part of the address.
The good Burghers of this proud ancient market town would be very upset to be called a suburb. A suburb is usually defined as part of an urban area. Not a town 12 miles away from where a private company happens to have its depot.
This seems to be another cases where the addressing schema in the UK can be interpreted in multiple ways. I doubt this ambiguity is helpful to anyone.
I have personally tended to add addr:(conurbation size) in addition to addr:suburb, mainly to match existing tagging. This seems a little repetitive, but also seems like a reasonable approach.
Some areas prefer not to use addr:city as the “Postal Town”, as defined by Royal Mail, though using it as the “Postal Town” seems to be far more common.
All these different approaches seem counterproductive.
This is almost certainly for a separate topic, but is it time to decide on a definitive schema that can be applied consistently? Ideally, something that accommodates, comprehensible but uniquely, every address type.
There is nothing further down the page to say that in the UK addr:city should explicitly match the address scheme invented by one now-privatised mail delivery service.
If I was posting a letter to Eakring I might include the “Royal Mail Post Town”, but may just use the Postcode. If I was telling a human where it was, I would not mention Newark.
Storing the “Royal Mail Post Town” in OSM isn’t necessarily wrong (there have been arguments both ways since forever), but where should the “human address” go?
Is addr:* for postal addresses or for “human addresses”? For example, many suburbs of Sheffield are not included in the postal addresses (except to disambiguate from another road with the same name), however a “human address” would probably include them. It was my understanding that addr:* was for postal addresses.
Perhaps the ‘human address’ could be derived by taking the ‘first’, i.e. smallest, place type from the address tags and omitting the others. This is how places should generally be tagged and would provide a suitable result in your example.
Have is_in:* keys been deprecated in the UK? If not, it seems to me they are well-suited to tagging the geographical information that some users wish to include. You can have is_in:village, is_in:town, is_in:county, even is_in:former_postal_county.
It seems to me there are two schools of thought on tagging the location of an object. One school wants to tag something reasonably faithful to the postal address used by Royal Mail. The other school wants to tag a geographical or “human” description of the location. I don’t know what the relative sizes of the two schools are.
Can we have an approach of live-and-let-live to this? In other words, the postal address school uses the addr:* tags and turns a blind eye to the is_in:* tags. The geographical school uses the is_in:* tags and turns a blind eye to addr:* tags except the ones finer-grained than “village”.
I agree that the wiki page is not easy to figure out. If the content of the page could be expressed more clearly, that would be all to the good. But I would caution against changing the recommendations and advice.
Much of the page was constructed by RobJN in the light of discussions on the talk-gb mailing list. I believe it is the best compromise that can be achieved between two conflicting aims.
To accommodate the different views of different contributors in the UK
To be prescriptive enough to make it useful
(In other words, the page provides for more than one way of tagging in certain situations, and that is intentional.)
This has also allowed to give warnings for when no nearby street has been found. I have also added a couple of new warning categories and tried to limit the false positives for abbreviations (“St” was getting flagged too much).
As with all such QA tools, there are some things shown there which are not actually errors. If you find anything systematic, then please let me know and I can adjust it.
