Re: [Talk-GB] UPRN wiki page

[Mark Goodge]

On 18/11/2020 11:10, Robert Whittaker (OSM lists) wrote:


It could well vary by local authority, but looking at the pattern of
URPNs near where I live, it certainly seems that there is one assigned
to every public road. There is consistently exactly UPRN at one end or
the other of each road. The pattern is quite obvious if you look at a
housing estate with lots of little roads.


Not every street has them. Mine doesn't, for example. But others in my 
town do.


Having had a look at various examples, I'm pretty sure that every 
newbuild street that was constructed since UPRNs became a requirement 
has one, but they only get applied retrospectively to existing streets 
if either the local authority has a policy of bulk-adding them or an 
operational need arises to do so.


The fact that they are always at the extreme end of the street, though 
(a pattern I hadn't previously spotted), gave me an idea. I've run a 
load of queries against the data, and it's possible, with very high 
reliability, to find the street record UPRN for a USRN by looking for a 
UPRN which precisely matches the geometry of the street. You can see the 
results of that here, for example, where I've changed the icon for 
street records to be red instead of blue:


https://uprn.uk/map?loc=17,52.1714708,-2.2041535

If anyone wants to replicate that, the process I, broadly speaking 
(after a few false starts!) was, iterating over each USRN sequentially...


1. Find any associated UPRNs that are linked to that USRN in the OS Open 
Linked Identifiers (LIDS) database. If there are none, then presumably 
this USRN doesn't have a street record.


2. If there are linked UPRNs, then run a spatial SQL query to find 
which, if any, intersect the geometry of the USRN.


3. Any that match are street records.

Normally, there is only one street record for a USRN. I was a bit 
surprised to find some USRNs that matched multiple UPRNs in this way, 
but, on checking them, all of the UPRNs have identical coordinates! So, 
in those cases, I think what we have is a set of one or more historic 
(archived) UPRNs that share coordinates with the currently active one.


Doing this found me 301,645 UPRNs that I think are street records, which 
is in the right ballpark if a little on the low side. Picking some at 
random, and checking them against non-open sources has, so far, resulted 
in no false positives - that is, all the ones I think are street records 
really are street records. That gives me confidence to assume that a 
precise match is reliable.


However, there are false negatives. That is, there are some UPRNs that I 
know to be street records (both from a visual check on the map and 
cross-checking against non-open sources), but that don't get matched by 
this algorithm.


Having had a look, this appears to be caused by a slight mismatch 
between the two sets of coordinates. In all the ones I've checked, it's 
a simple question of a different number of significant digits - 
truncating the one with more digits results in a match.


So I think what I need to do next is modify my algorithm to look for a 
UPRN that precisely matches, or is very close to (less than 1m 
distance), the first or last node in the USRN geometry.


I'll report back when I've done that. It may take a while, though!

Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[James Derrick]

Hi,

Thanks for the additional information Mark - very useful.

On 18/11/2020 11:28, Mark Goodge wrote:
What I'd suggest, therefore, is that we should add as many USRNs as 
possible, based on a best-match between the relevant OSM way and the 
OS OpenUSRN geometry. But we should only add UPRNs that are 
unambiguously the correct one for a particular building or structure. 


+1

That makes a lot of sense, as does the other comments about the geometry 
and modelling (down to way segments) of OS and OSM mapping being different.


The UPRN point is well made - the junction of Glazebury Way / Gisburn 
Court has both a foul drain cover (subterranean infra ref?) and a 
Northumberland County Council grit bin (with a NCC-specific reference 
label)!



My hope in attempting the earlier Overpass query is that a JOSM 
validator might be possible to assist with tagging, however the 
complexities being discussed here suggest that UPRN=building; 
USRN=highway; is both simple and wrong in several edge cases.



In case you want to visualise the earlier discussion about Cramlington, 
here's an https://overpass-turbo.eu/ query to show the USRN data I added 
as soon as it became publicly available:


---cut here---
//[bbox:south,west,north,east]
[out:json][timeout:25][bbox:55.08,-1.60,55.10,-1.566];
(
    way["ref:GB:usrn"];
);
// print results
out body;
>;
out skel qt;
---cut here---

(and change "ref:GB:usrn" to "ref:GB:uprn" to see house references, and 
the missing building I'm about to add...)


Happy Mapping,


James
--
James Derrick
li...@jamesderrick.org, Cramlington, England
I wouldn't be a volunteer if you paid me...
https://www.openstreetmap.org/user/James%20Derrick


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Lester Caine]

On 18/11/2020 11:10, Robert Whittaker (OSM lists) wrote:

It's definitely possible for UPRNs to be assigned to streets. I think
you can tell this by searching for such a UPRN at
https://www.findmyaddress.co.uk/  (I don't look at that now since they
added a new T forbidding any use of the information for competing
purposes.) IIRC, that site will tell you if a UPRN you enter is a
street reference, and then refuse to provide the usual address
information.


