Re: [Talk-GB] UK street addressing

2020-12-21 Thread Mark Goodge



On 21/12/2020 15:07, Andy Mabbett wrote:

On Mon, 21 Dec 2020 at 12:50, Colin Smale  wrote:


Royal Mail say that a house number must be numeric, and anything else
(like Rose Cottage, 7A, 3-7, 11/13 etc) should go in the house name field.


So in  a row of three adjacent, identical houses, known as 11, 11A,
and 15, two have numbers and one has a name? That's not logical.


You have to bear in mind here that the point of Royal Mail's addressing 
system is to get post from origin to destination. It isn't intended to 
provide a consistent means of labelling adjacent properties.


The full PAF has 20 different fields. Some of those are always populated 
for every postal address. Others are usually blank, and only 
occasionally populated. And some are either blank or have a value 
depending on circumstances.


One of the reasons there are so many fields is that each field only ever 
contains a single type of data. There are no multi-purpose fields. So 
there are separate fields for name and number. And "number" is defined 
internally as an integer value, precisely in order to make it impossible 
to put anything other than a number into it. Which means, therefore, 
that something like 7A, or 7-11, has to go into the name field as the 
database simply won't allow it to go into the number.


In practice, though, that makes no difference to users as that 
distinction is handled internally by the PAF software. When displayed, 
the name and/or number will be shown on screen (or printed on paper) in 
the same output position on the address, either concatenated (if both 
are present) or either/or (if only one is).


There's absolutely no need to replicate that complexity on a non-PAF 
database, such as OSM. For almost all practical purposes, name/number 
can be a single field.


Mark

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


Re: [Talk-GB] Anglican churches

2020-12-21 Thread Mark Goodge



On 18/12/2020 19:01, Robert Whittaker (OSM lists) wrote:


https://osm.mathmos.net/nameless/amenity/place_of_worship . I think a
lot of them may have been armchair-mapped from possibly out of date
maps. So if anyone is at a loose end and fancies trying to work out if
the places of worship listed there are still in use and if so what
their name is, please have a look.


I've fixed one of them! Not by adding a name, though, but by removing 
the tag. They're a pair of former cemetery chapels that are no longer 
used for that purpose, instead, they're just used as storage by the 
local council.


Mark

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


Re: [Talk-GB] Anglican churches

2020-12-18 Thread Mark Goodge



On 18/12/2020 18:03, Sean Blanchflower wrote:


In addition there are many more mapped with various tags (by others) 
which are in fact closed or redundant churches. I've been marking them 
as disused:amenity=place_of_worship when I come across them, but there 
are still many more that I haven't got to. (I may get round to this at 
some point)


Just out of interest, do we have a consistent tagging scheme for 
churches which are officially redundant but are still consecrated and 
used for other events as well as occasional worship services?


I'm thinking here mainly of CofE buildings that are now maintained by 
the Churches Conservation Trust rather than a local parish or diocese, 
although there are some equivalents from other denominations as well. 
They're not exactly disused, because they are all usually open to the 
public and often host events, including worship services, but they no 
longer host regular parish services and have no resident congregation or 
assigned priest.


So disused:amenity=place_of_worship seems wrong, to me. I think the 
'disused' key is more correct for a former church that is no longer open 
to the public or in use at all, either because it's now privately owned 
or is functionally derelict. But I'm not sure what would be a better 
option for one that is in use but, from a CofE perspective, is 
considered redundant.


Mark


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


Re: [Talk-GB] "GPS trace" tracking county boundary

2020-12-14 Thread Mark Goodge



On 14/12/2020 17:49, Martin Wynne wrote:

On 14/12/2020 17:27, Edward Bainton wrote:
Any thoughts on why when I enable "public GPS traces" in iD, I get one 
that
near enough exactly tracks the LA boundary South Kesteven:Peterborough 
(at

Deeping St James)?



Someone took their tracker with them when "Beating the Bounds"?


In a canoe?

Mark

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


Re: [Talk-GB] driveway-becomes-track

2020-12-12 Thread Mark Goodge



On 12/12/2020 12:34, Martin Wynne wrote:
A common situation is that a service road/driveway continues as a track 
beyond the initial residential destination. This is common on farms.


On the standard map at zoom level 15, driveways are not shown. But 
tracks and footpaths are. This seems counter-intuitive in that driveways 
are usually wider and more substantially surfaced than farm tracks.


The result is that a track, and sometimes a footpath, appears to start 
in the middle of nowhere.


An example of that is at:

  https://www.openstreetmap.org/#map=15/52.2816/-2.4320

What is the process for getting something done about this?


I wouldn't tag that as a driveway. I'd tag it as a track or a service 
road. That's not tagging for the renderer, it's tagging according to 
common usage. A driveway, these days, at least in the UK, generally 
means a short section of off-street parking attached to an urban 
dwelling. Out in a rural area, nearly everybody would call that length 
of road, especially one that links a public highway with private farm 
tracks, a track or access road.


The wiki seems to agree with me in this scenario, saying that "It is 
rare for a driveway to be the way to access another roadway". If it is 
the access to another roadway extending beyond it (eg, a farm track) 
then it's not a driveway, it's an access road and should be tagged 
accordingly.


Mark

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


Re: [Talk-GB] Tagging of shared use paths

2020-12-10 Thread Mark Goodge



On 10/12/2020 14:08, Tony Shield wrote:

/Are there any public cycleways from which pedestrians are actually banned?
/

Unfortunately yes - https://www.openstreetmap.org/way/827379295

Quite clear signage - Mapillary - 
https://www.mapillary.com/app/?lat=53.66933432657343=-2.6290113968031967=17=_ir_HmYAIa4H0rnj1JrO8A=photo

//


Although, having said that, there's no equivalent prohibition sign when 
approaching that section from the other end. And the point where that 
cycleway crosses the M6 slip road is clearly signalled as a "Toucan" 
(pedestrians and cycles) crossing:


https://goo.gl/maps/gKBbuspimGe9ZjaAA

Since a route that you can use as a pedestrian in one direction but not 
the other would be somewhat absurd (and something that UK highway law 
makes no provision for), I'm more inclined to think that the sign at the 
Chorley end (at the intersection with Temple Way) does not, in fact, 
have legal force. It seems to me that it's more likely to be the result 
of an over-zealous highway officer getting the wrong signage installed.


Mark

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


Re: [Talk-GB] Tagging of shared use paths

2020-12-10 Thread Mark Goodge



On 10/12/2020 16:28, Ken Kilfedder wrote:

> I think there are enough items that look and act like a cycles-only
way to make it worth having a fourth item in your hierarchy- whatever
the legal position.


But route-finding software needs to know the legal position. Mapping 
something as cycles-only, when in fact it can also be used on foot, will 
break a lot of valid pedestrian routes.


Mark

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


Re: [Talk-GB] Tagging of shared use paths

2020-12-10 Thread Mark Goodge



On 10/12/2020 15:39, Phillip Barnett wrote:

“  any road that cars can use is also open to cyclists and
pedestrians ” Pedestrians? Are you sure about that? Yes, you can walk
along country roads that lack pavements, but try that in a town and
I’m pretty sure you’d get stopped quite quickly.


Legally, yes. Of course, if there is a separate footway then it would 
obviously be wiser to use it. But you are not breaking any law by 
walking in the carriageway. Unless it's a motorway or designated special 
road, with signage to explicitly indicate that pedestrians are not allowed.


Mark

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


Re: [Talk-GB] Tagging of shared use paths

2020-12-10 Thread Mark Goodge



On 10/12/2020 12:41, Ken Kilfedder wrote:
As a break from 'tagging for the renderer', I'd like to see rendering 
for the tags.  It would save a lot of heartarche if the map on osm.org 
showed shared-use paths explicitly.   


I entirely agree! I think the real problem here is that the standard OSM 
render simply doesn't handle highways restricted to non-motorised users 
very well at all, and hence there's a strong incentive to people to 
modify the tags to try and workaround that issue.


However...

Perhaps as follows:-


  * highway=cycleway with nothing to say that foot is allowed - blue
dashes as at present.
  * highway=footway with nothing to say bicyles are allowed - red dashes
as at present.
  * highway=cycleway with foot expressly allowed - blue/red dashed line
(maybe blue long dash interspersed with red short dash)
  * highway=footway with bikes expressly allowed - blue/red dashed line
(maybe red long dash interspersed with blue short dash)
  * With segregated=yes - possibly, at higher zoom levels, show blue
dashes in parallel with red - the right way round if possible.


...this distinction doesn't really exist in the UK. The default legal 
position for for any public highway in the UK is that any permission for 
any class of user also includes permission for any class of user prior 
to that in the hierarchy, unless explicitly stated (and signed) 
otherwise. The hierarchy in question being:


pedestrians
cyclists
horse riders and horse-drawn vehicles
motor vehicles

So any cycleway in the UK is also a footway, unless pedestrians are 
explicitly prohibited, and any road that cars can use is also open to 
cyclists and pedestrians (unless, again, they are explicitly prohibited, 
such as on motorways). There's certainly no general legal distinction 
between a cycleway that allows pedestrians and a footway that allows 
cycles - they are both, in law, exactly the same, and are both in law, a 
shared-use path. Even a segregated shared-use path is still legally 
usable across its entire width by pedestrians, even if that's typically 
discouraged.


Personally, I think the default OSM map render should follow that 
hierarchy, with minor highways and paths having a three-way distinction:


pedestrians only
pedestrians and cycles
all vehicles

(I'd disregard horses in this context, although tagging bridleways in 
rural areas would still be useful and it would be helpful to have that 
indicated somehow on the default render).


I think that would solve the issue here, and prevent a lot of anonymous 
notes.


Anyone know off hand where/how to propose this?  Or even willing to help 
on coding up a demo?


Another issue here is that the default OSM map render is intended to be 
global, but other countries don't necessarily have the same highway 
hierarchy as the UK. In some countries, cycleways that pedestrians are 
prohibited from using may be the norm (I have a feeling that is the case 
in The Netherlands, for example). This is one of the reasons why I think 
that the default render ought to be location-aware, in order to reflect 
different highway laws in different places.


But, also, it's a good reason to press on with creating a specifically 
UK stylesheet, so that OSM on a .uk domain looks different to that on a 
.org domain, with the former being styled to match British practice.


Mark

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


Re: [Talk-GB] Nominatim oddity

2020-12-07 Thread Mark Goodge



On 07/12/2020 17:34, Ken Kilfedder wrote:

That's the name in latin for the UK, I think.   Is it under name:la,
and do you have your browser set to latin for some reason?


No, my browser is set to English. But it does have Latin as one of 
several alternate languages. Odd that Nominatim seems to be using that 
rather than the browser's preferred language. Maybe it's parsing the 
language string back to front.


Mark

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


[Talk-GB] Nominatim oddity

2020-12-07 Thread Mark Goodge
This may be a dim question, and this may possibly be the wrong place to 
ask it. But, at the risk of being both dim and out of place... Why does 
Nominatim return "Britanniarum Regnum" as the country name for objects 
in the UK? For example:


https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=21279378=place

Mark

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


Re: [Talk-GB] featdesc & featcode

2020-11-19 Thread Mark Goodge



On 19/11/2020 16:35, George Honeywood wrote:

Hi,

I have a feeling it might be related to OS OpenData, perhaps from
importing without deleting the original tags.


Yes, if memory serves it's from the now defunct OS 50k gazetteer.

Mark

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


Re: [Talk-GB] UPRN wiki page

2020-11-19 Thread 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

2020-11-18 Thread 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

2020-11-17 Thread 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

2020-11-17 Thread 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

2020-11-17 Thread 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

2020-11-17 Thread 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


Re: [Talk-GB] Multi-lingual tagging in Wales

2020-10-31 Thread Mark Goodge



On 31/10/2020 11:03, Ben Proctor wrote:



Example:
name: Caernarfon
name:cy Caernarfon


That's not a particularly good example, as Caernarfon is the Welsh name. 
The English name is Caernarvon. But in this case, nobody, not even the 
English, uses the English name any more. The English version though, is 
found in a lot of historical documentation. So including it somewhere is 
probably appropriate.


I'm not sure, though, that name:en would be the right tag, as that 
implies that it's a name in current use. Do we have a way of tagging 
historic or archaic names? If so, then I'd use that for Caernarvon.


Mark

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


Re: [Talk-GB] High quality NLS imagery of buildings and HOUSENUMBERS (!) available in London (and Scotland). Create a tasking manger to add this?

2020-10-30 Thread Mark Goodge



On 30/10/2020 20:10, ipswichmapper--- via Talk-GB wrote:

Also, the messages by "Mark Goodge" and "Ken Kilfedder" (spiregrain) 
didn't show up in my email. Why is this? (Is it because their "reply 
all" didn't include my address by mistake?) I'm still getting used to 
mailing lists.


I didn't do a "reply all". I did a "reply list". That's how lists are 
supposed to work! You'll see my reply as part of the normal list 
traffic, not as a direct reply to you.


The https://lists.openstreetmap.org/pipermail/ website sorts the mails 
into "threads". How does it which email goes under which thread? 
Currently, when I hit "reply all" it shows in the archive my email 
underneath the right thread. I am assuming it know based on who I sent 
the email to. However, if the same person were to reply twice to my 
email, and then I replied to one of their emails, how would the 
archiving system know which email I replied to?


