Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 23:14, Cj Malone wrote:

On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote:

What is needed is a means of adding LAYERS of data which can be
managed either via third party data sets, or manual edited using
existing tools to add data that is missing from the narrow view
confined to 'current' objects ...


If I understand you right, I like the idea of this, for example a layer
of bus stops in the UK would be sourced from NapTAN. That layer would
be kept up to date with NapTAN (most bus stops in OSM are a decade old,
unmodified, not validated) and OSM mappers could add
corrections/modifications.
Potentially we could have a line of communication to NapTAN to inform
them of errors in there dataset.

It'll be hard to change some peoples minds, but it's worth discussing.


That is one example and if editing the data can be carried out using 
existing tools then new data sets can be created in a similar way. My 
own tools for handling NLPG data was targeted to allow councils to 
automatically create update data sets as they create new uprn's or 
correct existing ones.


But my own interest is not so much the independent layers like NapTAN 
but being able to update current records with historic details such as 
start_dates which apply to CURRENT objects, but also maintain data that 
has expired due to end_date.


--
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 Locations Map

[Cj Malone]

On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote:
> What is needed is a means of adding LAYERS of data which can be
> managed either via third party data sets, or manual edited using
> existing tools to add data that is missing from the narrow view
> confined to 'current' objects ...

If I understand you right, I like the idea of this, for example a layer
of bus stops in the UK would be sourced from NapTAN. That layer would
be kept up to date with NapTAN (most bus stops in OSM are a decade old,
unmodified, not validated) and OSM mappers could add
corrections/modifications.
Potentially we could have a line of communication to NapTAN to inform
them of errors in there dataset.

It'll be hard to change some peoples minds, but it's worth discussing.

Cj


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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 20:33, David Woolley wrote:

On 04/07/2020 18:24, Lester Caine wrote:
The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM


I'm not referring to OHM; I'm referring to the main OSM map.  At least 
since September 2012, OSM has the complete back history, and, as far as 
I can see, you can use overpass API to retrieve the map as of any date 
and time since then.


BUT you can't upgrade the data in that history, only access previous 
data without any reference to if it is correct or not. OHM is not a 
solution to add the missing history, or correcting that history which 
was removed because of mistakes. It is simply a record of what was done 
with all it's mistakes ...


What is needed is a means of adding LAYERS of data which can be managed 
either via third party data sets, or manual edited using existing tools 
to add data that is missing from the narrow view confined to 'current' 
objects ...


--
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 Locations Map

[David Woolley]

On 04/07/2020 18:24, Lester Caine wrote:
The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM


I'm not referring to OHM; I'm referring to the main OSM map.  At least 
since September 2012, OSM has the complete back history, and, as far as 
I can see, you can use overpass API to retrieve the map as of any date 
and time since then.


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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 12:54, David Woolley wrote:
At the very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced


How does this differ from how OSM already works?  You can already create 
versions of the map at any point in its history, except where data has 
been redacted for legal reasons.


The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM anyway. Providing an historic layer which only holds the 
data that has changed over time AND using the same tools to expand on 
that historic data as are used to map current data removes another 
hurdle to maintenance. If third party data such as NLPG can be processed 
to provide it's data as another layer which can then be combined in the 
one view then it removes the need to simply import large data sets. One 
simply uses which set of layers you want ...


Of cause the other approach is simply merge all available data ... past, 
present and future ... into the one humungus database and navigate the 
problems of maintaining potentially thousands of data sets in sync with 
the 'master' copy.


--
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] Solar Power mapping update Q2 2020

[Dan S]

Hi all

That's great news. By the way, I have some regions to propose, if
anyone would like to be steered:

With my solar PV colleagues, we've discussed targeting a couple of
specific regions. We're looking at the Midlands (because so much good
mapping has happened there already) - but also the area around Exeter,
because there's quite a lot of "reverse flow" (i.e. solar generation)
in that region, and it's a useful case-study area for people working
with the National Grid ESO.

Exeter itself has been mapped to a good extent (30%), but it and its
surrounding areas could take more: Teignbridge (1%), Mid Devon (22%),
East Devon (4%). If anyone fancies looking over those regions, it
could be v beneficial.

Really great seeing all this mapping. I'm hoping to be able to publish
some academic analysis of it all, soonish. - I'll certainly let you
know when I've done so!

Best
Dan