It is worth pointing out that UPRN references identify parcels of land 
and in theory the whole of the United Kingdom is now covered by a 
continuous grid of land parcels with unique identifiers. Where a parcel 
is developed into multiple new smaller parcels then a new block of 
UPRN's will be generated by the local authority as defined by the 
planning documentation. So roads and amenity land which do not involve 
postal addresses will be defined along with other land registry parcels. 
I am not sure what happens with the original UPRN, but I would expect it 
to be tagged as 'ended' when the new contained parcels are 'started'. It 
should not be used as a part of the new batch for consistency but I 
can't find the 'rules' applied here. The new roads on the developments 
will then have new USRN references and Royal Mail will assign postcodes 
to these new roads. Many UPRN packets will never have a postal address 
listed in the PAF file ( and many businesses today are not properly 
listed either ) even if a postcode is used with that object as if it is.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Mark Goodge]

On 18/11/2020 09:55, James Derrick wrote:

Building UPRN tags appear to be more clear-cut, with the U*SN location 
node around the centre of a building way.


As we all learn more about the data, perhaps I (and others?) may have 
been to quick to add USRN tags as they first became available?


USRNs are relatively straightforward, for several reasons. Firstly, they 
only apply to highways, so they're much less ambiguous than UPRNs. And 
they can, generally, be matched with the relevant OSM way (or relation) 
just by using a map overlay (although be aware that an OSM way may not 
exactly match the geometry of OS MasterMap, which is what the OS 
OpenUSRN geometry is based on). And, finally, the OpenUSRN database only 
contains current USRNs, so there's no danger of inadvertently tagging a 
road with an inactive one.


UPRNs are much harder, partly because the OpenUPRN database includes 
inactive ones (there are good operational reasons for this, but it's 
unhelpful for mapping purposes when you're trying to map what exists 
rather than what might once have been) and partly because UPRNs can 
apply to pretty much anything, including subdivisions or different 
levels of an entity that may be a single mapped object as well as things 
that can't actually be seen (and therefore wouldn't be mapped on OSM).


What I'd suggest, therefore, is that we should add as many USRNs as 
possible, based on a best-match between the relevant OSM way and the OS 
OpenUSRN geometry. But we should only add UPRNs that are unambiguously 
the correct one for a particular building or structure.


Going back to USRNs, there are a few gotchas that mappers need to be 
aware of. The first is that a road can have multiple USRNs. The most 
common instance of that is a trunk road (that is, one operated by a 
national, rather than county, highway authority), which will have a USRN 
issued by the national authority for its entire length and individual 
USRNs issued by each highway authority that it passes through. But even 
smaller roads can have multiple USRNs if it suits the highway authority 
to assign them for operational purposes.


The other main gotcha is that USRNs don't have a one-to-one 
correspondence with OSM ways that represent mapped streets. For example, 
a cross-country road that crosses a highway authority boundary will have 
a different USRN in each authority, but will usually be a single OSM 
way. On the other hand, an urban street that is one-way for only part of 
its length will be separate OSM ways (as those restrictions have to be 
applied on a per-way basis), but a single USRN. So when tagging a way 
with a USRN, you do have to be sure that you are tagging the right way 
with the right USRN.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Robert Whittaker (OSM lists)]

On Wed, 18 Nov 2020 at 10:42, Jez Nicholson  wrote:
> My personal opinion is that UPRNs never apply to a road or road section. They 
> apply to something that you cannot see, like a grit bin that is no longer 
> there.

It's definitely possible for UPRNs to be assigned to streets. I think
you can tell this by searching for such a UPRN at
https://www.findmyaddress.co.uk/ (I don't look at that now since they
added a new T forbidding any use of the information for competing
purposes.) IIRC, that site will tell you if a UPRN you enter is a
street reference, and then refuse to provide the usual address
information.