The archives will include anything that has the address 
'talk-gb@openstreetmap.org' in the To or CC lines (not sure about Bcc, 
and I can't be bothered to check!). But all list messages should, as a 
general rule, be replied to on-list - that is, by sending your reply to 
the list address, not the address of the sender. You should only reply 
directly to the sender if you need to contact them off-list.


Mark

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


Re: [Talk-GB] High quality NLS imagery of buildings and HOUSENUMBERS (!) available in London (and Scotland). Create a tasking manger to add this?

2020-10-30 Thread Mark Goodge



On 30/10/2020 18:37, Mateusz Konieczny via Talk-GB wrote:




Oct 30, 2020, 16:28 by talk-gb@openstreetmap.org:

It has come to my attention that the "Town Plan" map from 1944-1967
in NLS is available freely.

What are its licensing terms?

"available freely" does not mean "compatible with OSM license"


It's out of copyright, so there aren't any licensing issues in deriving 
data from it.


I would, though, be a little reluctant to use it as a basis for 
wholesale numbering without any supporting local knowledge or survey. 
House numbers can, and sometimes do, change, particularly when streets 
are renamed or rebuilt. So you can't be 100% certain that a house number 
in the 1950s is the same number it is now, even if the building is still 
the same.


Mark

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


[Talk-GB] Mapping a building that's two connected separate buildings

2020-10-12 Thread Mark Goodge
I was looking at tidying up a few things around my local area, and came 
across this:


https://www.openstreetmap.org/#map=19/52.08855/-1.94195

What you can see there is a building labelled "Evesham Hotel" (which is 
correct), and, just to the south-west of it, another, unlabelled building.


However, look at the aerial view (eg, via the edit feature, although 
Google Maps will do just as well), and it's clear that there is a link 
building connecting the two (something which I can confirm from local 
knowledge):


https://www.openstreetmap.org/edit#map=19/52.08855/-1.94195

(There's also an unmapped extension to the bottom left building, but 
that's another matter).


That's because, many years ago when the manor house was converted to a 
hotel, the owners expanded the hotel by building the link to the 
adjacent building so that it's all one building internally (more of the 
accommodation is in the bottom left building, the original manor house 
is mostly reception, function and dining rooms and associated non-public 
areas such as kitchens and offices).


So, how should this be mapped? Should the entire hotel, covering both 
original buildings and the later link building, be mapped as a single 
polygon? Or should they be mapped as three adjacent, but separate, 
polygons? Is there a standard way of approaching situations like this?


Mark

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


Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Mark Goodge



On 28/09/2020 10:00, Frederik Ramm wrote:


Remember: OSM is not an IT project.


Indeed not. But this is also a good example of the truism that OSM is 
not a map, it's a database. Having the right data in the database 
matters. Fixing clear and obvious errors, such as invalid URLs in a 
"website" tag, seems to me to be a worthwhile project if someone is 
prepared to put the time and effort into doing it.


Mark

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


Re: [Talk-GB] Jewson - is it shop=doityourself or shop=trade?

2020-09-18 Thread Mark Goodge



On 18/09/2020 21:27, Mateusz Konieczny via Talk-GB wrote:

I encountered https://github.com/osmlab/name-suggestion-index/issues/4140
and it is hard to me how it should be decided.


I'd say that Jewson is primarily a trade outlet. Although they do 
advertise themselves to the consumer (DIY) market, the reality is that 
the majority of their revenue, and the largest part of their customer 
base, is trade.


FWIW, I'd also say that Screwfix, Selco, Travis Perkins, Buildbase and 
Plumbase are also trade, but B, Wilko and Wickes are consumer. All of 
them do operate in both markets, so it is something of a judgment call 
for all of them. But they do, generally, focus more on one side than the 
other.


(I used to work for a division of the parent company that owns 
Buildbase, Selco and Plumbase - I'm partly responsible for parts of the 
Buildbase and Plumbase websites - and we were pretty clear in our minds 
about which companies were our trade competitors and which were our 
consumer competitors).


Mark

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


Re: [Talk-GB] Flatholm Island Boundary Problem

2020-09-12 Thread Mark Goodge



On 12/09/2020 21:23, Russ Garrett wrote:

I've foolishly now decided to try to get to the bottom of it - the
beating of the bounds still doesn't explain why exactly it covers that
area (although I'm impressed that the Lord Mayor managed to commandeer
a warship to do so!)


AIUI, it's because it's the historic maritime navigation route into 
Bristol and Avonmouth. The simplified constituency boundary map is, 
possibly a little bizarrely, one of the best visualisations of that:


https://members.parliament.uk/constituency/3368/location

See also this Admiralty chart for the Bristol Channel - you can see that 
the "Bristol Deep" channel passes between the two islands and leads into 
the harbour:


https://cdn.shopify.com/s/files/1/0278/1529/products/OCB-1179.jpg

Mark

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


Re: [Talk-GB] Flatholm Island Boundary Problem

2020-09-12 Thread Mark Goodge



On 12/09/2020 21:11, Rob Nickerson wrote:
"extremely stupid reasons" in this case relates to an very old tradition 
where the Lord Mayor of Bristol 'beats the bounds' of the city by 
rowing/sailing out to the islands.


As a consequence a small wedge of the city of Bristol bounds lies within 
Welsh water.


See also this rather oddly shaped map of the Bristol North West 
constituency:


https://members.parliament.uk/constituency/3368/location

Mark

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


Re: [Talk-GB] Street-name toids

2020-08-13 Thread Mark Goodge



On 13/08/2020 15:30, Nick wrote:
On delving deeper, it looks as if my comment is a load of rubbish. UPRNs 
that are listed do include huge numbers of adopted roads - so if we 
could have a list of these and other 'non-addressable' UPRNs, it would 
help users identify relevant ones


How are you identifying that the UPRNs in question are current (ie, not 
"historic") and are actually assigned to the street as a whole and not 
some specific artifact on it?


Mark

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


Re: [Talk-GB] Street-name toids

2020-08-13 Thread Mark Goodge



On 13/08/2020 13:34, I wrote:


The TOIDs in those datasets can then be cross-referenced against OS 
OpenNames to give the OS name for the linked USRNs. Although this isn't, 
always, the same as the official USRN name of the street, which can be 
confusing. But that's because OS (like OSM) maps what is visible, rather 
than necessarily what is documented, and if a street has a name by which 
it is commonly referred to then that's what goes on the OS maps even if 
it has a different name in the USRN.


Just as an aside to that, there are just over 92,000 USRNs in the Open 
USRN database that are linked to both a named road in OpenNames (via the 
TOIDS LID) and have a name in the NSG, but those two names are not the same.


In a lot of cases that's a simple translation difference - OpenNames is 
English-only, but the NSG uses local names (eg, in Welsh) where 
different to English. Others are relatively minor disagreements over 
spelling (eg, Aaron's Hill v Aarons Hill or Abbey Fields v Abbeyfields). 
The NSG also differentiates, in some cases, between different 
carriageways of dual carriageways, so it has, for example, both Abbey 
Hill Westbound and Abbey Hill Eastbound where OpenNames only has Abbey 
Hill. But, even after excluding these, there are still a significant 
number of streets where the OpenNames name and the NSG name are 
completely different.


I haven't dug particularly deeply into this, as the NSG list of street 
names, although readily available, isn't open data so it's not a lot of 
practical use for my purposes (or, for that matter, OSM). But it is an 
illustration of how even the "official" name of something is not 
necessarily the "correct" name. The naming of roads is a difficult 
matter, it isn't just one of your armchair map games :-)


Mark

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


Re: [Talk-GB] Street-name toids

2020-08-13 Thread Mark Goodge



On 13/08/2020 11:25, Robert Whittaker (OSM lists) wrote:

On Wed, 12 Aug 2020 at 16:56, SK53  wrote:

OpenRoads from the Ordnance Survey contains a field containing the toid for the 
street name. I wonder if we should include these alongside usrn & uprn. They 
may be more useful than either for gathering complex roads which share a name.


I'd tend to see the TOIDs are just an internal ID used in OS MasterMap
and not something that there's much value in adding to OSM. I'd have
thought that that USRN should be a sufficient unique reference number
for highways. (Everything in OS MasterMap has a TOID, and actually I
think streets have two -- one for the centreline geometry, and one for
the bounding polygon. If we start adding TOIDs for streets, where
would we stop?)


A street will have multiple TOIDs if it has multiple names. For example, 
USRN 21, part of the A27 Shoreham By-Pass, is linked to TOIDs 
osgb400023625257 and osgb400030480763 - the first for the 
number,m the second for the name.



However, from a practical point of view, if you want to check OSM for
completeness against OS Open Roads, then having the TOID in OSM would
be useful. But perhaps a better solution would be to persuade OS that
they should be including the USRNs in OS Open Roads -- as these are
now the promoted 'gold standard' open unique identifiers for streets.


There's an Open Data Linked Identifiers (LIDS) dataset available from OS 
which links USRNs to TOIDs.


https://osdatahub.os.uk/downloads/open/LIDS

Well, actually, there's two of them, and I'm not entirely sure what the 
difference is:


Road TOID Street USRN 10
RoadLink TOID Street USRN 8

Both of them have exactly the same data format.

The TOIDs in those datasets can then be cross-referenced against OS 
OpenNames to give the OS name for the linked USRNs. Although this isn't, 
always, the same as the official USRN name of the street, which can be 
confusing. But that's because OS (like OSM) maps what is visible, rather 
than necessarily what is documented, and if a street has a name by which 
it is commonly referred to then that's what goes on the OS maps even if 
it has a different name in the USRN.


Mark

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


Re: [Talk-GB] Street-name toids

2020-08-12 Thread Mark Goodge



On 12/08/2020 16:54, SK53 wrote:
OpenRoads from the Ordnance Survey contains a field containing the toid 
for the street name. I wonder if we should include these alongside usrn 
& uprn. They may be more useful than either for gathering complex roads 
which share a name.


Experimentally I have added this 
 toid to a street in Glossop.


I think adding toids is worth it, if we can unambiguously link them.

However, I'm a little concerned that someone has added a UPRN to that 
way. UPRNs are not, generally, applied to streets, and looking at the 
ESRI satellite view I suspect that that's actually a legacy UPRN which 
applied to the property before it was redeveloped for housing.


The street does have a USRN, which is 17326392. If you compare this:

https://uprn.uk/usrn/17326392

which is Foundry Close, with this:

https://uprn.uk/usrn/17301086

which is Surrey Street (that Foundry Close connects to), you'll see on 
the latter a single UPRN on top of Foundry Close. But switch to the 
satellite view on that page and you'll see that it's appears to be the 
UPRN of what was, at the time the image was taken, some empty land that 
had been cleared for redevelopment.


Mark

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


Re: [Talk-GB] UPRN Locations Map

2020-08-02 Thread Mark Goodge



On 02/08/2020 11:58, Jez Nicholson wrote:
My initial thought was also "conspiracy!". Licence problem is more 
likely, or perhaps they were concerned that someone might poll the URL 
with every available UPRN.


I'm certain that it's been done to prevent people using the EA site as a 
means of looking up an address from a UPRN. That's the only plausible 
explanation for a change which both makes the site more complex from an 
operator point of view (instead of a single database lookup, it now 
needs to do several to identify the property from the postcode and 
sequence ID) and less useful from a user perspective (because you can no 
longer bookmark and share a link to a specific property).


If it is a licence issue, then that's going to have ramifications beyond 
the EA. A lot of local authorities use the UPRN in the URL for 
property-related information. For example, if you live in Cambridge, you 
can check when your bins will be emptied by appending the UPRN to the page:


https://www.cambridge.gov.uk/check-when-your-bin-will-be-emptied#id=24173390

and if you live in Worcestershire, you can check lots of useful stuff 
about your property:


http://e-services.worcestershire.gov.uk/MyLocalArea/MyLocalAreaResults.aspx?uprn=100120673306

It seems to me that this is precisely how the UPRN should be used by 
government and other organisations. To quote Matt Hancock from when he 
was the secretary of state for DCMS:


"The UPRN is the jewel at the heart of the addressing system. It links 
address data across a diverse range of systems and services facilitating 
greater accuracy and immediate data sharing"


and the government's own statement on open UPRNs states that

"Users need property and street information with identifiers that remain 
the same over time and are easy to exchange between systems."


and

"Systems, services and applications that store or publish data sets 
containing property and street information must use the UPRN and USRN 
identifiers."


https://www.gov.uk/government/publications/open-standards-for-government/identifying-property-and-street-information

So it seems to me that there should be no licensing issues with using 
the UPRN as a unique identifier in a public URL. If anything, the 
requirement to use UPRNs in any published dataset seems to pretty much 
make it the simplest means of compliance.


(I appreciate that this is going a bit off topic for OSM, so I think 
I'll leave it there unless there's anything else directly 
mapping-related, but it's worth noting that this change has already been 
mentioned on social media and I suspect it's an issue which will gain 
more traction over time).


Mark

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


Re: [Talk-GB] UPRN Locations Map

2020-08-01 Thread Mark Goodge



On 01/08/2020 20:24, Nick wrote:
As a follow up, Robert Whittaker also submitted an FOI asking for "... a 
list of all UPRNs that are classified as 'historic', and a separate list 
of all those classified as a 'parent' ". the logicto me was that 
this would help users of Open Data to then filter these out. The 
response that this was "exempt from disclosure under section 21 of the 
FOIA" - if you are interested follow the link to 
https://www.whatdotheyknow.com/request/lists_of_historic_and_parent_upr


In another move, the Environment Agency flood risk website no longer 
allows you to link directly to a property by UPRN. You used to be able 
to construct a link in this format:


https://flood-warning-information.service.gov.uk/long-term-flood-risk/risk?address=[uprn]

But that no longer works. Now, you have to search by postcode, and when 
you select an address the site then sets a cookie which determines which 
property details you will be shown. And, checking the source of the 
postcode page, it no longer has the UPRN as a variable for each 
property. Instead, it's a simple sequential number. For example, if 
there are ten properties in a postcode, then the variables will be 
numbered 0 to 9.


I'm pretty certain this is deliberate, in order to stop people using 
their site as a way to look up addresses from a UPRN. And I suspect it's 
part of the same attempts by GeoPlace to deliberately minimise the 
utility of the Open UPRN database.


Mark

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


Re: [Talk-GB] Surveying rural buildings

2020-07-24 Thread Mark Goodge



On 24/07/2020 13:20, Martin Wynne wrote:

  > but most people I know aren't aware of OSM.

I've been trying to persuade country-walking groups to use OSM. There is 
a lot of useful stuff there not shown on OS Explorer -- stiles, kissing 
gates, benches, bus stops, all pubs, cafes, etc. It's a lot more 
up-to-date, and if they find anything missing they can add it themselves 
for the benefit of others.


Most of them go back to OS Explorer when they find UK public rights of 
way are not shown in different colours on the OSM standard map.


Yes; this is an issue specifically for map users on foot. With roads, 
the question of legality is much less of an issue - almost all roads of 
any significance are public highways, and those that are not are usually 
clearly marked as such. But with footpaths and farm tracks in open 
countryside, there is often no obvious visual distinction, and yet the 
legality is a critical factor to users. This is an area in which OS maps 
are much more useful to walkers.


On the other hand, one of the areas where OSM is better than OS is that 
we map permissive paths, which OS tends not to unless they are big 
enough to also be usable by vehicles (and even then, it doesn't have any 
means of indicating permission).


This is one of the reasons why it would be nice to have a UK-specific 
stylesheet for OSM. The data is there, so there's no reason why it cant 
be rendered. Or, alternatively, a dedicated "outdoors" stylesheet which 
focusses on hiking, biking, etc.


Mark

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


Re: [Talk-GB] Another UPRN/ oddity

2020-07-23 Thread Mark Goodge



On 23/07/2020 00:16, Andy Mabbett wrote:

Here's a good one...

I know the street at:


https://www.openstreetmap.org/?mlat=52.54633=-1.91892#map=19/52.54633/-1.91892

which is a side-loop off the Queslett Road dual carriageway (and,
indeed is the original alignment of Queslett Road, before the dual
carriageway was built), as being also "Queslett Road". OSM sensibly
agrees with me, as does Royal Mail's address/postcode-finder. As did a
friend who lived there, many years ago.


[snip]


The house nearest to my marker is 229 Queslett Road. Its UPRN is
100070487637; and the government flood warning service also says its
address is Queslett Road:


https://flood-warning-information.service.gov.uk/long-term-flood-risk/risk?address=100070487637


The PAF also has it as Queslett Road.


But the USRN for the loop is given on "Find My Street" as 2708337,
which is Booths Lane.


But here's an interesting thing. None of the properties on that section 
of street are linked to USRN 2708337 in the open UPRN database:


   https://uprn.uk/usrn/2708337

The USRN that 100070487637 is associated with is 2704593:

   https://uprn.uk/100070487637

Which is Queslett Road:

   https://uprn.uk/usrn/2704593

I think that what you've found, therefore, is simply an[other] error in 
the USRN database.


Mark

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


Re: [Talk-GB] Scheduled Monument

2020-07-23 Thread Mark Goodge



On 22/07/2020 23:02, Dave Love wrote:

On Wed, 2020-07-15 at 10:18 +0100, Tony OSM wrote:


For a building or similar I presently use

HE_ref=1072653
heritage=2
heritage:operator= Historic England
historic= heritage
listed_status=Grade II
name= War Memorial Gateway to Astley Park
barrier=gate
start_date= mid C19
website=
https://historicengland.org.uk/listing/the-list/list-entry/1072653


I forgot to comment before:  From a maintenance point of view, is it a
good idea to add redundant data (that I assume are implied by HE_ref)?


The HE_Ref is probably the important one, as that links back to the 
original data source. But the rest of it seems a reasonable way of 
tagging listed buildings.



Also:

On Thu, 2020-07-16 at 14:10 +0100, Tony OSM wrote:

Yes, maintenance when things change is an issue.

I've looked at taginfo listed_status and found several variations
for
Scheduled Monument, Grade(value)

I plan to do several things if there are no objections

1. update wiki listed_status to show the capitalised values
Scheduled
Monument, Protected Wreck Site,
Park and Garden, Battlefield, World Heritage Site, Certificate of
Immunity, Building Preservation Notice


What happens to, say, a park/garden with a grade, then?


Parks and Gardens are, typically, not listed buildings and don't have 
grades in the same way.



Straying a bit from the topic a bit, perhaps it's worth adding
something about adding listed things that may not be obvious to
everyone.  If you find in the HE listings a building (say) you don't
already know and want to tag it, presumably it's a problem that you
can't just match the position on their OS maps to OSM.  I assume you
need to take the listed grid reference and just use that (which you
probably can't with curtilages etc. or a monument like an ancient
ditch, though that's likely on NLS 1:1).  The wiki could use info
about converting grid references too, unless I missed it.


The re-usable data for listed buildings only contains a point, so that's 
the only useful geographic data for them even if the map on the HE 
website shows the curtilage. Some of the data for monuments includes a 
polygon, but not all, and you can't tell from the website which does and 
which doesn't - you have to download and convert the shapefiles.


Mark

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


Re: [Talk-GB] Electric vehicle charging points

2020-07-21 Thread Mark Goodge



On 21/07/2020 21:27, ael wrote:

On Tue, Jul 21, 2020 at 05:30:25PM +0100, Mark Goodge wrote:



On 21/07/2020 16:57, Kai Michael Poppe - OSM wrote:

Is the National Chargepoint Registry data open for OSM now? If not
somebody should write a nice enough letter?


It is open, it's OGL now. But it's not reliable enough for an unfiltered
bulk import; there are duplicate entries, incorrect coordinates and
incorrect or missing addresses.


And missing entries. Two charge points that I have mapped do not appear,
at least with a post-code search.


Yes; it's a good start, but by comparison with other (non-open) sources, 
it appears to have only around 80% of the total included. Although 
missing entries are less of a problem for a data import than erroneous 
entries, because gaps can be filled in manually. It's the errors which 
are more of a problem, because it's generally better not to map 
something than to map it wrongly.


Mark

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


Re: [Talk-GB] Electric vehicle charging points

2020-07-21 Thread Mark Goodge



On 21/07/2020 20:56, Dave F via Talk-GB wrote:



On 21/07/2020 17:30, Mark Goodge wrote:



On 21/07/2020 16:57, Kai Michael Poppe - OSM wrote:
Is the National Chargepoint Registry data open for OSM now? If not 
somebody should write a nice enough letter?


It is open, it's OGL now. But it's not reliable enough for an 
unfiltered bulk import; there are duplicate entries, incorrect 
coordinates and incorrect or missing addresses.


Can you post the link?


https://www.national-charge-point-registry.uk/ncr-home/

Download link and licence details are in "Access the data" on the right 
(if you have a narrow screen then you need to click the arrow to make 
the panel slide in).


Mark

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


Re: [Talk-GB] Electric vehicle charging points

2020-07-21 Thread Mark Goodge



On 21/07/2020 16:57, Kai Michael Poppe - OSM wrote:
Is the National Chargepoint Registry data open for OSM now? If not 
somebody should write a nice enough letter?


It is open, it's OGL now. But it's not reliable enough for an unfiltered 
bulk import; there are duplicate entries, incorrect coordinates and 
incorrect or missing addresses.


What it would be useful for, though, is adding the technical data to a 
chargepoint that has been mapped by on-the-ground observation. So long 
as we can match an entry in the NCR to a mapped chargepoint, the 
metadata (eg, connector types, owner/operator/network) can be updated 
automatically.


Mark

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


Re: [Talk-GB] Electric vehicle charging points

2020-07-21 Thread Mark Goodge



On 21/07/2020 12:58, Dave F via Talk-GB wrote:

1538 nationwide.


Which is a long way short of the 10,000+ listed in the National 
Chargepoint Registry.



Use this to see what other tags contributors are adding.
https://overpass-turbo.eu/s/Wia


It seems to be patchy, and very dependent on local mappers.

I think it would be beneficial to add them wherever possible. I take the 
point mentioned elsewhere that those who actually use them will, 
typically, have an app that gives their locations and availability. But 
they are, nonetheless, a visible part of the built infrastructure. I'll 
certainly make a point of adding the ones I know about locally.


Mark

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


[Talk-GB] Electric vehicle charging points

2020-07-21 Thread Mark Goodge

Do we map electric vehicle charging points? If not, should we?

None of the ones in my town are on OSM, at the moment. I could add them, 
but it seems a bit pointless if they're not generally mapped.


Mark

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


Re: [Talk-GB] The curious case of USRN 20602512

2020-07-15 Thread Mark Goodge



On 15/07/2020 09:05, Phillip Barnett wrote:

Could you not just ask the local mapper to knock on any doors in the
street and ASK them the name? And then use that local knowledge?


In this case, there are no doors on the street as it's just an access road!

What might work would be to contact a local councillor, say, and ask 
them for the name of the street. Their local knowledge can then be used 
in OSM.


If you wanted to pursue the FOI route, another option would be to ask 
for documentation from the time when the road was named, showing the 
decisions made. It would probably date from the time when the entire 
estate was built. But the council may no longer have those records, as 
it is some time ago.


Mark

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


Re: [Talk-GB] The curious case of USRN 20602512

2020-07-15 Thread Mark Goodge



On 15/07/2020 08:35, o...@poppe.dev wrote:


We wish to refer you to the Adopted Roads map for this information. 
This can found via: 
http://maps.ealing.gov.uk/Webreports/Highways/Adoptedroads.html You

are free to use this information for your own use, including for
non-commercial research purposes. It may also be used for the
purposes of news reporting. Any other type of re-use, for example
publishing the information, issuing copies to the public or
marketing, will require our permission as copyright holder. If you
intend to re-use this information in this manner you must apply to
us. ***


This is the FOI get-out; they can refer you to existing published 
information and therefore don't need to give a direct answer in the 
response. Unfortunately, that doesn't help with finding an 
ODbL-compliant source of the name.



Secondly, lookig at that map, the adopted road scheme REALLY thinks,
that this road is called "Fairfield Road". Darn.


Well, it would, because the Adopted Roads list will match the NSG. In 
fact, it's the source of the information that Ealing submits to the NSG.



So, now my question is this: The response said "If you intend to
re-use this information in this manner you must apply to us.". Is
this a process that I want to go through (given, I ever find out who
"us" is) and then put the answer under
https://wiki.openstreetmap.org/wiki/Permissions?


I suspect it would be fruitless anyway. They'll just refer you to the 
existing mechanisms for getting access to the NSG. But even if you were 
to pay the cost of that, it won't deliver the data in a suitable licence.


In any sane world, of course, the idea that the names of roads should be 
subject to any form of restrictive license would be deemed utterly 
absurd. In fact, I'm reasonably confident that it wouldn't survive a 
legal challenge in this world. While the creation of a map, is, clearly, 
a work subject to copyright, a simple fact - and the name of a road is a 
fact - isn't. And a list of road names, created for the benefit of those 
who use and maintain the roads, has no independent economic value and 
therefore doesn't meet the criteria for database right.


The rulings by the European Court of Justice in the William Hill and 
Fixtures Marketing cases are relevant here - essentially, the court 
concluded that if a list of facts (eg, a list of football matches, or 
horses entered in a race) is a necessary part of administering the 
competition, then that list of facts isn't subject to database right as 
it has no existence independently of the competition's functioning. And 
I'm pretty sure that a court would apply the same judgment to a list of 
street names. Councils have a legal obligation to maintain the canonical 
list of street names in their territory, and, in any case, having such a 
list is essential to the way that the council operates. So the list has 
no independent existence apart from that legal and operational 
necessity, and therefore doesn't qualify for database right.


But, of course, OSM can't include data on the basis of a legal opinion. 
It would take an actual court case to establish the fundamental openness 
of street names, and OSM doesn't want to be the organisation which is 
part of that case. So, at the moment, we're still stuck as far as 
directly reusing names from the NSG is concerned.


Mark

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


Re: [Talk-GB] The curious case of USRN 20602512

2020-07-11 Thread Mark Goodge



On 11/07/2020 07:47, Steve Doerr wrote:

On 10/07/2020 11:27, Mark Goodge wrote:
So, it seems that Fairfield [Road] isn't known to either OS or Google. 
It is shown (in abbreviated form) on streetmap.co.uk, but at that zoom 
level, in London, that's based on the Bartholomew A-Z maps rather than 
OS.


For what it's worth, I also found it in a street atlas published by 
Geographia. I don't know if that's the same company as A-Z. 


Geographia is a former publisher of maps, now defunct (and not related 
to the US company of the same name).


I also don't 
know the date of the street atlas and neither do I know how old a street 
atlas (non-OS) would have to be in order to be able to copy a name from it.


For non-OS maps, copyright expires 70 years after the death of the last 
surviving major contributor. The wiki has some information on this:


https://wiki.openstreetmap.org/wiki/Out-of-copyright_maps#UK

The atlas should have a publication date on it, somewhere.

Mark


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


Re: [Talk-GB] The curious case of USRN 20602512

2020-07-10 Thread Mark Goodge



On 10/07/2020 16:00, Kai Michael Poppe - OSM wrote:

After not having any luck in finding out of copyright maps that helped I 
wondered, if a FOI request to Ealing Council, naming the exact location 
and asking for the name would be fruitful. Did anyone ever try something 
like this? Would this then be seen as a source compliant to the ODbL?


I suspect that an FOI request would return the name that's in the NSG. 
That is, Fairfield Road. It's unlikely that the FOI officer will do 
anything other than look up the street on the computer, and take the 
answer they are given.


I'm not sure whether that's acceptable for ODbL or not. There's a lot of 
data that can be released under FOI that can't be reused because it 
contains proprietary information. This may come under that category.


Mark

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


Re: [Talk-GB] The curious case of USRN 20602512

2020-07-10 Thread Mark Goodge



On 10/07/2020 14:21, Lester Caine wrote:

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can 
be difficult to spot errors, because the people who are most likely to 
spot errors - members of the general public with local knowledge - 
tend not to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer at 
the council covering the area. Probably originally tacked on to another 
job description and someone who probably had no training is this 'new' 
function? I was receiving NLPG updates for many years and the vast 
majority of 'updates' were corrections to data rather than additions. 
The problem has always been not allowing public access to what has 
always been public data and now we do have access there needs to be a 
proper channel to feed corrections to the 'data officer' responsible for 
the relevant slice of raw data. I don't think THAT has changed since the 
requirements for councils to provided the raw NPLG data passed into law? 
I'm fairly sure the street data is part of the same legal framework ...


There is a process for changing the name of a street, yes. It's a bit 
cumbersome and bureaucratic, but it's doable.


The problem with correcting an error on the NSG is that, unless it is a 
clear and obvious error (such as a typo), and there is current 
documentation which shows the correct form of the name, it has to be 
treated as a name change rather than an error correction.


So, for example, if the NSG says "Coronaton Street" for a street on a 
new development, but the minutes of the relevant meeting where new 
street names were discussed clearly shows that it was resolved to call 
it "Coronation Street", then that is a clear and obvious error which can 
be corrected without the need for any further hurdles to jump.


But, on the other hand, if the NSG has "Victoria Square" for a street 
that has been there since Victorian times and was entered into the NSG 
as "Victoria Square" in the 1990s when the NSG was first created, then 
even if absolutely everybody who lives there knows that it really should 
be "Albert Square", and there are records dating back to the 19th 
century which show it as "Albert Square", and even if it's always been 
"Albert Square" on the OS maps, then it still needs to go through a full 
change of name process to get the NSG updated to say "Albert Square". 
And that can't be done just by asking for it, it needs the support of 
the local councillors at district or borough level as well as, if 
appropriate, the support of the local parish council. And getting that 
support can be problematic.


(This scenario is precisely what happened in the case I was involved in; 
a village lane that had been known by a particular name for centuries, 
and was still known by that name by the locals, had, somehow, ended up 
in the NSG in 1991 under a completely different name. And getting that 
changed was a whole world of pain.)


Mark

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


[Talk-GB] The curious case of USRN 20602512

2020-07-10 Thread Mark Goodge
Apologies for the long read, but this may be interesting to some folk. 
This follows on from my earlier response to Kai Michael Poppe about 
"Fairfield Road" in Ealing.


On 04/07/2020 12:02, I wrote:


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.


I've been doing a bit more research in this, as it piqued my interest. 
And the results are a little surprising.


For a start, USRN 20602512 doesn't match Fairfield Road in OS LocalMap 
Open. In fact, there's no Fairfield Road anywhere near there in OSLMO. 
Matching the coordinates indicates that, as far as OS is concerned, it's 
a part of Southdown Avenue. That's not particularly unusual, access 
roads off named streets often don't have a name of their own, they're 
either completely unnamed or share the name of their parent street.


However, I did wonder whether this might just be a limitation on OS Open 
Data, and whether MasterMap might actually include the name. That's not 
reusable in OSM, of course, but it might help point to an open source 
that does contain it.


But it seems that even MasterMap doesn't have that name. You can check 
that by looking at Ealing's online GIS website:


http://maps.ealing.gov.uk/Webreports/Planning/Planning.html

This is a planning application map, but it's just a window into their 
GIS system and you can turn off the planning layers. Anyway, zoom all 
the way in to the street in question - I can't give you a persistent 
link, but it's just above the LA boundary in the bottom middle of the 
map - and... it still has no name. At the highest zoom level, this is 
MasterMap, and every named object has its name displayed. But there's no 
name here.


Google, also, knows nothing of a Fairfield Road here. Using the Maps API 
to query the coordinates of USRN 20602512, we either get Southdown 
Avenue, again, or Boston Gardens, which is the postal address of 
buildings facing Boston Road. You can see that name on the road sign via 
Google Streetview:


https://goo.gl/maps/KGLbRC75mQw43PCV6

So, it seems that Fairfield Gardens isn't known to either OS or Google. 
It is shown (in abbreviated form) on streetmap.co.uk, but at that zoom 
level, in London, that's based on the Bartholomew A-Z maps rather than OS.


Given that, we can't include the name "Fairfield Road" in OSM as it's 
only available from non-open sources. But even those non-open sources 
don't agree on the name. That seems to me to lead to two possibilities:


1. It doesn't exist at all. It's just a map trap designed to catch out 
unwary copyright infringers. That's certainly a possibility, and A-Z 
maps are known to use those. But that doesn't explain its presence in 
the USRN database.


2. The USRN name is wrong, but that error has propagated to the A-Z maps.

Personally, I think that the second option is the most likely. And, if 
so, it wouldn't be the only error in USRN. One of the things I had to 
deal with a few years ago, in my capacity as a district councillor, was 
a country lane in my ward that had the wrong name assigned to it in 
USRN. After a bit of investigation, we concluded that it had simply been 
a transcription error back in the late 90s when the local gazetteer was 
first digitised, but it had gone unnoticed for a couple of decades 
simply because the wrong name never appeared anywhere in public until it 
eventually cropped up on a planning application. Getting the name 
corrected wasn't an easy task, because of the length of time it had been 
wrongly recorded, but we did eventually manage to get it sorted out and 
the correct, historic name of the lane assigned to the USRN.


But that's not the only one. The USRNs for where I grew up, out in the 
middle of the countryside in West Suffolk, are listed as either "Poultry 
Road" or "Sedge Fen" in the USRN database. You can 

Re: [Talk-GB] UPRN Locations Map

2020-07-06 Thread Mark Goodge



On 05/07/2020 18:42, I wrote:



On 05/07/2020 18:35, Robert Skedgell wrote:


Is it possible that your installation of GDAL doesn't include support
for the GPKG vector driver?


Yes, I get the error

Unable to open datasource `osopenusrn_202007.gpkg' with the following 
drivers


Just as a follow-up note, I tried it with a fresh install of GDAL on a 
different server and it works fine. So there clearly was something odd 
about the version I'd originally used. But that's immaterial now, 
fortunately.


Mark

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


Re: [Talk-GB] UPRN Locations Map

2020-07-05 Thread Mark Goodge



On 05/07/2020 17:45, Kai Michael Poppe - OSM wrote:

On 05.07.2020 17:51, Andy Mabbett wrote:


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)


Naive question - can that be added as a layer in JOSM? If so, how?


Yes and no. The UPRN data is also available as a GeoPackage (just like
USRN), yet when I tried this morning, I was unable to make to GeoServer
deliver the data correctly.


Just out of interest, is there any simple way to export data from 
GeoPackage (eg, to GML or GeoJSON) via the command line on Linux? I've 
tried ogr2ogr, but that doesn't seem to recognise GeoPackage as a 
source. I can do it manually by loading it into QGIS desktop and then 
exporting it, but I'd prefer something I can automate.


Mark


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


Re: [Talk-GB] UPRN Locations Map

2020-07-04 Thread 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


Re: [Talk-GB] UPRN Locations Map

2020-07-04 Thread 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

2020-07-03 Thread Mark Goodge


On 03/07/2020 20:37, I wrote:


You could probably also match the names from OS OpenMap using the same 
principle. That doesn't include USRNs, but the LineStrings are likely to 
match the Open USRN geometry pretty closely. Either way, it should be 
possible to assign names to Open USRNs simply by overlaying them on a 
map which already has names.


Just for reference, I've just compared the LineStrings for the street 
where I live in both Open USRN and OS OpenMap Local. Apart from the fact 
that, for one coordinate pair, OSOML is rounding to two decimal places 
wile Open USRN uses three decimal places, they are identical.


Obviously, that's just one suburban residential street, and other, more 
complex routes may not match so well. But the principle works on a 
sample location, so it's just a case of seeing how consistent it is 
across the entire network. I may have a look at that in more detail next 
week. But I've been working flat out on processing open UPRNs and UPRNs 
since Wednesday, and, right now, it's wine o'clock :-)


Mark

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


Re: [Talk-GB] UPRN & USRN Tagging

2020-07-03 Thread Mark Goodge



On 03/07/2020 21:07, Andy Mabbett wrote:

On Fri, 3 Jul 2020 at 15:31, Tony OSM  wrote:


Question: Should uprn be applied to the building outline or to a node?


Yes ;-)

Some UPRNs have a 1:1 relation with a building or object (terraced,
semi- or detached house, telephone box, etc.)

Some do not (apartments; subdivided houses, etc.)

I propose we tag accordingly.


I agree. But, where multiple UPRNs are co-located with a single 
building, there's no consistent way to tell from the Open UPRN data 
which UPRN attaches to which subdivision. The open data has no z-index, 
so where you have a flat above a shop, for example, the data will give 
you two UPRNs for the same building but no indication of which is the 
flat and which is the shop.


For that, you need local knowledge - and it can't be local knowledge 
obtained from incompatible sources. So there won't be any easy way to 
look it up, as all the lookups are likely to be based on data obtained 
from MasterMap and AddressBase.


Mark

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


Re: [Talk-GB] UPRN Locations Map

2020-07-03 Thread Mark Goodge



On 03/07/2020 11:23, Tony OSM wrote:
I spent part of yesterday navigating the relevant OS and LandRegistry 
sites and trying to figure out what we can do.


We can basically put UPRN and USRN into OSM freely - the license is 
written to enable that.  OS have also separated out the ability to match 
UPRN and USRN to address and street records - essentially they are 
creating an index into their MasterMap products which are behind a 
paywall. So anybody who wants to pay -  possibly Logistics companies - 
can find exactly where their van has to go, more accurate than a postcode.


It should be relatively straightforward to link USRNs to OSM data, since 
the topology will match - most roads don't stack, so where a USRN line 
follows the same route as an OSM way that's tagged as a road then they 
are the same. Where roads do overlap (eg, the A4/M4 double decker in 
West London and various tunnels and flyovers), that should be amenable 
to manual resolution. Once a USRN is matched to an OSM named way then 
that gives us a name for the USRN that's derived independently of 
MasterMap.


You could probably also match the names from OS OpenMap using the same 
principle. That doesn't include USRNs, but the LineStrings are likely to 
match the Open USRN geometry pretty closely. Either way, it should be 
possible to assign names to Open USRNs simply by overlaying them on a 
map which already has names.


(I say "relatively" straightforward as the open USRN dataset is supplied 
as a Geopackage, so using it requires extracting the data from that. 
That's an added layer of irritation, but it's not unsurmountable).


Matching UPRNs to OSM data is likely to be more awkward. In a lot of 
cases, of course, it will be simple enough - where there's just one UPRN 
assigned to what is obviously a distinct building that's been mapped in 
OSM then that UPRN clearly applies to that building. But where there are 
multiple UPRNs allocated to a single building then we would need more 
data to be able to make the correct links. And that data is probably not 
available with a suitable licence.


OS also seem to have been careful not to place UPRN and USRN data into 
their other free products so as to make cross referencing difficult.


UPRNs can be linked to adjacent USRNs via the OS Open Linked Identifiers:

https://osdatahub.os.uk/downloads/open/LIDS

That's helpful, because it tells us which part of the road network the 
local authority responsible for allocating the UPRNs thinks it's on. 
That's not necessarily the same as the street name in the postal 
address, but for physical access (which is what matters for things like 
deliveries and taxis) it's often more useful than a postal address.


Mark

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


Re: [Talk-GB] UPRN Locations Map

2020-07-02 Thread Mark Goodge



On 02/07/2020 19:52, SK53 wrote:

Post boxes, substations, patches of grass (I presume), and bus stops are 
things I've spotted. The oddity is a great forest of UPRNs over a 
hospital building 
. 


They may possibly be multiple postal addresses, for example for post to 
different departments, that share a location.


On a similar note, this view of a postal depot in Stoke only has one 
marker on the building itself:


https://osm.mathmos.net/addresses/uprn/#19/52.9423/-1.1827

But, actually, there are multiple UPRNs all sharing identical 
coordinates - so many, in fact, that if you click on the marker, the 
list expands so far that it shifts the viewpoint of the map which then 
hides them all again, so you can't actually read them!


Mark

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


Re: [Talk-GB] UPRN Locations Map

2020-07-02 Thread Mark Goodge



On 02/07/2020 18:38, Peter Neale via Talk-GB wrote:

Hi Robert,

Many thanks for producing that map.

I was able to look at my street and see a blue pin in each of the 
building outlines that I had mapped from aerial imagery, so that gave me 
a warm, smug feeling :)


I too noticed some not-yet-there properties in a nearby development that 
had UPRNs assigned - Not a problem really (IMHO).  There is also one 
allocated to a pond near me; I didn't know that was "addressable"!


They're not addressable in the sense that they have a postal address. 
But they still need to have some form of identification that can be used 
for things like planning applications, business rates, etc.


However, I am still not clear how best to use the data available, if you 
can't use it to look up the address of the property.  Similarly, I am 
not sure how a data consumer could use the data, if we laboriously 
edited every property in OSM to include a "ref:GB:UPRN=" tag (or 
similar; other tags are available.).


In the short term, not a lot. But, in the long run, UPRNs are likely to 
have increasing importance. Consumers will be expected to know, or at 
least know where to find, their UPRN - it will be a public identifier 
for business rates and council tax, for example. I would even expect 
sat-navs to start supporting them - they are more precise than 
postcodes, but easier to type in than a full address. So having them 
available to the map will facilitate that.


Mark

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


Re: [Talk-GB] "secret" site

2020-06-28 Thread Mark Goodge



On 28/06/2020 15:12, Dave Love wrote:

On Sun, 2020-06-28 at 13:37 +0100, Mark Goodge wrote:


On 28/06/2020 12:18, Dave Love wrote:

On Sun, 2020-06-28 at 09:33 +0100, Robert Skedgell wrote:

Is it mapped or does it appear to be redacted on NLS's out-of-
copyright
OS maps?


Yes, for NLS and current OS displayed by MAGIC.


Is that yes, it's mapped, or yes, it's redacted?


Sorry, it's mapped.  I don't recall ever seeing anything redacted on an
OS map, but I don't remember when and what navigation we used on a
North York Moors walk.


In that case, the next question is, is it visible, either from a ground 
survey or from the overhead imagery?


If the answer is yes, then map it. You can then use your local knowledge 
to name it.


Stuff isn't generally redacted on OS maps these days, although it was, 
once. There's an interesting disconnect on the New Popular Edition here, 
where one sheet was produced while Lakenheath Airbase was still redacted 
but the neighbouring sheet was produced after it ceased to be:


http://www.npemap.org.uk/tiles/map.html#191,94,2

You can see it on the 1:10,560 maps of 1949-1969 on NLS as well:

https://maps.nls.uk/geo/explore/#zoom=14=52.41301=0.56200=193=3

Although the 7th Series had the road diversion and gave a name for the 
airfield, it didn't map any of the features and gave the (misleading) 
impression that a track still crossed it:


https://maps.nls.uk/geo/explore/#zoom=13=52.41613=0.54170=11=3

Mark

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


Re: [Talk-GB] "secret" site

2020-06-28 Thread Mark Goodge



On 28/06/2020 12:18, Dave Love wrote:

On Sun, 2020-06-28 at 09:33 +0100, Robert Skedgell wrote:

Is it mapped or does it appear to be redacted on NLS's out-of-
copyright
OS maps?


Yes, for NLS and current OS displayed by MAGIC.


Is that yes, it's mapped, or yes, it's redacted?

Mark

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


Re: [Talk-GB] Rockall

2020-06-15 Thread Mark Goodge



On 15/06/2020 10:23, Colin Smale wrote:
A new mapper has changed the status of Rockall, removing it from the UK 
admin boundaries. As I understand it Rockall is accepted as UK territory 
although it can't be used as a baseline to extend the EEZ. I contacted 
the mapper with a changeset comment and their motivation is based on 
"fixing the EEZ".


Wikipedia suggests that Rockall is considered (administratively 
speaking) part of the isle of Harris, in the Western Isles.


As Rockall has from time to time been the subject of a territorial 
dispute with Ireland, should we use the "disputed territories" process 
for Rockall?


I'd just revert it. There's no dispute as such about the ownership of 
Rockall, as no other country claims it. Ireland doesn't recognise UK 
sovereignty over Rockall, but doesn't claim it for itself either.


I see that the mapper in question has also changed the description of 
Rockall from island to rock, which also seems wrong to me. It is an 
island, albeit a very small one. But those are their only two edits, 
which suggests that they have a particular aganda rather than trying to 
improve OSM.


I think both edits should be reverted for now, but the mapper should be 
invited to suggest the changes he wants here and see if he can get a 
consensus around them.


Mark

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


Re: [Talk-GB] Tagging showgrounds

2020-05-15 Thread Mark Goodge



On 15/05/2020 13:50, Andy Townsend wrote:

The problem is that they're not necessary "all the same fundamental 
object".  Ashover Showground is "a patch of grass with some nice gates 
where something happens one a year".  Stoneleigh is essentially an 
agricultural business park.


Yes, and in between that you have ones like Stafford and Bakewell which, 
most of the year, are essentially grass-surface car parks adjacent to 
some exhibition halls.


Mark

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


Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-17 Thread Mark Goodge



On 17/04/2020 15:15, Brian Prangle wrote:
Rather than mappers up and down the country with varying evels of Excel 
skills spending many dozens of hours cleaning up this csv could somebody 
be kind enough to publish somewhere a cleaned up copy? It would be a 
great resource for the QP.


OK, here you go. Here are Excel and proper comma separated csv versions.

https://www.dropbox.com/s/ekokv1lz4wlgxfg/Pharmacies.xlsx?dl=0
https://www.dropbox.com/s/xhszbngsps4p14e/Pharmacies.csv?dl=0

I haven't made any attempt to normalise the addresses. Doing so reliably 
would require referencing AddressBase or the PAF, and therefore render 
the data non-open. And doing it unreliably is probably worse than not 
doing it at all.


It is not, though, particularly difficult to import the original version 
into a spreadsheet or database, and I would recommend that anyone who 
wants to use this data regularly does take a bit of time to learn how.


Mark



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


Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

2020-04-10 Thread Mark Goodge



On 10/04/2020 17:37, Brian Prangle wrote:

Can I ask two  basic daft questions?
What use are these in OSM if we only pick at them instead of importing 
the lot ( which is  highly unlikely)?


UPRNs will be useful on any mapped building or area, as it will help 
link OSM data to other datasets in a consistent way.


Is it possible to derive street names from USRN in a way that is licence 
compatible?


That depends on what's in the dataset that eventually gets released as 
open data. I would expect that the canonical name of the street would be 
part of the data, though. If so, then yes, we can use it.


One of the reasons why the government has been persuaded to release 
UPRNs and USRNs as open data is because there is a big push to get third 
party data users (eg, utility companies, roadworks contractor and 
planning applicants) to use the same identifiers as government (local 
and national) already does internally, so as to minimise the risk of 
errors in conversion from one identifier to another. To some extent 
that's already happening, because the big guys are already paying for 
AddressBase and have a licence to use the data. But it's recognised that 
for it to become ubiquitous, the data has to be open as many potential 
users can't, or won't, pay for a commercial licence.


To give an example, a lot of planning applications for greenfield 
developments and agricultural buildings are on land that doesn't have an 
assigned postal address (because nobody sends post to a field or a 
barn!). So they get described on planning applications as something like 
"Land adjacent to 53 Greendale Lane" or "Barn in field behind 23 
Pencaster Road", which often isn't helpful as that can be ambiguous. The 
applicant has to provide what's called the "red line" plan showing the 
outline of the property to which the application refers, but these are 
not necessarily accurate. But if a UPRN is provided, the planning 
authority can look that up on the Land Registry database and see 
precisely where it is, and the extent of the property, without needing 
to rely on the applicant's information. And, again, while large scale 
professional developers almost always get it right (because they can 
afford to spend money on professional data and mapping), it's the small 
guys who often don't. So if they can be steered towards supplying the 
UPRN of the location, it will make things easier all round. But that 
relies on the UPRN being available and reusable in the first place.


Mark

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


Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

2020-04-10 Thread Mark Goodge



On 09/04/2020 20:58, nd...@redhazel.co.uk wrote:

If uprn is supposed to denote an address, why not simply use addr:uprn?


It doesn't denote an address. While a lot of premises that have a UPRN 
also have an address, there are also many that don't. Every individual 
field in an agricultural area has a UPRN, for example, as do things like 
telephone boxes and street lamps. In fact, one of the main reasons 
behind the adoption of UPRNs as the unique identifier for properties is 
that addresses alone can't fulfil that purpose.


Mark

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


Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

2020-04-09 Thread Mark Goodge



On 09/04/2020 17:18, Andy Mabbett wrote:

On Thu, 9 Apr 2020 at 13:06, Mark Goodge  wrote:


They're a 10 to 12 digit integer.


Is there a check digit?


No, they're a simple sequential allocation. So an error can't be 
detected internally, it does need to be verified. But the same is true 
of postcodes and phone numbers, of course.


Similarly to the way that telephone numbers are allocated, though, UPRNs 
are allocated in blocks to local authorities who then assign them out of 
their block. So the first few digits of a UPRN will tell you 
approximately where in the country it is. In fact, you can already link 
a UPRN to administrative geography via existing open data, it's only 
drilling right down to precise coordinates that isn't currently possible.


If I was designing the checkout process for an online retailer that 
allowed customers to enter their UPRN rather than a postal address, what 
I'd do is show them a map, with their UPRN location marked, and ask them 
to confirm that that is, indeed, the premises they want the item 
delivered to. That could be done entirely using open data (once UPRNs 
are open), but a commercial supplier might also want to enhance that by 
using an address lookup to generate the geographic address from the UPRN 
and display that to the customer as well.

Mark

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


Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

2020-04-09 Thread Mark Goodge



On 09/04/2020 14:26, Robert Whittaker (OSM lists) wrote:


I would have said that ref:uprn and ref:usrn are the natural choices
for use to use. However, I've seen some calls for country codes to be
added to 3rd-party ref values, so we might consider ref:UK:uprn and
ref:UK:usrn instead. This isn't explicitly documented in the wiki at
https://wiki.openstreetmap.org/wiki/Key:ref though the French
community seems to be using it, as can be seen at
https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
, and I think it might make sense.


I agree that adding a country identifier makes sense. One of the key 
attributes of a UPRN is that it is unique within a country. But it may 
not be globally unique if other countries adopt a similar system. And, 
because it's just an integer, unlike a postcode, you can't infer the 
country from the format. But, on the other hand, adding another layer 
makes it more likely that people will tag them wrongly using what they 
think is the right method simply because that's what's most obvious to them.



I don't see any value in adding NLPG (or it's incorrectly ordered
variant NPLG). Although the National Land and Property Gazetteer is
where the UPRN values originate from, if they're being used as core
identifiers by the government, they're no longer just NLPG values.


I agree with this, too. The NLPG is just a database of UPRNs and other 
data, it isn't the source of them.



I also don't see any benefit in adding a :1 :2 etc suffix to the key
in anticipation of multiple values (which seems to have been done in
several existing UPRN keys). I think this will actually make it harder
for data-users than having a single key name and separating multiple
values with semi-colons. (You would suddenly need to search multiple
different keys to get all possible UPRN-tagged objects.)

So I'd propose that we use either ref:uprn and ref:usrn, or
ref:UK:uprn and ref:UK:usrn. What does everyone else think?


I'd be happy with either, so long as it's consistent.

Mark

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


Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

2020-04-09 Thread Mark Goodge



On 03/04/2020 10:15, Peter Neale via Talk-GB wrote:
So, will I have to quote a 20-digit alpha-numeric code, if I want to 
order something from Amazon? ..or get my grandchildren to send me a 
birthday card?


(I do not know what these UPRN's look like, but I bet they are not as 
easy to remember as "Rose Cottage, 3 Church Lane, XX3 4ZZ")


They're a 10 to 12 digit integer. At most, that's one digit longer than 
a telephone number. It's shorter than a credit card number. Mine is 
100121279888. For memorability, I could format that as 1001 2127 9888, 
pronounced "one thousand and one, two one two seven, nine triple-eight".


It isn't necessary to remember all of them, or even any of them, other 
than your own. Once they're open data they can be stored in any address 
book, along with things like email address and phone numbers. And to 
find out where they actually are, you just search for them on Google 
Maps, OSM, Bing Maps or any other mapping provider. Imagine, for 
example, that I have this entry in my phone's contact list:


Alice Example
phone: 01234 567890
mobile: 07654 321321
email: al...@example.com
uprn: 123456789012

If I want to phone Alice, I just tap on the number and the phone dials 
it. If I want to email Alice, I tap on the email address and my phone 
opens the email app with her address prefilled as the recipient. And if 
I want to visit her, I tap on the UPRN and my phone opens the default 
mapping app with a marker showing her location, and offers to provide me 
with directions on how to get there. I don't need to look up anything 
other than her name.


That doesn't stop anyone using the existing methods of storing an 
address. But it will make it hugely simpler for anyone who stores them 
in bulk, such as online retailers.


Mark

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


Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

2020-04-03 Thread Mark Goodge



On 03/04/2020 09:27, Robert Whittaker (OSM lists) wrote:


There will presumably be a drive in government circles to store
addresses as UPRN's, and then fetch the associated location and
address data from AddressBase. Assuming Rob's interpretation is
correct (I think it probably is) then this could be bad new for
sources of addresses and postcodes for OSM. While we'll be more easily
able to geo-locate objects from their URPN's, the actual addresses in
any datasets will become more likely to be contaminated by OS's IP
rights in AddressBase.


In the long run, I suspect this could actually spell the end for postal 
addresses (as distinct from geographic addresses). If every property has 
a published, unique number, analogous to a telephone number, then all 
that's necessary for, say, Amazon to deliver a package to me is for them 
to know the UPRN of my house. Their routing software will then do all 
the heavy lifting of plotting how to get the package from their depot to 
my door.


Mark

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


Re: [Talk-GB] Anyone in South-West London?

2020-03-30 Thread Mark Goodge



On 30/03/2020 19:08, Steve Doerr wrote:
Is this relevant/ 
https://ecoworldlondon.com/places-to-live/current/verdo-kew-bridge


Yes; that's also the subject of a Wikipedia page that appears to have 
been created by the same person. It's the promotional name of a new 
housing development, not a real place name, and as such is neither 
notable enough for Wikipedia nor relevant to OSM.


Of course, names of new developments may, over time, enter common use as 
the name of the place, and as and when that does happen there's no 
reason why they shouldn't be mapped. But the mapping has to follow real 
world usage, not precede it.


Mark

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


Re: [Talk-GB] Quarterly Project Suggestion - drink_water:refill

2020-03-20 Thread Mark Goodge



On 20/03/2020 10:55, European Water Project wrote:

Dear All,

Just got off a long conversation with Rebecca Burgess, CEO of Refill.

Unsurprisingly, Refill has no plans to share any of their proprietary 
data, but their App is open because anybody can use it  :)


For comparison purposes, I installed their app. While their base list of 
establishments in my town that offer free refills concurs with my own 
observations and council data, their mapping is awful. They've moved 
Tesco half a mile further down the road than it really is. A local 
independent coffee shop is on the wrong street. A cafe that I use 
regularly is in completely the wrong part of town! In fact, of the six 
locations they list here, only one of them (Wetherspoons!) has the 
correct coordinates.


So they've clearly got significant quality control issues. It seems to 
me that an Open Data product based on OSM would be more reliable than 
their solution, however it's being implemented. Provided the location of 
a premises is correct in OSM (which it usually is), then simply tagging 
that premises as offering free refills provides all the information 
necessary. The Refill app, by contrast, expects users to supply 
coordinates themselves (by dragging and tapping on a map), which is 
always likely to be unreliable.


Refill has plans to use more and more OpenStreetMap data to populate 
their network over time without re-contributing ...   Just a shame 
everyone can't just use the Refill App (sarcasm) !


Based on what I've seen, people are better off not using it.

Mark

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


Re: [Talk-GB] Quarterly Project Suggestion - drink_water:refill

2020-03-14 Thread Mark Goodge



On 14/03/2020 19:36, Jake Edmonds wrote:



On 14 Mar 2020, at 20:09, Mark Goodge <mailto:m...@good-stuff.co.uk>> wrote:


If we do come up with an agreed tagging system, I'd be happy to add 
tags for all the establishments in my town that I know offer this 
service. 


Maybe you have already seen them, but here is a link to the recently 
approved tags. Do you have any thoughts?


https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water%3Arefill


That seems reasonable. My only real concern is that tagging as part of a 
network could cause the network to think that we are re-creating their 
proprietary database. I'd prefer to stick with a simple 
drinking_water:refill=yes




And I could do that purely by observation; I don't have the Refill app 
or any other insight into their database, so there's no danger of 
adding non-free data to OSM. I'm sure that there are plenty of other 
people up and down the country who would be in a similar position.


Another way to avoid any worry of users submitting non-free data is to 
make storefront photos part of the project.


Possibly, although that makes it less likely that we'll get a critical 
mass of contributions. I could tag several establishments in my town 
from memory. Having to go back and photograph them would be an 
additional barrier.


Mark

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


Re: [Talk-GB] Quarterly Project Suggestion - drink_water:refill

2020-03-14 Thread Mark Goodge



On 14/03/2020 17:45, Philip Barnes wrote:

They do seem very secretive about the locations of these outlets, there 
appears to be no indication on their website even beyond there may be 
one somewhere in this area.


They came to the council that I sit on to ask for grant funding to get 
the scheme up and running in our area. One of the objections raised at 
the time was the lack of transparency around the scheme, and in 
particular the fact that if we did fund it, we appeared to be locking 
ourselves into a proprietary system if we wanted to promote it. Although 
a small amount of funding was approved, I suspect that it will not be 
if/when they come back to us for more. It does, unfortunately, seem to 
have more the feel of a device to sell branded water bottles than a 
genuine public service.


As it stands it does not appear to be a viable quarterly project. We 
have no indication of how common these places are, or their geographical 
spread meaning it is not a project all mappers can participate in.


I would disagree with this. I think that an observation-based database 
of establishments offering free water is, potentially, very useful. But 
it needs a certain critical mass to work, and it needs the help of 
people who can act as local observers. It seems to me that the OSM 
community is a good place to find that.


If we do come up with an agreed tagging system, I'd be happy to add tags 
for all the establishments in my town that I know offer this service. 
And I could do that purely by observation; I don't have the Refill app 
or any other insight into their database, so there's no danger of adding 
non-free data to OSM. I'm sure that there are plenty of other people up 
and down the country who would be in a similar position.



Also are these bottles just another 'single use' 'bag for life >
Like bags for life, their reuse is heavily dependent on them being 
remembered next time, and most people forget to take them, or leave home 
not realising they will even need them.


People are beginning to get more used to doing that, though. A lot of 
coffee shop chains offer a discount for people bringing a re-usable cup. 
Waitrose gives customers free coffee if they have a re-usable cup. So 
the principle is taking hold.


Mark

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


Re: [Talk-GB] Tagging showgrounds

2020-02-24 Thread Mark Goodge





On 24/02/2020 12:02, Ian Caldwell wrote:


As a local, I think it should be tagged as commercial. There is some 
event there most weeks. It's a very commercial organisation.


There are events which use buildings at the showground most weeks 
outside winter. But not that many which use the grass areas.


https://www.visitthemalverns.org/whats-on/event-finder/three-counties-showground-events/

(Note that there's a bug in that calendar which puts a caravan rally on 
every day! That's incorrect; all but two of those days - the real rally 
dates - are actually blank)


Mark

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


Re: [Talk-GB] Tagging showgrounds

2020-02-24 Thread Mark Goodge



On 24/02/2020 11:34, Brian Prangle wrote:
This is a case where landcover and landuse get confused in the OSM 
scheme of things. Yes it's grass but that's not its use. Its use is 
commercial : the  space is rented commercially to exhibitors who sell 
goods to attendees who pay an entrance fee, with a semi-cultural event 
attached. 


The wiki describes commercial as:

"Use tag landuse=commercial to delineate areas of land used for 
commercial purposes. Commercial landuse mainly deals with services and 
trade (tertiary sector).


Such area may consist of offices, administration, laboratories, 
logistics, hotels, car repair stations, and associated infrastructure 
(car parks, service roads, lawns and so-on). Compared to industrial 
landuse (landuse=industrial) no goods are produced."


A showground doesn't fit that description. Sure, it's commercial in the 
sense that it generates revenue. But then, so does forestry and 
agricultural land. And the trade stand aspect of a county show is 
secondary to the primary use, even though, these days, it's the use 
which sustains the event financially.


I'm not sure about access rights during times when there is no 
event , but I suspect it's private, so an open space justification might 
not be appropriate.


Yes; that's why I'm less happy with park or recreation_ground; as these 
tend to imply public access. I don't think they're necessarily wrong, 
and a ground which gets a lot of year-round use as well as its main show 
could well qualify as a recreation_ground. I think that's probably true 
of the East of England Showground, for example.


Given that we don't have a dedicated landuse=showground tag, I think 
that grass or recreation_ground are normally the best alternatives, and 
maybe sometimes park. None of them are precisely right for that kind of 
usage, but they're less wrong than some of the other alternatives such 
as commercial.


Mark


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


Re: [Talk-GB] Tagging showgrounds

2020-02-24 Thread Mark Goodge



On 24/02/2020 11:44, Andy Townsend wrote:

I suspect that it'll depend on the showground.  For Stoneleigh (which 
used to host the Royal Show), I'd have said commercial was correct.  For 
Ashover https://www.openstreetmap.org/way/231760526 (much smaller!) you 
could perhaps make a case for recreation_ground or farmland, although 
for 1 day a year it's used for Ashover show and it is currently mapped 
as the little-used "amenity=show_grounds" (which doesn't seem wrong, 
either).


That does make sense, particularly where the ground has other uses at 
other times.


I've no idea what the best tag for the Three Counties Showground would 
be - perhaps that would depend on "what it is most of the year"?


Most of the year it's just grass. It has no use other than the events 
which are held there, and those only take up a few days a year.


That's why I'm not entirely comfortable with recreation_ground, as that 
implies that it has a year-round use as such.


Mark

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


[Talk-GB] Tagging showgrounds

2020-02-24 Thread Mark Goodge

Morning all,

Someone has commented on a change I made to the Three Counties 
showground last year when I changed the tagging to landuse=grass rather 
than landuse=commercial. Their suggestion is that it really ought to be 
landuse=recreation_ground, with a secondary tag of surface=grass.


https://www.openstreetmap.org/changeset/74103491#map=16/52.0834/-2.3235

I've responded to that comment on the changeset, but I thought it would 
be worth throwing out here as well.


I do think that tagging showgrounds as landuse=commercial is generally 
incorrect; it doesn't match the description of 'commercial' in the wiki 
and doesn't reflect the typical uses of showgrounds both when a show is 
on and when one isn't.


The reason I tagged the Three Counties showground as grass is because, 
most of the year, that's precisely what it is - an open area of 
grassland. Unless there is an event on (which only happens for a 
minority of days in a year) it is just an open space.


Looking at a few other showgrounds across the country, we don't seem to 
have any consistency.


The East of England Showground is tagged as landuse=recreation_ground:

https://www.openstreetmap.org/#map=16/52.5456/-0.3170

The Suffolk Showground is tagged as a park:

https://www.openstreetmap.org/#map=16/52.0330/1.2277

So is the Staffordshire County Showgound:

https://www.openstreetmap.org/#map=16/52.8255/-2.0643

The former Royal Showground at Stoneleigh is tagged as commercial, but 
in that case that's probably now correct as it's no longer used as a 
showground and is gradually being redeveloped as a business park:


https://www.openstreetmap.org/#map=15/52.3435/-1.5220

The Great Yorkshire Showground isn't tagged as an area at all, just a 
network of roads and individual features:


https://www.openstreetmap.org/#map=16/53.9830/-1.5065

Similarly with the Norfolk Showground

https://www.openstreetmap.org/#map=16/52.6490/1.1793

And the Bath and West Showground:

https://www.openstreetmap.org/#map=16/51.1552/-2.5265

So, what do people think? Personally, I think that showgrounds ought to 
be tagged as an area, because they do, typically, have clear boundaries 
and are distinct from their surrounding context. But I'm less sure what 
the area should be tagged as. I think commercial is usually wrong, for 
the reasons I've already given, but I can see an argument for either 
grass, recreation_ground or even park.


Thoughts, anyone?

Mark


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


Re: [Talk-GB] Cheers Drive, Bristol

2020-02-16 Thread Mark Goodge



On 15/02/2020 12:08, Borbus wrote:
I've long suspected that local councils and other government bodies are 
giving data directly to Google. I've seen developments turn up on Google 
maps that couldn't possibly have been established with a survey. It's 
all really shady. 


There's no reason why they shouldn't. Street names are not a secret. The 
same information would be available to anyone who asks. In some cases, 
it isn't even necessary to ask, as it's published on the council website.


But at least we can say, even in this case, that OSM 
is the more accurate reflection of reality.
No, it isn't. The development has been built and the roads are actually 
there, as can be seen from the photos in the media reports. Someone 
needs to get down there and do a trace!


Mark

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


Re: [Talk-GB] What is farmland?

2019-12-14 Thread Mark Goodge



On 14/12/2019 16:08, Martin Wynne wrote:

I would say yes, as I believe both arable & livestock is farmland.


Thanks Dave.

But in that case, how on OSM do we differentiate between the two?

It seems silly that in some areas of OSM we can go into ridiculous 
detail, such as whether a bench seat has a backrest, but vast tracts of 
land which visually look very different are classed as one and the same?


That's partly because our mappers tend to be more urban, and urban 
things are what they tend to care more about and have more knowledge 
about. But, also, it's often hard to map rural areas from observation as 
a lot of it is private property that can't easily be accessed other than 
along the route of public rights of way. So we're more reliant on the 
aerial imagery for a lot of the countryside, and in many cases it's 
impossible to tell the difference between arable and grassland as it's 
all just shades of green (or, in summer, brown). In the same way, you 
can't easily see field boundaries on aerial photography unless they're 
separated by something easily visible, such as a hedgerow.


So I don't think this is an easily solvable problem, at least not 
without a lot of groundwork and local knowledge.


Mark

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


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Thread Mark Goodge



On 03/12/2019 15:48, Tom Hughes wrote:

The reason they're getting that error is almost certainly that they
aren't paying and they're either not passing an API key at all or
they're passing one that is for a different site.

Most likely the site was developed before API keys were required
and has never been updated, but if they add a key they will almost
certainly exceed the free allowance and have to pay which is likely
why they haven't done so.


They are passing an API key. But it doesn't seem to have billing enabled 
on it. Hence it won't be allowed to generate billable API calls.


Mark

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


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Thread Mark Goodge



On 03/12/2019 15:21, Edward Bainton wrote:
Interesting. Do they pay Google for the map and tileserver use (even if 
they don't realise that's what they're paying for)?


Or rather, since they've clearly not updated whatever agreement they had 
with Google for a while, /if/ the map were functioning would that mean 
they were paying Google?


Depending on how much usage it got, yes.

All Google Maps API usage now requires an API key. Each key has to be 
associated with a billing account, and all usage is chargeable. But each 
billing account gets $200 credit every calendar month, so if your total 
usage is less than that it remains free.


(There is still an embeddable non-API version of Google Maps, but it's 
very limited in functionality).


Mark

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


Re: [Talk-GB] Neighbourhood/LSOA Names

2019-11-15 Thread Mark Goodge

On 15/11/2019 18:38, Owen Boswarva wrote:

Hi Steve,

Do you mean this? https://visual.parliament.uk/msoanames

Recently completed, but the House of Commons Library did request 
suggested names back in January when it was in draft.


The problem with census areas, at any level, is that they don't 
necessarily coincide with the way that people actually perceive their 
neighbourhoods. In rural areas, civil parishes tend to be a reasonable 
proxy for the answer people would give to the question "Where do you 
live?", but not always. In cities, ward names can be a guide, but often 
aren't.


From a commercial perspective, this is something that is particularly 
important in the property market. For example, Zoopla, Rightmove and 
OnTheMarket have all created a database of named neighbourhoods that can 
be used in a location search. But they don't agree with each other 100%. 
And, of course, it isn't open data.


Google also returns a locality name with a reverse geocode search. But 
that, too, isn't open data (and requires a paid-for API key to query in 
bulk). In rural areas, it coincides with at least one of the property 
websites around 80% of the time, but hardly at all in major urban areas.


Royal Mail's dependent and double-dependent locality names in the PAF 
are, where populated, the most likely to correspond with perceived 
neighbourhood names (as, indeed, you would expect, as they're derived 
from historical usage themselves). But that's not open data either, and 
is also costly to access.


The obvious open data route, of using a proximity search to names 
already in OSM (or OS OpenNames), turns out not to work very well at all 
- mainly because simple distance takes no account of physical barriers 
such as rivers and roads, which often form the boundaries of perceived 
localities. You need to define your boundaries as well as assigning your 
names, and very few neighbourhoods and localities are anything near 
circular.


I'm not aware of any crowdsourced database, although I've often 
considered trying to create one. But even there, you run up against the 
problem that people may not agree among themselves as to the name of 
their locality.


Mark

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


[Talk-GB] Monochrome map layers

2019-11-12 Thread Mark Goodge
Does anyone know of a map layer/tile set that is completely
monochrome? I want to create some maps specifically for printing, but
the standard Carto layer is costly to print in colour and doesn't work
very well when printed in black and white as it uses a lot of subtle
colour for detail.

Specifically, what I want them for is to print off maps of local
neighbourhoods and villages for use when delivering leaflets (yes,
this is general election related!), so that people can easily see
where they need to go and mark off, using a highlighter, the streets
they have done.

Any suggestions?

Mark

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


Re: [Talk-GB] Poly Tunnels vs Greenhouses

2019-11-08 Thread Mark Goodge



On 08/11/2019 20:50, Philip Barnes wrote:

No problem with boats and greenhouses that don't move.

But these are probably seasonal and certainly shouldn't be mapped
from aerial imagery alone as they may have long gone. They certainly
need a recent survey.


I don't think polytunnels in open fields should be mapped, for this 
reason. They are seasonal and transient. They will be there for part of 
the year, and then removed after the growing season, and may not be used 
again on the same field the following year.


However, there are some permanent polytunnels that are, effectively, 
plastic greenhouses. Those can, and should, be mapped. But it needs 
local knowledge to map them. You can't do it from imagery.



It reminds me of the time an armchair mapper carefully traced a Maize
Maze that had existed for a short time in a field near me a couple of
years earlier.


I'm pleased to see that we do have the Hampton Court Maze mapped, though :-)

Mark

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


Re: [Talk-GB] Parish Councils needs

2019-10-26 Thread Mark Goodge



On 26/10/2019 09:23, Colin Smale wrote:

On 2019-10-26 09:58, Edward Bainton wrote:


(copying the list in again)
Thank you. My understanding is that this parish council has had *all* 
street assets devolved to it: see here 
. 

Where do you read that in the attached document? W.r.t. the public 
highway as an asset, paragraph 8 basically rules out transfer, as 
Wiltshire Council has a statutory role as Highways Authority. This 
document relates to a Draft Policy, so it may or not actually happen 
(dated Nov 2017). 
Street sweeping is unlikely to be delegated to parish councils, as the 
economy of scale doesn't work at that level - it needs a workforce and 
equipment inventory that's only cost-effective at city/district/borough 
level and above. Also, street cleansing is a statutory duty of principal 
councils under the Environmental Protection Act 1990, so it can't simply 
be delegated on a hands-off basis.


What does often happen in parishes is that public highways consisting 
solely of footways (eg, footpaths connecting housing estates) are 
cleaned by the parish under contract to the highway authority. Where the 
cleaning is done the old-fashioned way, by a man (or woman) with a 
broom, that makes sense, as the parish can be more responsive to local 
need and the street cleaners are themselves usually local residents who 
are familiar with their environment. But the overall responsibility 
still lies with the principal council.


Dangerous paragraph 21 about funding for delegated services: the parish 
council gets responsibility, without any additional money. They might be 
lucky and get the freehold of a swimming pool (operated by a third 
party) for example by way of compensation...


The way it works is that the parish council is expected to increase its 
council tax precept to cover the necessary costs, while the transferring 
council reduces its revenue budget (and hence precept) by the same 
amount. So it's cost-neutral, in theory, to the taxpayer, but the 
transferred service is subject to more local control.


In some cases that can actually work very well, and save money overall, 
because it eliminates a layer of management. But it only works where the 
service can effectively be managed at a local level.


Mark

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


Re: [Talk-GB] Import UK postcode data?

2019-10-07 Thread Mark Goodge



On 07/10/2019 14:50, David Woolley wrote:

On 07/10/2019 14:23, Mark Goodge wrote:

The ONS website explicitly states that their postcode products are OGL


The OGL only applies to the parts of the data that relevant government 
organisation has the ability to grant rights to.  It excepts "third 
party rights the Information Provider is not authorised to license;". As 
such being OGL doesn't meant that you have a right to any RM data it may 
contain.


Yes, but the ONS website licensing page lists the exceptions to OGL in 
its products. It is quite clear about the extent of OGL, and the data to 
which it does not apply. And it doesn't list the user type flag in 
postcode data as an exception. So, as far as ONS are concerned, the user 
type is OGL. That is the only valid conclusion from their wording.


Mark

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


Re: [Talk-GB] Import UK postcode data?

2019-10-07 Thread Mark Goodge



On 07/10/2019 11:43, Simon Poole wrote:


Am 03.10.2019 um 10:26 schrieb Mark Goodge:


ONSPD solves this problem, because it includes the "large user" flag.



It's the nature of the beast that when we are discussing OGL licensed
datasets that when something turns up that was previously thought to be
part of a proprietary dataset all alarm bells go off. Do you know how
they derived that flag and if there is really no residual proprietary IP
from RM in the data?


The ONS website explicitly states that their postcode products are OGL, 
with the exception of NI postcodes (which need to be licensed separately 
from NI Land and Property Services).


https://www.ons.gov.uk/methodology/geography/licences

Mark

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


Re: [Talk-GB] Import UK postcode data?

2019-10-04 Thread Mark Goodge



On 04/10/2019 20:28, Frederik Ramm wrote:

Hi,

On 10/4/19 20:51, Mark Goodge wrote:

The reality is that people expect postcodes to be a functional
search term on online mapping, at least in the UK,


You *are* ware that UK post codes are fully findable on the OSM
website and any site that runs the Nominatim geocoder? It must have
been mentioned somewhere in this thread. This means that our web site
and anything that uses Nominatim for geocoding already knows UK post
codes without importing them to OSM.


Yes, but OSM is the data, and the data needs to stand alone without 
needing Nominatim as a front-end. It's easy to add postcode search to 
OSM by means of an add-on system. But not every use of OSM data will 
include those add-ons.



With an automated import, OSM can be as up to date as the latest
release of CPO/ONSPD. And that's a positive selling point for our
data.


The notion that automated imports could set OSM apart from the 
competition flies in the face of what many of us believe to be OSM's 
unique value proposition. We don't usually brand ourselves as "the 
database with the better imports" and we're unlikely to ever be a

match to the giants on the field of engineering.


Automating a postcode import is trivial. The reason Google is slow to do 
it isn't because it's an engineering challenge, it's simply because they 
don't consider it a priority.


Richard makes a good point (that if anything, a manual process that 
allows our human editors with local knowledge - who are what really

sets us apart - to verify and improve the data would be preferable)
but also a questionable one (in suggesting that there are 195
countries in the world having some form of post codes that is also
available as open data - the number is probably one-digit).

I would like to applaud Ken for his roll-up-sleeves approach. It 
shouldn't be too hard to find one house for each of the post codes

in your local area and add the post code to that, which will
ultimately make every post code findable without actually having to
add something as synthetic as a centroid.


There are, typically, between 1,000 and 3,000 new postcodes added every 
month, and postcodes are deleted every month, too. Sometimes, there's a 
mass reorganisation of postcode data which can involve additions and 
deletions of the many tens of thousands in one month. I don't think that 
OSM has anywhere near the number of human editors necessary to keep up 
with that manually.


Mark

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


Re: [Talk-GB] Import UK postcode data?

2019-10-04 Thread Mark Goodge



On 04/10/2019 01:52, nd...@redhazel.co.uk wrote:


This may not be a perfect solution but the information CPO/ONSPD 
contains is still extremely useful for geocoding. Search for a postcode 
and you are _guaranteed_ to get an address in a close vicinity to a 
place you are looking for. How about not needing to start Google Maps 
when searching for a location on the go?


I entirely agree with this. You can search for any postcode on Google 
Maps, Bing Maps, Here Maps and Michelin Maps, to name just the ones I've 
checked right now. The reality is that people expect postcodes to be a 
functional search term on online mapping, at least in the UK, and not 
having it places OSM at a distinct disadvantage compared to the 
commercial mapping operators. Given that postcode data is itself 
available under a compatible licence, refusing to use it because of 
purist notions of what a map should be is, in my opinion, simply a case 
of cutting off our noses to spite our face. It's important that OSM 
gives users what they want from a map, not just what mapping geeks want 
from a map. And users want postcodes - all of them - to be a functional 
search term.


In fact, OSM can easily do better than Google et al when it comes to 
postcodes. One of their biggest faults is the lag on adding new 
postcodes - it can take up to 18 months before new postcodes become 
usable search terms on Google Maps. With an automated import, OSM can be 
as up to date as the latest release of CPO/ONSPD. And that's a positive 
selling point for our data.


Mark

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


Re: [Talk-GB] Import UK postcode data?

2019-10-03 Thread Mark Goodge



On 03/10/2019 01:40, nd...@redhazel.co.uk wrote:


- Code-Point Open is a legal and open source of postcode data. In fact 
it is the _only_ legal source of such data in bulk. All other sources 
are either derived from CPO or are based on local knowledge.


That's not true. The ONS Postcode Database (ONSPD) products are also 
OGL, at least as far as mainland GB postcodes are concerned (NI 
postcodes are somewhat different). And ONSPD is more useful than 
Code-Point Open, partly because it's more amenable to an automated 
update (you can script a regular download of the latest file, unlike OS 
products which need to be manually ordered each time), and partly 
because it includes more meta-data that can also be valuable (for 
example, it includes lookups to GSS codes for a wide range of 
administrative authorities).


- The key (and deliberate) limitation Code-Point Open is that it doesn't 
distinguish between residential postcodes and postcodes assigned to 
"large users". This is not ideal but still useful - we know the postcode 
exists at a given location, we just can't be sure if it is the only 
postcode there.


ONSPD solves this problem, because it includes the "large user" flag.

(Slight tangent here: residential postcodes can be "large user" too; for 
example a university hall of residence with a single address point. 
Postcodes themselves don't distinguish between residential and 
commercial use, and that information isn't reliably held anywhere, even 
in the full PAF, as that information is generally irrelevant to Royal 
Mail's purposes. But it is true that most large user postcodes are 
commercial.)


- Quality of building in OSM database. Large buildings, especially in 
town centres, are often not partitioned correctly. Different parts may 
have different street names and postcodes. Code-Point Open may in fact 
be helpful in finding and correcting such issues.


- Some postcodes are for PO boxes (usually collocated with post offices) 
are are best left out.


You can generally identify Post Office based PO Box postcodes simply by 
looking for postcodes that share identical coordinates. But, of course, 
to do that you need to have all of them; you can't do it reliably on a 
postcode-by-postcode basis.


My recommendation: import missing postcodes "as is" (as points) with 
extra tags denoting the import, import date and an accuracy metric from 
CPO. Keep it searchable and easy to remove or update, if necessary. 
Code-Point Open is updated quarterly and sometimes centroids move to 
another building. Filter out PO boxes and postcodes which are already in 
OSM (I usually check if there is an OSM object with a matching 
addr:postcode within a 10m radius of the code point). Do not attempt to 
merge them with buildings as it is not guaranteed to work in all cases. 
This is best done manually and in some cases it may require a survey.


I agree with all of that, with the exception that I'd suggest using 
ONSPD as the source (for the reasons given above). An advantage of using 
ONSPD is that the presence of the large user flag means that for 
postcodes identified as being large user (if not also PO Box postcodes), 
they do accurately and correctly identify a specific building. So they 
can be merged with the building data where possible.


Mark

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


Re: [Talk-GB] Copyright in OS-derived maps

2019-09-05 Thread Mark Goodge



On 05/09/2019 10:49, David Woolley wrote:

On 05/09/2019 05:48, Warin wrote:

If they had derived their data from OSM .. then all would be fine.


As I hinted before, the use of a red line, and a custom printout from an 
OS detailed map, suggests this is a map for legal purposes.  For both 
the Land Registry and council planning applications, a red line is the 
convention for showing a property boundary.


Or, in planning terms, the application boundary, which may not 
necessarily coincide with ownership boundaries.


But yes, the red line convention is widely used and widely understood, 
so a red outline on a map tends to suggest that it was produced as a 
legal document. In which case, it will definitely be based on an 
underlying OS map.


Until you can get lawyers, the Land Registry, and councils to accept OSM 
derived mapping, this sort of map is always going to be OS derived.


Maps used for legal purposes are always going to be OS (or, maybe one 
day in the future, whatever other company the government decides to 
award the contract to). However useful OSM may be in everyday life, a 
map that anybody can edit clearly isn't going to be suitable as a legal 
record of anything.


Mark

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


Re: [Talk-GB] National Trust Paths organised edit page

2019-09-03 Thread Mark Goodge



On 03/09/2019 09:54, Colin Smale wrote:

For HGVs there is another issue in play. Specialised devices using 
specialised maps are required, to give routing appropriate to the 
vehicle, its mass, length, height, width etc. These devices can be a lot 
more expensive, and harder to find, than consumer devices which are only 
suitable for cars, motorcycles, cycles etc. If a truck driver is 
allowing himself to be directed by Google Maps on his phone for example, 
it will end in tears...


One of the big problems we have is truck drivers using car sat-navs, 
because they're cheaper. Or using older, cheaper truck sat-navs that 
haven't been updated for a while. A lot of older sat-navs, for example, 
will still direct trucks over the closed level crossing here:


https://www.openstreetmap.org/#map=19/52.39148/0.26737

Mark



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


Re: [Talk-GB] National Trust Paths organised edit page

2019-09-02 Thread Mark Goodge



On 02/09/2019 14:30, Jez Nicholson wrote:
Following on from their talk at the OSMUK AGM, the National Trust have 
now created an official 'organised edit' page for their footpath project 
https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/National_Trust_Paths


I'm a little puzzled by one of the lines on the permissions grid on that 
page. There's a line for "Legal RoW but access discouraged", with a 
suggested tagging of "discouraged/private" for pedestrians (and similar 
tags for other users).


Quite apart from the fact that "private" is simply wrong for any public 
right of way, the use of "discouraged" for pedestrian users seems to me 
to also conflict with the wiki, which suggests that this is a functional 
tag (the wiki example is HGV traffic on narrow roads). But public rights 
of way come in all shapes and sizes, from broad, well-maintained paths 
to barely visible routes across difficult terrain. If we want to tag 
their relative ease of use, then surely a more appropriate tag than 
"discouraged" should be used. If a right of way on foot exists, then it 
is, ultimately, up to the user whether they use it or not.


The reason why I'm uneasy with this here, is that it relates to similar 
concerns already expressed by Frederik Ramm. There's quite a lot of NT 
property which is crossed by public rights of way, but that the NT would 
prefer people not to use as they provide a route onto the property that 
bypasses the "official" entrance. I can understand why they'd want to do 
that, but I don't think it's appropriate to reflect that in how the 
paths are mapped in OSM.


Mark

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


Re: [Talk-GB] National Trust Paths organised edit page

2019-09-02 Thread Mark Goodge



On 02/09/2019 14:58, David Woolley wrote:

On 02/09/2019 14:48, Frederik Ramm wrote:

Sometimes they want us to add a "vehicle=no" to a track that has
absolutely no signposts whatsoever locally, meaning that nobody can
verify that vehicles are forbidden and no local motorist would be turned
away


This could conflict with a trend that I believe is developing, at least 
for more formal roads, of removing signage, because it distracts 
drivers, and relying on satellite navigators to provide the information 
instead.


That's certainly not a trend in the UK. At the moment, the problem is 
the opposite: how to ensure that people obey the signs rather than 
following sat-nav. For example:


https://www.cornwalllive.com/news/cornwall-news/lorry-driver-sat-nav-nightmare-683052

One of the issues with relying on sat-nav is that the device data often 
isn't updated very often. Unless the government can impose some kind of 
legally binding SLA on the device manufacturers to ensure that all data 
updates are performed within a specified period of time, then you can't 
rely on people having current information. If a road is closed, then 
people need to know it's closed from the moment it's closed - waiting 
for their navigation software to update isn't good enough!


Whilst this probably doesn't currently apply to prohibitions, a logical 
extension, at some time in the near future, might be to make the 
electronic map definitive in all cases.


If we ever do get a situation where the electronic map is the definitive 
record of prohibitions and other relevant mapping data, then it will 
need to be available via an open licence (presumably OGL, here in the 
UK). So presumably we'd be able to import that directly into OSM via an 
API call or data dump. But it would probably need a set of specific tags 
that don't conflict with those used by people mapping from observation.


Mark

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


Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

2019-07-20 Thread Mark Goodge



On 20/07/2019 10:36, Tony Shield wrote:

Hi

Starting to get a little confused here - my brother lives in Northern 
Ireland and has a BT postcode which he has given me. Am I allowed to put 
into OSM?


You can add the postcode to any address in OSM, if you know the full 
address from personal knowledge. That includes BT postcodes. What you 
can't do is bulk-import BT postcode centroids from a dataset.


Mark

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


Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

2019-07-20 Thread Mark Goodge



On 19/07/2019 22:36, nd...@redhazel.co.uk wrote:

On 19/07/2019 20:29, Mark Goodge wrote:


ONS postcode products are also OGL, so can be reused in OSM and 
similar. They're also more useful than Code-Point Open in that they 
also include lookups to a number of other government codes (such as 
local authority GSS codes). It also differentiates between "large 
user" and normal postcodes, and includes an introduction date and, 
where applicable, a termination date for every valid postcode.


That would be very useful indeed but what is the license of these extra 
features? OGL alone doesn't mean anything if they qualify it with "data 
may contain third party IP" or similar.


It's OGL apart from BT postcodes, which are mentioned separately in the 
licence.



Their website says:

"Our postcode products (derived from Code-Point® Open) are subject to 
the Open Government Licence."


and then:

"If you also use the Northern Ireland data (postcodes starting with 
“BT”), you need a separate licence for commercial use direct from Land 
and Property Services."


I understand it as only the part that already exists in Code-Point Open 
is free, extra information may or may not be free, depending if it comes 
from ONS own data or other sources.


The other information is OGL as that's derived from other published data 
that's already OGL. For example, GSS codes and their associated names. 
The licence page is quite clear about that: postcode lookup data is OGL 
apart from BT postcodes. And those are easy enough to filter out if 
necessary.


Mark

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


Re: [Talk-GB] Ground truth v legal truth

2019-07-19 Thread Mark Goodge



On 19/07/2019 18:05, David Woolley wrote:

On 19/07/2019 15:37, Mark Goodge wrote:
There are, though, two potentially useful open data coordinate mapping 
systems that can be used by the likes of OSM. One is Mapcode, the 
other is Google's Open Location Code (aka Plus Codes). Both have the 
advantage of not only being entirely free and open to use, but can 
also be generated programmatically from a published algorithm - no 
need to hook into an API, just run some code locally.


There is also the extended form of the venerable Maidenhead Locator System.


Ah, that's a new one on me. Looks a pretty simple algorithm, too. Thanks.

Mark

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


Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

2019-07-19 Thread Mark Goodge



On 19/07/2019 15:15, Andrzej wrote:


Indeed, Code-Point Open is less than ideal, the issues are almost
always caused by lack of differentiation between residential and
"large user" postcodes. On the other hand, it is the only legal
source of postcodes we have, other than local knowledge, but the
latter is realistically limited to a dozen or so postcodes per
mapper. Businesses website could also be OK but they are usually
copyrighted. Derived databases, like FHRS, are generally not OK, a
unless also permitted by Royal Mail.


ONS postcode products are also OGL, so can be reused in OSM and similar. 
They're also more useful than Code-Point Open in that they also include 
lookups to a number of other government codes (such as local authority 
GSS codes). It also differentiates between "large user" and normal 
postcodes, and includes an introduction date and, where applicable, a 
termination date for every valid postcode. And, unlike Code-Point Open, 
the ONSPD has a persistent URL that can be used to automate updates.


https://hub.arcgis.com/datasets/ons::ons-postcode-directory-latest-centroids

More generally, the ONS open data geography datasets are a goldmine. 
Another useful one is the Index of Place Names; that has obvious utility 
for OSM as a means of verifying the official spelling of names entered 
by mappers.


Mark

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


Re: [Talk-GB] Ground truth v legal truth

2019-07-19 Thread Mark Goodge



On 19/07/2019 13:50, Andy G Wood wrote:

On Friday, 19 July 2019 13:30:48 BST Martin Wynne wrote:

On 19/07/2019 12:55, David Woolley wrote:
...


(As a variation on the last point, one of my pet hates, these days, is
how few houses now have house numbers in the UK.  It make it difficult
to give accurate locations for fly tips


Have you seen: https://what3words.com/

[...]

"3. Rights in what3words Materials and your licence to use them
Yes, unfortunately W3W is useless for any open data application as it 
exists primarily as a commercial service aimed at the likes of satnav 
manufacturers rather than being available for anyone to use. (It also 
doesn't work globally as the words are language specific).


There are, though, two potentially useful open data coordinate mapping 
systems that can be used by the likes of OSM. One is Mapcode, the other 
is Google's Open Location Code (aka Plus Codes). Both have the advantage 
of not only being entirely free and open to use, but can also be 
generated programmatically from a published algorithm - no need to hook 
into an API, just run some code locally.


Personally, I prefer Mapcode, its codes are more memorable (and, if you 
take the country for granted, can be very short). But I suspect that OLC 
is more likely to gain widespread use simply because it's backed by Google.


https://www.mapcode.com/
https://plus.codes/

Mark

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


Re: [Talk-GB] UK coastline data

2019-07-14 Thread Mark Goodge



On 14/07/2019 00:39, David Woolley wrote:

On 13/07/2019 22:21, Colin Smale wrote:
So what was your point again about internal waterways? The "extent of 
the realm" is not the 12-mile limit, it is ±MLW, isn't it?


Assuming it is mapped correctly, this is an example of an administrative 
boundary that is outside the low water mark: 



Yes, and that's probably a good example of where "the coast" crosses an 
estuary rather than continuing up it.


After all, if MLW was always the admin boundary, then most of the Thames 
through London would be outside local government control. In reality, of 
course, it's part of the GLA and partitioned between various London 
Boroughs. Pragmatically, admin boundaries cross the MLW where 
appropriate to maintain meaningful local government areas.


I don't know if there is an official formula for when admin boundaries 
do actually do this. Looking at boundary maps, it appears to be the 
principle that if opposite banks of the estuary are close enough, the 
admin boundaries cross the estuary at that point and then run up the 
centre (or thereabouts) of the river if the river itself is a boundary 
(which it often is). But I don't know what amounts to "close enough". On 
the Thames, it's just to the west of Southend, as illustrated in the 
above link. On the  Severn, it's just downstream of the Severn Bridge. 
On the Humber, it crosses from Spurn Point. But admin boundaries don't 
cross The Wash, and in Scotland admin boundaries don't cross the Forth 
until upstream of Kincardine. So it seems to be based on what is locally 
appropriate rather than a rigid measurement. Which is something you 
can't map simply by observation; you have to know what the actual 
consensus is.


Mark

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


Re: [Talk-GB] UK coastline data

2019-07-12 Thread Mark Goodge



On 11/07/2019 20:38, Borbus wrote:

The mess often happens because mappers don't necessarily know what a 
"coastline" is (I didn't before I researched it). For land-based maps 
the coastline that is shown is generally shown is mean high water level. 
The other "coastline" that is also shown on land-based maps is the mean 
lower water level. The bit between these lines is the intertidal zone. 
This is admittedly a bit less interesting, but it's certainly useful 
when there are causeways and other features in the intertidal zone.


It's also one of the most useful from a leisure perspective, as a lot of 
popular beaches fall primarily or wholly in the intertidal zone. Take, 
for example, Hunstanton in Norfolk - at high tide the sea comes all the 
way up to the sea wall, and there is no beach as such on the town centre 
seafront. But, at low tide, there's a large expanse of sand. And, in 
between, there are differing amounts of sand visible!


FWIW, I think that both OSM and OS currently show this correctly, with 
the intertidal beach being mapped as sand (as are the sand and mud banks 
further south near Heacham and Snettisham). Google, on the other hand, 
seems to be ignoring the intertidal area completely and mapping the 
coastline according to what is visible on their own aerial imagery (for 
a good example of that, zoom into Hunstanton Sea Life Centre on Google 
maps and then switch between map and satellite view).


Mark

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


Re: [Talk-GB] Tagging a St John's Ambulance base

2019-07-10 Thread Mark Goodge



On 10/07/2019 19:08, Ben Proctor wrote:

Hello mapping people

There is a building and yard in Hereford used by St John's Ambulance. 
The building functions as a meeting venue (like a scout hut but for St 
John's) and some vehicles are stored in the yard.


https://www.openstreetmap.org/#map=19/52.06051/-2.71419

How would you tag this?

It's currently amenity=doctors which doesn't seem right. 
emergency=ambulance_station doesn't seem to describe this use.


I was heading down amenity=community_centre route but I'm not sure 
that's right either.


A quick search for St John's Ambulance reveals a wider range of 
approaches in other areas.


I'd be inclined to go for community centre, in this case. It isn't an 
emergency ambulance station, which is what the 
emergency=ambulance_station tag is for (and, in any case, is rapidly 
becoming obsolete with the new distributed means of organising an 
ambulance service), and it isn't a doctor or a clinic either. And the 
main purpose of the building (as opposed to the yard) is for things like 
first aid training (both for St John volunteers themselves and the wider 
community). So a community centre is probably closest.


Mark

Mark

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


Re: [Talk-GB] Newish user causing damage-...

2019-06-23 Thread Mark Goodge



On 23/06/2019 16:50, Andy Townsend wrote:

https://www.openstreetmap.org/user_blocks/2922

(apologies for terseness - sending from pub beer garden)


Best place to be sending it from :-)

Mark

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


  1   2   >