Op do 2 jul. 2020 om 19:16 schreef Gregory Williams
:
>
> Thanks Jerry, and thanks to everyone that's continued to contribute
> more coverage.
>
> The next quarter's update to the FiT register should be published in
> the next few days. So I hope to find time to update the site to use
> that soon.
>
> I continue to be amazed at the steady progress in the coverage. Though,
> as you say, there are quite a few areas where the imagery either just
> isn't clear enough to untangle the ambiguities, or is clear but isn't
> recent enough.
>
> Personally, I've recently been trying to concentrate on a mixture of
> areas with less than 10% coverage, and on the lightly-mapped LSOA
> hotspots that my tool picked out.
>
> Cheers,
>
> Gregory
>
> On Thu, 2020-07-02 at 18:56 +0100, SK53 wrote:
> > We passed a couple of milestones a few days ago:
> > 20% of FIT totals
> > 170k individual panels mapped (excluding those in solar farms)
> > In terms of coverage there are now well over 50 LAs (all in England &
> > Wales) with more than 50% of solar installations mapped, with around
> > 10 exceeding 80%. Areas with good coverage are:
> > Scottish Central Belt: helped no doubt by more atomic data much of
> > the Central Belt is around 20% mapped.
> > North-East (former Tyne & Wear): Newcastle, Gateshead, Sunderland and
> > North & South Tyne.
> > North Wales: Conwy, Flint, Denbigh & Wrexham. Most panels in the
> > first three are in the coastal resort towns, but reasonable rural
> > coverage.
> > North West: recent activity has been around Preston, Blackburn Wigan
> > and Chorley.
> > East Midlands: mainly Leics & Notts. Improved & recent imagery for
> > Leicester made a huge difference.
> > West Midlands: Warwickshire, Worcestershire & Herefordshire are
> > roughly in the 20-30% zone. ALso extending into the South Wales
> > valleys. brianboru's detailed mapping in the latter is another good
> > index of rural coverage.
> > South Coast: Bournemouth area & Southampton, all at over 50%
> > More rural areas continue to be challenging: older imagery which is
> > often difficult to interpret doesn't help. I've experimented in
> > places where every building is already mapped by stepping through
> > each building, but still one may only find 20% of the number in FIT.
> >
> > London and immediately adjacent areas also have relatively little
> > mapped. Imagery can be a problem, but also finding panels in older
> > and/or larger housing with more complex roof shapes is hard.
> >
> > One thing I'm continually amazed at is how many places have buildings
> > mapped, which is very helpful for this task. However in a couple of
> > places: Ribble Valley & Leicester - it is clear that better imagery
> > would allow existing building outlines to be improved, but also that
> > plenty of buildings have been extended, demolished or replaced. This
> > type of activity lends itself to combined work using tools such as
> > Tasking Manager or MapRoulette and might be worth considering in the
> > future for a quarterly project.
> >
> > There's still no shortage of places where a lot of panels can be
> > mapped quickly, although more systematic mapping of a single LA often
> > requires a couple of passes over imagery.
> >
> > Looking forward to achieving the next milestones of 200k & 25%.
> >
> > Jerry
> >
> > Personally, I'm concentrating on areas adjacent to the existing well-
> > mapped (50%+) areas with the aim of extending these areas.
> >
> > ___
> > 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

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

Re: [Talk-GB] UPRN Locations Map

[Nick]

Hi Mark

I was wondering in the future if street names etc. could be derived from 
Mapillary (attribution source=Mapillary) where images exist?


Cheers

Nick

On 04/07/2020 12:02, Mark Goodge wrote:



On 04/07/2020 06:16, Kai Michael Poppe - OSM wrote:


So, a few months ago I stumbled upon a note
(https://www.openstreetmap.org/note/2158104#map=19/51.49829/-0.32762)
that StreetComplete left saying, that the street couldn't be given a
name because there's none shown.

Back then, I used streetmap.co.uk
(https://www.streetmap.co.uk/map.srf?X=516161=179063=Y=106) in
hopes to finding something - but only got "FAI RD." which - to me -
makes no sense.

Also, using https://os.openstreetmap.org/ makes it look like that's just
an access path to houses around it, which is (IMHO) not entirely true as
the way directly linking Southdown Av. and Boston Rd. clearly is
publicly accessible.

Now, using the above mentioned map
(https://osm.mathmos.net/addresses/uprn/#19/51.4983/-0.3279) I now know,
that this street has the UPRN ID 12145988.


That may not be the UPRN of the path or street. It may be the UPRN of 
the open space that the path runs through. The path is more likely to 
have a USRN (unique street reference number) than a UPRN.


To find the USRN of the path, you need to use the lookup tables 
supplied by OS. Doing that, we find that the associated USRN is 20602512.


Now, there's no open data source which will directly tell you the name 
of a USRN (at least, not until we start putting them into OSM). The 
long way of doing so is to find the matching LineString in OS OpenMap 
Local, and see what name it has there.


However, it can be done directly via a non-open source. If you go to 
https://www.findmystreet.co.uk/map and zoom in on the location, then 
click the street to bring up the USRN details, it will give the name 
(and also confirm that the USRN from the OS lookup table is correct). 
Or use the search box and search for USRN 20602512.


From an OSM point of view, that would normally be a dead end. Even if 
you can view the information on a non-open source, you can't 
incorporate it into OSM. However, in this case, we already have an 
abbreviated name from an open source. So all we are learning from the 
closed source is the full text of the abbreviation. Whether that makes 
it acceptable to include the full name into OSM is a matter of debate. 
I'll leave that decision up to others, but, for reference, the name of 
the street is Fairfield Road.


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 Locations Map

[Kai Michael Poppe - OSM]

Hi Marc,

Thanks for the reply. I'll make it my task to find an out of date copyright map 
that brings the full name, wherever I might find it :)

Have a great weekend!

Kai

Am 4. Juli 2020 13:02:59 MESZ schrieb Mark Goodge :
>
>
>On 04/07/2020 06:16, Kai Michael Poppe - OSM wrote:
>> 
>> So, a few months ago I stumbled upon a note
>> (https://www.openstreetmap.org/note/2158104#map=19/51.49829/-0.32762)
>> that StreetComplete left saying, that the street couldn't be given a
>> name because there's none shown.
>> 
>> Back then, I used streetmap.co.uk
>> (https://www.streetmap.co.uk/map.srf?X=516161=179063=Y=106) in
>> hopes to finding something - but only got "FAI RD." which - to me -
>> makes no sense.
>> 
>> Also, using https://os.openstreetmap.org/ makes it look like that's just
>> an access path to houses around it, which is (IMHO) not entirely true as
>> the way directly linking Southdown Av. and Boston Rd. clearly is
>> publicly accessible.
>> 
>> Now, using the above mentioned map
>> (https://osm.mathmos.net/addresses/uprn/#19/51.4983/-0.3279) I now know,
>> that this street has the UPRN ID 12145988.
>
>That may not be the UPRN of the path or street. It may be the UPRN of 
>the open space that the path runs through. The path is more likely to 
>have a USRN (unique street reference number) than a UPRN.
>
>To find the USRN of the path, you need to use the lookup tables supplied 
>by OS. Doing that, we find that the associated USRN is 20602512.
>
>Now, there's no open data source which will directly tell you the name 
>of a USRN (at least, not until we start putting them into OSM). The long 
>way of doing so is to find the matching LineString in OS OpenMap Local, 
>and see what name it has there.
>
>However, it can be done directly via a non-open source. If you go to 
>https://www.findmystreet.co.uk/map and zoom in on the location, then 
>click the street to bring up the USRN details, it will give the name 
>(and also confirm that the USRN from the OS lookup table is correct). Or 
>use the search box and search for USRN 20602512.
>
> From an OSM point of view, that would normally be a dead end. Even if 
>you can view the information on a non-open source, you can't incorporate 
>it into OSM. However, in this case, we already have an abbreviated name 
>from an open source. So all we are learning from the closed source is 
>the full text of the abbreviation. Whether that makes it acceptable to 
>include the full name into OSM is a matter of debate. I'll leave that 
>decision up to others, but, for reference, the name of the street is 
>Fairfield Road.
>
>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 Locations Map

[SK53]

I've tried to match UPRNs to buildings 1:1 in Nottingham and therefore
provide an address lookup. Here's the first stab of 35 k objects:
https://raw.githubusercontent.com/SK53/osm_uprn/master/ng_osm_uprn_lu.csv

Jerry

On Sat, 4 Jul 2020 at 12:28, Mark Goodge  wrote:

>
>
> On 04/07/2020 12:16, Stephen Knox wrote:
> > I don't think there is value in bringing in the points themselves but
> > I think there definitely is value in tagging existing buildings /
> > locations with the UPRN where it is incontrovertible - e.g. a single
> > unit house. This is the vast majority of the buildings in the UK, if
> > not the addresses. There are difficulties to overcome with multiple
> > unit buildings, that probably needs a lot of further thought and
> > possibly further open data releases to do properly, which may appear
> > eventually. How historical values are managed is also a consideration
> > to deal with.
>
> I agree. I think we have to bear in mind that UPRNs will become
> increasingly important to map users, and having them in the tag data
> will be useful. If it's a known fact about a building, then it does no
> harm, and will be potentially beneficial, to tag the building with the
> UPRN.
>
> But we do need to be wary of historic data and overlapping UPRNs. Unless
> we have incontrovertible local knowledge from a compatible source, then
> we shouldn't add a UPRN tag if the open data is in any way ambiguous.
>
> The same applies to USRNs. Where we can unambiguously match a road or
> street on OSM to a USRN, then we should add the tag. But only if we can
> be certain.
>
> > Arguably of more use for OSM for the here and now is the change to
> > the licence of the UK Land Registry INSPIRE polygons to OGL, which I
> > haven't seen much or any discussion of on this list. This means that
> > we now have an authoritative reference for boundaries and can use
> > that to alter and check geometries of things like semi-detached house
> > boundaries, gardens, hedges
> > etc.https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.
>
> I agree with that, too.
>
> 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 Locations Map

[David Woolley]

On 04/07/2020 11:45, Lester Caine wrote:
At the very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced


How does this differ from how OSM already works?  You can already create 
versions of the map at any point in its history, except where data has 
been redacted for legal reasons.


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

Re: [Talk-GB] UPRN Locations Map

[Ed Loach]

I'd suggest only add it to buildings where the address already exists and there 
is a one to one mapping, so we can use unmatched values to see where needs 
surveying.

Ed

Get Outlook for Android


From: Stephen Knox 
Sent: Saturday, July 4, 2020 12:16:38 PM
To: talk-gb@openstreetmap.org 
Subject: [Talk-GB] UPRN Locations Map


On 04/07/2020 08:51, Stephen Colebourne wrote:
> I'm not convinced this data should be pulled into OSM. It would add a
> lot of clutter that users would be tempted to move around or delete. In
> areas like mine where I've added thousands of buildings and addresses
> from surveys, it would be making matters worse not better. It would be a
> disincentive to adding more buildings with addresses as the additional
> nodes would get in the way of editing, and because they represent a semi
> random set of things. Because the dataset is fixed I would think it
> should be a layer used alongside OSM by those tools that think it adds
> value. Ideally, OSM itself should support layers, but AFAIK it doesn't.

I don't think there is value in bringing in the points themselves but I think 
there definitely is value in tagging existing buildings / locations with the 
UPRN where it is incontrovertible - e.g. a single unit house. This is the vast 
majority of the buildings in the UK, if not the addresses. There are 
difficulties to overcome with multiple unit buildings, that probably needs a 
lot of further thought and possibly further open data releases to do properly, 
which may appear eventually. How historical values are managed is also a 
consideration to deal with.

UPRNs will not bring any obvious value initially, but will gradually make OSM 
much more useful for the commercial sector, hopefully for everyone's benefit, 
as they can match IDs from proprietary datasets with Open OSM data, and it also 
enables OSM to be used an an authoritative ID for every building - neither 
postcodes nor addresses do that.

Arguably of more use for OSM for the here and now is the change to the licence 
of the UK Land Registry INSPIRE polygons to OGL, which I haven't seen much or 
any discussion of on this list. This means that we now have an authoritative 
reference for boundaries and can use that to alter and check geometries of 
things like semi-detached house boundaries, gardens, hedges etc. 
https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.

Stephen


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

Re: [Talk-GB] UPRN Locations Map

[Mark Goodge]

On 04/07/2020 12:16, Stephen Knox wrote:

I don't think there is value in bringing in the points themselves but
I think there definitely is value in tagging existing buildings /
locations with the UPRN where it is incontrovertible - e.g. a single
unit house. This is the vast majority of the buildings in the UK, if
not the addresses. There are difficulties to overcome with multiple
unit buildings, that probably needs a lot of further thought and
possibly further open data releases to do properly, which may appear
eventually. How historical values are managed is also a consideration
to deal with.


I agree. I think we have to bear in mind that UPRNs will become 
increasingly important to map users, and having them in the tag data 
will be useful. If it's a known fact about a building, then it does no 
harm, and will be potentially beneficial, to tag the building with the UPRN.


But we do need to be wary of historic data and overlapping UPRNs. Unless 
we have incontrovertible local knowledge from a compatible source, then 
we shouldn't add a UPRN tag if the open data is in any way ambiguous.


The same applies to USRNs. Where we can unambiguously match a road or 
street on OSM to a USRN, then we should add the tag. But only if we can 
be certain.



Arguably of more use for OSM for the here and now is the change to
the licence of the UK Land Registry INSPIRE polygons to OGL, which I
haven't seen much or any discussion of on this list. This means that
we now have an authoritative reference for boundaries and can use
that to alter and check geometries of things like semi-detached house
boundaries, gardens, hedges
etc.https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.


I agree with that, too.

Mark

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

[Talk-GB] UPRN Locations Map

[Stephen Knox]

On 04/07/2020 08:51, Stephen Colebourne wrote:
>* I'm not convinced this data should be pulled into OSM. It would add a
*>* lot of clutter that users would be tempted to move around or delete. In
*>* areas like mine where I've added thousands of buildings and addresses
*>* from surveys, it would be making matters worse not better. It would be a
*>* disincentive to adding more buildings with addresses as the additional
*>* nodes would get in the way of editing, and because they represent a semi
*>* random set of things. Because the dataset is fixed I would think it
*>* should be a layer used alongside OSM by those tools that think it adds
*>* value. Ideally, OSM itself should support layers, but AFAIK it doesn't.*

I don't think there is value in bringing in the points themselves but
I think there definitely is value in tagging existing buildings /
locations with the UPRN where it is incontrovertible - e.g. a single
unit house. This is the vast majority of the buildings in the UK, if
not the addresses. There are difficulties to overcome with multiple
unit buildings, that probably needs a lot of further thought and
possibly further open data releases to do properly, which may appear
eventually. How historical values are managed is also a consideration
to deal with.

UPRNs will not bring any obvious value initially, but will gradually
make OSM much more useful for the commercial sector, hopefully for
everyone's benefit, as they can match IDs from proprietary datasets
with Open OSM data, and it also enables OSM to be used an an
authoritative ID for every building - neither postcodes nor addresses
do that.

Arguably of more use for OSM for the here and now is the change to the
licence of the UK Land Registry INSPIRE polygons to OGL, which I
haven't seen much or any discussion of on this list. This means that
we now have an authoritative reference for boundaries and can use that
to alter and check geometries of things like semi-detached house
boundaries, gardens, hedges etc.
https://www.gov.uk/guidance/inspire-index-polygons-spatial-data.

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

Re: [Talk-GB] UPRN Locations Map

[Mark Goodge]

On 04/07/2020 06:16, Kai Michael Poppe - OSM wrote:


So, a few months ago I stumbled upon a note
(https://www.openstreetmap.org/note/2158104#map=19/51.49829/-0.32762)
that StreetComplete left saying, that the street couldn't be given a
name because there's none shown.

Back then, I used streetmap.co.uk
(https://www.streetmap.co.uk/map.srf?X=516161=179063=Y=106) in
hopes to finding something - but only got "FAI RD." which - to me -
makes no sense.

Also, using https://os.openstreetmap.org/ makes it look like that's just
an access path to houses around it, which is (IMHO) not entirely true as
the way directly linking Southdown Av. and Boston Rd. clearly is
publicly accessible.

Now, using the above mentioned map
(https://osm.mathmos.net/addresses/uprn/#19/51.4983/-0.3279) I now know,
that this street has the UPRN ID 12145988.


That may not be the UPRN of the path or street. It may be the UPRN of 
the open space that the path runs through. The path is more likely to 
have a USRN (unique street reference number) than a UPRN.


To find the USRN of the path, you need to use the lookup tables supplied 
by OS. Doing that, we find that the associated USRN is 20602512.


Now, there's no open data source which will directly tell you the name 
of a USRN (at least, not until we start putting them into OSM). The long 
way of doing so is to find the matching LineString in OS OpenMap Local, 
and see what name it has there.


However, it can be done directly via a non-open source. If you go to 
https://www.findmystreet.co.uk/map and zoom in on the location, then 
click the street to bring up the USRN details, it will give the name 
(and also confirm that the USRN from the OS lookup table is correct). Or 
use the search box and search for USRN 20602512.


From an OSM point of view, that would normally be a dead end. Even if 
you can view the information on a non-open source, you can't incorporate 
it into OSM. However, in this case, we already have an abbreviated name 
from an open source. So all we are learning from the closed source is 
the full text of the abbreviation. Whether that makes it acceptable to 
include the full name into OSM is a matter of debate. I'll leave that 
decision up to others, but, for reference, the name of the street is 
Fairfield Road.


Mark

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 08:51, Stephen Colebourne wrote:
I'm not convinced this data should be pulled into OSM. It would add a 
lot of clutter that users would be tempted to move around or delete. In 
areas like mine where I've added thousands of buildings and addresses 
from surveys, it would be making matters worse not better. It would be a 
disincentive to adding more buildings with addresses as the additional 
nodes would get in the way of editing, and because they represent a semi 
random set of things. Because the dataset is fixed I would think it 
should be a layer used alongside OSM by those tools that think it adds 
value. Ideally, OSM itself should support layers, but AFAIK it doesn't.


That about sums it up. The plans themselves may be a starting point 
where there is nothing, but ALL that needs importing are the references 
being added to existing objects in OSM. As you say, the data in the NLPG 
data set is 'read only' and so anybody 'editing mistakes' may not 
understand that it is displaying what is the 'legal' situation on the 
ground. Any mistakes need to be reported to the right authority.


That OSM does not support layers is now a major stumbling block. At the 
very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced, but with 
the growing volume of other data sources with detailed graphical 
content, being able to combine layers of data should be a high priority. 
There should then be no need to import snapshots of those managed data 
sets and have to maintain mechanisms to keep the two in sync. Just use 
the raw data direct in parallel with the unique OSM data.


It is worth pointing out that unless something has changed drastically 
in the last few years, then the range of fine detail contained in the 
NLPG varies vastly between the various council sources. I think I have 
seen comments about 'only having a node' and not providing enough detail 
to identify different references. Certainly 10 years ago only a small 
number of councils actually had plans of the extent of each council tax 
parcel and other fine detail. Most just had a node somewhere in the 
right area. Many were reliant on paid services from OS for map data and 
so did not have a licence to copy that data over. HOPEFULLY today that 
particular problem has been resolved.


I've not had time yet to look at just what is available against the now 
somewhat out of data local extracts I have from the original NLPG dataset.


--
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 Locations Map

[SK53]

The new Leicester Coronavirus Regulations

provide some interesting test data, ostensibly under a Open Government
Licence, of 24 pages of postcodes and what are obviously individual
properties where postcodes are split by the boundary captured by querying
UPRNs (telephone & post boxes are a useful clue). For instance Welford Road
in Wigston (on p. 34) corresponds to this area
 on Robert's
site. Postcode LE18 3TE seems to extend from the junction of Welford Road
with Guthlaxton Lane down to the Navigation at Kilby Bridge. I've just
added the telephone (from this Mapillary
 image) which is
presumably UPRN 10025590850.

Given this looks to have been created by querying for objects via MasterMap
or similar I imagine the actual data is in practice covered by GeoPlace &
OSGB restrictions.

Nonetheless there are a few intriguing things mentioned which I cant locate
on OSM, including Lime Delph Road (which is probably the frontage road on
the new housing estate with unnamed road on the E). Nor is the nursery
obvious.

Jerry

On Sat, 4 Jul 2020 at 09:48, Jez Nicholson  wrote:

> From Wikidata, https://m.wikidata.org/wiki/Property:P8399 if you query
> the UK Flood service with the UPRN you can see more detail on the property
>
> On Sat, 4 Jul 2020, 08:52 Stephen Colebourne, 
> wrote:
>
>> I'm not convinced this data should be pulled into OSM. It would add a lot
>> of clutter that users would be tempted to move around or delete. In areas
>> like mine where I've added thousands of buildings and addresses from
>> surveys, it would be making matters worse not better. It would be a
>> disincentive to adding more buildings with addresses as the additional
>> nodes would get in the way of editing, and because they represent a semi
>> random set of things. Because the dataset is fixed I would think it should
>> be a layer used alongside OSM by those tools that think it adds value.
>> Ideally, OSM itself should support layers, but AFAIK it doesn't.
>> Stephen
>> PS. Thanks for the slippy map!
>>
>> On Thu, 2 Jul 2020, 17:38 Robert Whittaker (OSM lists), <
>> robert.whittaker+...@gmail.com> wrote:
>>
>>> I'm not completely sure if/how we can best make use of the new OS
>>> OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
>>> first step I've set up a quick slippy map with the UPRN locations
>>> shown:
>>>
>>> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show
>>> the data)
>>>
>>> The UPRN dataset literally just contains the UPRN number and its
>>> coordinates (both OS National Grid and WGS lat/lon). There are some
>>> additional linking datasets that link these ids to other ids (e.g.
>>> USRNs, TOIDs). But no address information is available directly. (You
>>> may be able to get street names by matching to OS Open Roads via TOIDs
>>> though. Coupled with Code-Point Open, you might be able to assign
>>> quite a few postcodes in cases where there's only one unit for a whole
>>> street.)
>>>
>>> The UPRN data has already helped me find a mapping error I made
>>> locally though -- it looks like I'd accidentally missed drawing a
>>> house outline from aerial imagery, and also classified a large garage
>>> a few doors down as a house. The two errors cancelled out when the
>>> houses were numbered sequentially, so I didn't notice until now. Today
>>> though I spotted a UPRN marker over some blank space on the map, and
>>> no marker over the mapped house that's probably a garage.
>>>
>>> Now a few initial thoughts on the data that I've explored so far:
>>>
>>> I believe that the UPRNs are assigned by local authorities, so
>>> conventions may vary from place to place. I don't know who actually
>>> assigns the coordinates (authority or OS). Looking at those for rows
>>> of houses around me, they don't seem to have been automatically given
>>> coordinates from the house footprint, it looks more like someone
>>> manually clicking on a map.
>>>
>>> The UPRN dataset should include all addressable properties. It is also
>>> ahead of reality in some places, as it includes locations for houses
>>> on a new development near me that have yet to be built yet. For blocks
>>> of apartments/flats, the UPRN nodes may all have the same coordinates
>>> or may be displaced from each other, possibly in an artificial manner.
>>>
>>> Other objects also appear to have UPRNs. Likely things I've noticed so
>>> far include: car parks, post boxes, telephone boxes (even after
>>> they've been removed), electricity sub-stations, roads and recorded
>>> footpaths (the UPRN locations seem to be at one end of the street, so
>>> usually lie at a junction), recreation grounds / play areas,
>>> floodlight poles (around sports pitches), and allotments. There's no
>>> information about the object type in the UPRN data unfortunately.
>>>
>>> Anyway, 

Re: [Talk-GB] UPRN Locations Map

[Jez Nicholson]

>From Wikidata, https://m.wikidata.org/wiki/Property:P8399 if you query the
UK Flood service with the UPRN you can see more detail on the property

On Sat, 4 Jul 2020, 08:52 Stephen Colebourne,  wrote:

> I'm not convinced this data should be pulled into OSM. It would add a lot
> of clutter that users would be tempted to move around or delete. In areas
> like mine where I've added thousands of buildings and addresses from
> surveys, it would be making matters worse not better. It would be a
> disincentive to adding more buildings with addresses as the additional
> nodes would get in the way of editing, and because they represent a semi
> random set of things. Because the dataset is fixed I would think it should
> be a layer used alongside OSM by those tools that think it adds value.
> Ideally, OSM itself should support layers, but AFAIK it doesn't.
> Stephen
> PS. Thanks for the slippy map!
>
> On Thu, 2 Jul 2020, 17:38 Robert Whittaker (OSM lists), <
> robert.whittaker+...@gmail.com> wrote:
>
>> I'm not completely sure if/how we can best make use of the new OS
>> OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
>> first step I've set up a quick slippy map with the UPRN locations
>> shown:
>>
>> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the
>> data)
>>
>> The UPRN dataset literally just contains the UPRN number and its
>> coordinates (both OS National Grid and WGS lat/lon). There are some
>> additional linking datasets that link these ids to other ids (e.g.
>> USRNs, TOIDs). But no address information is available directly. (You
>> may be able to get street names by matching to OS Open Roads via TOIDs
>> though. Coupled with Code-Point Open, you might be able to assign
>> quite a few postcodes in cases where there's only one unit for a whole
>> street.)
>>
>> The UPRN data has already helped me find a mapping error I made
>> locally though -- it looks like I'd accidentally missed drawing a
>> house outline from aerial imagery, and also classified a large garage
>> a few doors down as a house. The two errors cancelled out when the
>> houses were numbered sequentially, so I didn't notice until now. Today
>> though I spotted a UPRN marker over some blank space on the map, and
>> no marker over the mapped house that's probably a garage.
>>
>> Now a few initial thoughts on the data that I've explored so far:
>>
>> I believe that the UPRNs are assigned by local authorities, so
>> conventions may vary from place to place. I don't know who actually
>> assigns the coordinates (authority or OS). Looking at those for rows
>> of houses around me, they don't seem to have been automatically given
>> coordinates from the house footprint, it looks more like someone
>> manually clicking on a map.
>>
>> The UPRN dataset should include all addressable properties. It is also
>> ahead of reality in some places, as it includes locations for houses
>> on a new development near me that have yet to be built yet. For blocks
>> of apartments/flats, the UPRN nodes may all have the same coordinates
>> or may be displaced from each other, possibly in an artificial manner.
>>
>> Other objects also appear to have UPRNs. Likely things I've noticed so
>> far include: car parks, post boxes, telephone boxes (even after
>> they've been removed), electricity sub-stations, roads and recorded
>> footpaths (the UPRN locations seem to be at one end of the street, so
>> usually lie at a junction), recreation grounds / play areas,
>> floodlight poles (around sports pitches), and allotments. There's no
>> information about the object type in the UPRN data unfortunately.
>>
>> Anyway, I hope some of this is useful / interesting. I hope to be on
>> the OSMUK call on Saturday to discuss things further. Best wishes,
>>
>> Robert.
>>
>> --
>> Robert Whittaker
>> https://osm.mathmos.net/
>>
>> ___
>> 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
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN Locations Map

[Stephen Colebourne]

I'm not convinced this data should be pulled into OSM. It would add a lot
of clutter that users would be tempted to move around or delete. In areas
like mine where I've added thousands of buildings and addresses from
surveys, it would be making matters worse not better. It would be a
disincentive to adding more buildings with addresses as the additional
nodes would get in the way of editing, and because they represent a semi
random set of things. Because the dataset is fixed I would think it should
be a layer used alongside OSM by those tools that think it adds value.
Ideally, OSM itself should support layers, but AFAIK it doesn't.
Stephen
PS. Thanks for the slippy map!

On Thu, 2 Jul 2020, 17:38 Robert Whittaker (OSM lists), <
robert.whittaker+...@gmail.com> wrote:

> I'm not completely sure if/how we can best make use of the new OS
> OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
> first step I've set up a quick slippy map with the UPRN locations
> shown:
>
> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the
> data)
>
> The UPRN dataset literally just contains the UPRN number and its
> coordinates (both OS National Grid and WGS lat/lon). There are some
> additional linking datasets that link these ids to other ids (e.g.
> USRNs, TOIDs). But no address information is available directly. (You
> may be able to get street names by matching to OS Open Roads via TOIDs
> though. Coupled with Code-Point Open, you might be able to assign
> quite a few postcodes in cases where there's only one unit for a whole
> street.)
>
> The UPRN data has already helped me find a mapping error I made
> locally though -- it looks like I'd accidentally missed drawing a
> house outline from aerial imagery, and also classified a large garage
> a few doors down as a house. The two errors cancelled out when the
> houses were numbered sequentially, so I didn't notice until now. Today
> though I spotted a UPRN marker over some blank space on the map, and
> no marker over the mapped house that's probably a garage.
>
> Now a few initial thoughts on the data that I've explored so far:
>
> I believe that the UPRNs are assigned by local authorities, so
> conventions may vary from place to place. I don't know who actually
> assigns the coordinates (authority or OS). Looking at those for rows
> of houses around me, they don't seem to have been automatically given
> coordinates from the house footprint, it looks more like someone
> manually clicking on a map.
>
> The UPRN dataset should include all addressable properties. It is also
> ahead of reality in some places, as it includes locations for houses
> on a new development near me that have yet to be built yet. For blocks
> of apartments/flats, the UPRN nodes may all have the same coordinates
> or may be displaced from each other, possibly in an artificial manner.
>
> Other objects also appear to have UPRNs. Likely things I've noticed so
> far include: car parks, post boxes, telephone boxes (even after
> they've been removed), electricity sub-stations, roads and recorded
> footpaths (the UPRN locations seem to be at one end of the street, so
> usually lie at a junction), recreation grounds / play areas,
> floodlight poles (around sports pitches), and allotments. There's no
> information about the object type in the UPRN data unfortunately.
>
> Anyway, I hope some of this is useful / interesting. I hope to be on
> the OSMUK call on Saturday to discuss things further. Best wishes,
>
> Robert.
>
> --
> Robert Whittaker
> https://osm.mathmos.net/
>
> ___
> 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