It could well vary by local authority, but looking at the pattern of
URPNs near where I live, it certainly seems that there is one assigned
to every public road. There is consistently exactly UPRN at one end or
the other of each road. The pattern is quite obvious if you look at a
housing estate with lots of little roads.

Robert.

-- 
Robert Whittaker

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Jez Nicholson]

Good stuff. We are all learning here. And the raw data is deliberably
obfuscated.

Some of the UPRNs near road junctions are mysterious. They could be old IDs
for objects since removed. Do we have a full list of what objects could be
included?

My personal opinion is that UPRNs never apply to a road or road section.
They apply to something that you cannot see, like a grit bin that is no
longer there.

The only potentially legit duplicate I've seen so far is adjacent
postboxes. They might get a single UPRN between them.

On Wed, 18 Nov 2020, 09:58 James Derrick,  wrote:

> Morning all,
>
> On 17/11/2020 15:32, Mark Goodge wrote:
>
> what we have is what, from a mapping perspective, is a single road
> (Glazebury Way), but that comprises multiple OSM ways. So it's not
> unreasonable to add the UPRN to all the ways which make up the road.
>
> However, in this case I think I am talking bollocks. Although the OSM
> mapper has assigned UPRN 10071171668 to Glazebrook Way, the OS OpenUPRN
> OpenUSRN and OpenMap lookups link it to Gairloch Close. If we look at
> Gairloch Close (USRN 3230053) on my USRN map:
>
>
> Owning up, that mapper is me! 
>
> Just as Rob N added U*RN to his portfolio of useful visualisation tools, I
> noticed that adding UPRN to building=* gave location-checked green circles,
> adding UPRN to highway=* didn't seem to.
>
> As an experiment, I added the same ID to both ref:GB:usrn and ref:GB:uprn
> tags and promptly forgot about the double tagging.
>
> Jez let me know in a changeset discussion here, and the errant tag
> removed:
>
>   https://www.openstreetmap.org/changeset/90968241
>
> So, if there's any talking bollocks here - it's been uttered by me on home
> turf!
>
>
> I've removed the experimental double-tagging, and attempted to create a
> basic Overpass Turbo query to look for (what could be) incorrect values:
>
> ---cut here---
>
> [out:json][timeout:25];
> // gather results
> (
>   // node or way double tagged
>   node["ref:GB:usrn"]["ref:GB:uprn"]({{bbox}});
>   way["ref:GB:usrn"]["ref:GB:uprn"]({{bbox}});
>   // highway with Property
>   way["ref:GB:uprn"]["highway"]({{bbox}});
>   // building with Street
>   node["ref:GB:usrn"]["building"]({{bbox}});
>  way["ref:GB:usrn"]["building"]({{bbox}});
> );
> // print results
> out body;
> >;
> out skel qt;
>
> ---cut here---
>
>
> And now down the rabbit hole...
>
> there's a single linked UPRN that appears to be on Glazebury Way, or at
> least the intersection of Glazebury Way and Gairloch Close, rather than one
> of the properties on Gairloch Close. Follow that link, and it's UPRN
> 10071171668:
>
> https://uprn.uk/10071171668
>
> Now, there's nothing more we can discover from the maps and lookups, given
> that the OS open data doesn't tell us precisely what it is and the maps
> aren't sufficiently high-resolution. But if we cheat a bit and go to the
> location on Google Maps, then switch into street view:
>
> https://goo.gl/maps/ojwFAP21D4HkUvX77
>
> I have a strong hunch that UPRN 10071171668 is actually a subsurface
> property (eg, a utilities conduit) accessed via that manhole cover.
>
>
> Now that's a whole level of complexity which I wasn't previously aware of.
> If the data set includes data for ALL entity types (e.g. not just
> buildings, streets and the odd post box), then my assumption that a U*RN in
> the middle of a highway which looks like a logical centre point for a way
> segment could be incorrect.
>
> Looking out of my window (I did say this is home turf...) there is a foul
> drain cover at the intersection of Glazebury/ Gisburn, and likely one at
> Glazebury/ Gisburn (it's currently chucking it down here, so not keen to
> check immediately).
>
> Building UPRN tags appear to be more clear-cut, with the U*SN location
> node around the centre of a building way.
>
> As we all learn more about the data, perhaps I (and others?) may have been
> to quick to add USRN tags as they first became available?
>
> As several of you appear to have additional sources to validate USRN,
> could you offer any suggestions to alter these specific highway=residential
> please?
>
>
> James
> --
> James Derrick
> li...@jamesderrick.org, Cramlington, England
> I wouldn't be a volunteer if you paid me...
> https://www.openstreetmap.org/user/James%20Derrick
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[James Derrick]

Morning all,

On 17/11/2020 15:32, Mark Goodge wrote:
what we have is what, from a mapping perspective, is a single road 
(Glazebury Way), but that comprises multiple OSM ways. So it's not 
unreasonable to add the UPRN to all the ways which make up the road.
However, in this case I think I am talking bollocks. Although the OSM 
mapper has assigned UPRN 10071171668 to Glazebrook Way, the OS 
OpenUPRN OpenUSRN and OpenMap lookups link it to Gairloch Close. If we 
look at Gairloch Close (USRN 3230053) on my USRN map:


Owning up, that mapper is me! 

Just as Rob N added U*RN to his portfolio of useful visualisation tools, 
I noticed that adding UPRN to building=* gave location-checked green 
circles, adding UPRN to highway=* didn't seem to.


As an experiment, I added the same ID to both ref:GB:usrn and 
ref:GB:uprn tags and promptly forgot about the double tagging.


Jez let me know in a changeset discussion here, and the errant tag removed:

https://www.openstreetmap.org/changeset/90968241

So, if there's any talking bollocks here - it's been uttered by me on 
home turf!



I've removed the experimental double-tagging, and attempted to create a 
basic Overpass Turbo query to look for (what could be) incorrect values:


---cut here---

[out:json][timeout:25];
// gather results
(
  // node or way double tagged
  node["ref:GB:usrn"]["ref:GB:uprn"]({{bbox}});
  way["ref:GB:usrn"]["ref:GB:uprn"]({{bbox}});
  // highway with Property
  way["ref:GB:uprn"]["highway"]({{bbox}});
  // building with Street
  node["ref:GB:usrn"]["building"]({{bbox}});
 way["ref:GB:usrn"]["building"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

---cut here---


And now down the rabbit hole...

there's a single linked UPRN that appears to be on Glazebury Way, or 
at least the intersection of Glazebury Way and Gairloch Close, rather 
than one of the properties on Gairloch Close. Follow that link, and 
it's UPRN 10071171668:


https://uprn.uk/10071171668

Now, there's nothing more we can discover from the maps and lookups, 
given that the OS open data doesn't tell us precisely what it is and 
the maps aren't sufficiently high-resolution. But if we cheat a bit 
and go to the location on Google Maps, then switch into street view:


https://goo.gl/maps/ojwFAP21D4HkUvX77

I have a strong hunch that UPRN 10071171668 is actually a subsurface 
property (eg, a utilities conduit) accessed via that manhole cover.


Now that's a whole level of complexity which I wasn't previously aware 
of. If the data set includes data for ALL entity types (e.g. not just 
buildings, streets and the odd post box), then my assumption that a U*RN 
in the middle of a highway which looks like a logical centre point for a 
way segment could be incorrect.


Looking out of my window (I did say this is home turf...) there is a 
foul drain cover at the intersection of Glazebury/ Gisburn, and likely 
one at Glazebury/ Gisburn (it's currently chucking it down here, so not 
keen to check immediately).


Building UPRN tags appear to be more clear-cut, with the U*SN location 
node around the centre of a building way.


As we all learn more about the data, perhaps I (and others?) may have 
been to quick to add USRN tags as they first became available?


As several of you appear to have additional sources to validate USRN, 
could you offer any suggestions to alter these specific 
highway=residential please?



James
--
James Derrick
li...@jamesderrick.org, Cramlington, England
I wouldn't be a volunteer if you paid me...
https://www.openstreetmap.org/user/James%20Derrick

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Steve Doerr]

On 17/11/2020 22:34, Jez Nicholson wrote:
From my change request discussion it appears that the UPRN appeared on 
the road as part of a test of Robert's Mathmos matching.


The USRN and the UPRN tags showed the same number, I believe. The UPRN 
tag has now been removed leaving only the USRN, but the number concerned 
is not the USRN for that road.


Isn't there a sandbox for people to test things out without hitting the 
live database?


--
Steve

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Jez Nicholson]

>From my change request discussion it appears that the UPRN appeared on the
road as part of a test of Robert's Mathmos matching.

On Tue, 17 Nov 2020, 16:15 Mark Goodge,  wrote:

>
>
> On 17/11/2020 15:41, Robert Skedgell wrote:
>
> > Roads can have more than one USRN. I've come across some sections of
> > road which appear to have more than one Designated Street Name record
> > (possibly streets which cross authority boundaries?). In addition to
> > this, there may be records of types Unofficial Street Name, Officially
> > Described Street and Numbered Street.
>
> Trunk roads, in particular, will have individual USRNs in each highway
> authority they cross as well as an overall USRN for the entire length of
> the road. There are also USRNs which form a collection of roads.
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Mark Goodge]

On 17/11/2020 15:41, Robert Skedgell wrote:


Roads can have more than one USRN. I've come across some sections of
road which appear to have more than one Designated Street Name record
(possibly streets which cross authority boundaries?). In addition to
this, there may be records of types Unofficial Street Name, Officially
Described Street and Numbered Street.


Trunk roads, in particular, will have individual USRNs in each highway 
authority they cross as well as an overall USRN for the entire length of 
the road. There are also USRNs which form a collection of roads.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Robert Skedgell]

On 17/11/2020 14:53, Cj Malone wrote:
> On Tue, 2020-11-17 at 14:10 +, Jez Nicholson wrote:
>> Whilst i'm here, am I correct that a UPRN can *only* be on a single
>> thing?
>> So anything in
>> https://taginfo.openstreetmap.org/keys/?key=ref%3AGB%3Auprn#values mo
>> re
>> than once is an error?
>>
>> ...or can a road have a USRN *and* a UPRN?
>
> As far as I know a road should have only 1 USRN, but it can have
> multiple UPRNs. I think it's mainly if it goes over a admin boundary,
> each area will have a UPRN but the road will have one USRN.
>
> Also OSM often has multiple ways per road, each of these ways should
> share a USRN and more often than not share the UPRN.

Roads can have more than one USRN. I've come across some sections of
road which appear to have more than one Designated Street Name record
(possibly streets which cross authority boundaries?). In addition to
this, there may be records of types Unofficial Street Name, Officially
Described Street and Numbered Street.

Details of the USRN specification are here
https://www.ordnancesurvey.co.uk/documents/product-support/tech-spec/open-usrn-techspec-v1.1.pdf



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Mark Goodge]

On 17/11/2020 14:47, I wrote:


But, having said that


...or can a road have a USRN *and* a UPRN?

Yes. And, in this particular case:

https://taginfo.openstreetmap.org/tags/ref%3AGB%3Auprn=10071171668

(follow the Overpass turbo link to see it mapped)

what we have is what, from a mapping perspective, is a single road 
(Glazebury Way), but that comprises multiple OSM ways. So it's not 
unreasonable to add the UPRN to all the ways which make up the road.
However, in this case I think I am talking bollocks. Although the OSM 
mapper has assigned UPRN 10071171668 to Glazebrook Way, the OS OpenUPRN 
OpenUSRN and OpenMap lookups link it to Gairloch Close. If we look at 
Gairloch Close (USRN 3230053) on my USRN map:


https://uprn.uk/usrn/3230053

there's a single linked UPRN that appears to be on Glazebury Way, or at 
least the intersection of Glazebury Way and Gairloch Close, rather than 
one of the properties on Gairloch Close. Follow that link, and it's UPRN 
10071171668:


https://uprn.uk/10071171668

Now, there's nothing more we can discover from the maps and lookups, 
given that the OS open data doesn't tell us precisely what it is and the 
maps aren't sufficiently high-resolution. But if we cheat a bit and go 
to the location on Google Maps, then switch into street view:


https://goo.gl/maps/ojwFAP21D4HkUvX77

I have a strong hunch that UPRN 10071171668 is actually a subsurface 
property (eg, a utilities conduit) accessed via that manhole cover.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Cj Malone]

On Tue, 2020-11-17 at 14:10 +, Jez Nicholson wrote:
> Whilst i'm here, am I correct that a UPRN can *only* be on a single
> thing?
> So anything in
> https://taginfo.openstreetmap.org/keys/?key=ref%3AGB%3Auprn#values mo
> re
> than once is an error?
> 
> ...or can a road have a USRN *and* a UPRN?

As far as I know a road should have only 1 USRN, but it can have
multiple UPRNs. I think it's mainly if it goes over a admin boundary,
each area will have a UPRN but the road will have one USRN.

Also OSM often has multiple ways per road, each of these ways should
share a USRN and more often than not share the UPRN.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Mark Goodge]

On 17/11/2020 14:10, Jez Nicholson wrote:
Whilst i'm here, am I correct that a UPRN can *only* be on a single 
thing? So anything in 
https://taginfo.openstreetmap.org/keys/?key=ref%3AGB%3Auprn#values 
 
more than once is an error?


There is a one to one correspondance between UPRNs and addressable 
objects (in either the PAF or AddressBase). A single mappable entity may 
contain multiple addressable units (eg, a block of flats), so there can 
be multiple UPRNs on a single OSM object, since we don't normally 
subdivide buildings into individual units unless it can easily be mapped.


But the reverse isn't true. A single UPRN can only correctly be assigned 
to a single object. If it's being assigned to multiple objects then 
there's likely to be an error somewhere.


But, having said that


...or can a road have a USRN *and* a UPRN?

Yes. And, in this particular case:

https://taginfo.openstreetmap.org/tags/ref%3AGB%3Auprn=10071171668

(follow the Overpass turbo link to see it mapped)

what we have is what, from a mapping perspective, is a single road 
(Glazebury Way), but that comprises multiple OSM ways. So it's not 
unreasonable to add the UPRN to all the ways which make up the road.


Whether a road has a UPRN as well as a USRN is a bit inconsistent. As a 
general rule, roads which existed before UPRN/USRN addressing was rolled 
out will only have a USRN allocated. But new roads that are built as 
part of a new development will, typically, have a UPRN as the road 
usually exists before the houses (or industrial units) accessed from 
that road are built. So the road has to have its own entry in the UPRN 
database.


It is complicated, and the published documentation isn't particularly 
comprehensive. I'm still getting my head round it!


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Jez Nicholson]

Whilst i'm here, am I correct that a UPRN can *only* be on a single thing?
So anything in
https://taginfo.openstreetmap.org/keys/?key=ref%3AGB%3Auprn#values more
than once is an error?

...or can a road have a USRN *and* a UPRN?

On Tue, Nov 17, 2020 at 1:48 PM Jez Nicholson 
wrote:

> Well-spotted. I've updated it to, "UPRNs provide every property or object
> with a consistent, persistent, numerical identifier (often between 8 and 12
> digits, but not restricted to 12)".
>
> I know that you've been looking at UPRNs, so please add to the wiki page
> or discussions.
>
> On Tue, Nov 17, 2020 at 1:00 PM Mark Goodge  wrote:
>
>>
>>
>> On 17/11/2020 11:34, Jez Nicholson wrote:
>> > Following the fine efforts of a number of people to get ref:GB:uprn
>> > through the tag proposal process I have created
>> > https://wiki.openstreetmap.org/wiki/Key:ref:GB:uprn
>> > 
>> >
>> > Please add information to it, or discussions.
>>
>> One minor point on that. UPRNs aren't necessarily 12 digits. They're an
>> unsigned integer of (currently) up to 12 digits. UPRNs of 999
>> and below aren't zero-padded. They do, in fact, go all the way down to
>> UPRN 1.
>>
>> Mark
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Jez Nicholson]

Well-spotted. I've updated it to, "UPRNs provide every property or object
with a consistent, persistent, numerical identifier (often between 8 and 12
digits, but not restricted to 12)".

I know that you've been looking at UPRNs, so please add to the wiki page or
discussions.

On Tue, Nov 17, 2020 at 1:00 PM Mark Goodge  wrote:

>
>
> On 17/11/2020 11:34, Jez Nicholson wrote:
> > Following the fine efforts of a number of people to get ref:GB:uprn
> > through the tag proposal process I have created
> > https://wiki.openstreetmap.org/wiki/Key:ref:GB:uprn
> > 
> >
> > Please add information to it, or discussions.
>
> One minor point on that. UPRNs aren't necessarily 12 digits. They're an
> unsigned integer of (currently) up to 12 digits. UPRNs of 999
> and below aren't zero-padded. They do, in fact, go all the way down to
> UPRN 1.
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN wiki page

[Mark Goodge]

On 17/11/2020 11:34, Jez Nicholson wrote:
Following the fine efforts of a number of people to get ref:GB:uprn 
through the tag proposal process I have created 
https://wiki.openstreetmap.org/wiki/Key:ref:GB:uprn 



Please add information to it, or discussions.


One minor point on that. UPRNs aren't necessarily 12 digits. They're an 
unsigned integer of (currently) up to 12 digits. UPRNs of 999 
and below aren't zero-padded. They do, in fact, go all the way down to 
UPRN 1.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb