Re: [Talk-GB] Paths on Wimbledon Common
It seems a bit odd for Osmose to be flagging highway=footway, foot=yes as an error just because foot access is implied by default. Whilst there might be the tiniest bit of redundancy I can't see any particular reason to remove it and, indeed, there might be an argument that an explicit tag is always preferable to an implied value. OT, but I've personally always viewed foot=permissive as a caveat for the end user that a way might be closed. I only add it where a route is explicitly stated to be permissive on the ground, is actually known or likely to be shut from time to time, or is clearly an informal path. Many paths through parks and housing estates etc. are clearly intended for permanent public use and about as likely to be closed as the nearby highways. Kind regards, Adam ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The curious case of USRN 20602512
On 10/07/2020 22:27, Nick wrote: Hi Lester I think there needs to be some thought as to the "proper channel to feed corrections to the 'data officer' responsible". It took me months to get a 'data officer' to correct the location of a single UPRN, so my thought is that this needs to be a 'public' (open) channel that shows a) the number of issues identified (the rationale for making data open) and b) how long it takes for these to be investigated and resolved (if appropriate). TOTALLY AGREE ... local authorities MAY be required by law to provide the data, but they get no funding, and no support to manage that data yet third parties have been making money from it! SO the next step is to document all the mistakes. There should be no assumption that the current data set IS correct, which is why it should be used as a parallel layer and not simply imported over what may well be more accurate data. 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 ... ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The curious case of USRN 20602512
Hi Lester I think there needs to be some thought as to the "proper channel to feed corrections to the 'data officer' responsible". It took me months to get a 'data officer' to correct the location of a single UPRN, so my thought is that this needs to be a 'public' (open) channel that shows a) the number of issues identified (the rationale for making data open) and b) how long it takes for these to be investigated and resolved (if appropriate). 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 ... ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
Hi, I'm the changeset commenter, I added the foot=yes on the common based on it being a registered common with definite legal access. I also add foot=yes to signed public footpaths. I would only add foot=designated where there is a blue person sign or similar (not a green/wooden public footpath sign) and where doing so adds some value over just using the default. And I'm not sure I've ever actually used it. In general I'm wary of the legal aspect of the tag, as in most cases a mapper has no idea of the legal status. My approach (SW London urban areas) is based on a less legalistic interpretation: * foot=private if it looks private * "customers" if it is obviously for customers * "destination" if it is obviously just for those going somewhere in particular, such as a path to a school or church * "permissive" if it is likely to be private land but it is known or almost certainly used by others, paths on housing estates being an example * "yes" if I'm confident of the legal status, such as common land and public footpaths * nothing otherwise, and this includes sidewalks Stephen On Fri, 10 Jul 2020, 17:02 Adam Snape, wrote: > Hi, > > It's worth pointing out that if Wimbledon Common is (as I assume) > registered as common land then there would normally be a legal right of > access on foot under the Countryside and Rights of Way Act 2000, so > foot=yes would be correct. > > Kind regards, > > Adam > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
>I have been doing some tidying based on Osmose, including the warning for >highway=footway foot=yes, which is often left over >from a preset in Potlatch >1. > >https://www.openstreetmap.org/changeset/87672607 > >I got a changeset comment querying the edit. Hi Andrew, My understanding is that highway=footway with no access tags has an implied foot=yes. This, however is entirely different from highway=footway + foot=yes which explicitly states that access is allowed. Without the explicit tag, whilst routing will be the same, it could just be that the mapper adding the path did not know whether access was allowed. In my view, if there is a rule check, it should be checking that there IS either a foot= tag or an access=tag and warning if there isn't. For me however, the biggest problem is ways tagged with highway=footway, access=no and foot=yes - this really should be warned about, as without reading the change history and notes it is not possible to determine whether the access=no was intended to indicate that other access than foot is disallowed (which is superfluous) or was added to say the path has been closed, forgetting that foot=yes will override it. The feedback comment mentioned 'designated' - I think foot=designated should ideally only be used in conjunction with the designation= tag, as otherwise you don't know what designation designates the access. There are also lots of ways tagged with values of 'designated' for transport modes where the mapper had an incorrect understanding of what it meant, so without the accompanying designation tag, these values should be taken with a pinch of salt. Regards, Mike ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
Hi, It's worth pointing out that if Wimbledon Common is (as I assume) registered as common land then there would normally be a legal right of access on foot under the Countryside and Rights of Way Act 2000, so foot=yes would be correct. Kind regards, Adam ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The curious case of USRN 20602512
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
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
Re: [Talk-GB] Paths on Wimbledon Common
On Fri, 2020-07-10 at 11:54 +, Andrew Hain wrote: > I have been doing some tidying based on Osmose, including the warning > for highway=footway foot=yes, which is often left over from a preset > in Potlatch 1. > > > > > > https://www.openstreetmap.org/changeset/87672607 > > > > > > I got a changeset comment querying the edit. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I note you have removed foot=yes from highway=footway. My > understanding is that the default for a footway is foot=designated, > but designated requires an explicit sign. the paths on Wimbledon > Common do not have an explicit sign, but are legally > accessible, hence foot=yes. Perhaps osmose is wrong.Any comments? > --Andrew > > > > Assuming that you can walk there and from other comments in this thread you can, then what harm was the tag doing? QA tools, like compiler warnings, do need to be used with care. These are just warnings, not errors, which say you may want check this. They are not saying this must be fixed. Phil (trigpoint) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The curious case of USRN 20602512
Thank you for this absolute masterpiece of detective work, Marc! I'd never thought that looking through old Notes would spark such an interest :) As reported before, my own dip into having USRN data underlying JOSM at that particular point showed that this stub (in USRN the part where the barrier is to the northeast of the way isn't shown, so I guess that's really a small part of highway=footway) is recorded with the USRN you named. So I also believe that this isn't something to find copyright infringements - because the way exists, Google Street view clearly shows people walking along that way. 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? Kai Am 10. Juli 2020 12:27:24 MESZ schrieb 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
Re: [Talk-GB] Paths on Wimbledon Common
Jul 10, 2020, 14:49 by ajt1...@gmail.com: > On 10/07/2020 12:54, Andrew Hain wrote: > >> I have been doing some tidying based on Osmose, including the warning for >> highway=footway foot=yes, which is often left over from a preset in Potlatch >> 1. >> >> https://www.openstreetmap.org/changeset/87672607 >> > If Osmose is flagging "highway=footway;foot=yes" as a warning I'd suggest > that that is a problem that needs logging with Osmose. > It may be the best to make it a bit smarter - it is a completely valid suggestion in for example Poland. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
On 10/07/2020 13:35, David Woolley wrote: > On 10/07/2020 13:11, Colin Smale wrote: >> What does "legally accessible" mean? Are they Public Footpaths? Do we >> tag all Public Footpaths with an explicit "foot=yes" or is >> "designation=public_footpath" enough? >> > > I don't know the situation in Wimbledon Common, but most footpaths in > public park are more correctly described as access=permissive. foot=permissive might be better, as that doesn't imply anything at all for other transport modes. > > My understanding is that designated only has meaning if combined with an > access type tag with a value of designated. > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The curious case of USRN 20602512
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 ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
(apologies for the double reply) I just remembered I wrote a diary entry last year about this: https://www.openstreetmap.org/user/SomeoneElse/diary/391053 . That has some useful links in such as a pointer to the start of "designation" tagging, in 2009: https://lists.openstreetmap.org/pipermail/talk/2009-March/035412.html . Best Regards (again), Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
On 10/07/2020 12:54, Andrew Hain wrote: I have been doing some tidying based on Osmose, including the warning for highway=footway foot=yes, which is often left over from a preset in Potlatch 1. https://www.openstreetmap.org/changeset/87672607 If Osmose is flagging "highway=footway;foot=yes" as a warning I'd suggest that that is a problem that needs logging with Osmose. Speaking for myself, I've tagged "highway=footway" as "foot=yes" (where there is a legal right of way, such as a public footpath in England and Wales, or across access land), as "foot=permissive" where there isn't a legal right of way but general access is permitted (perhaps in parks/gardens that are occasionally closed but aren't restricted to "customers" and where there is no legal right of access) and as "foot=designated" where there's actual signage that suggests that foot traffic should go _this_ way rather than some other way which would otherwise be legal. I'd also use "designation=public_footpath" if appropriate (and also set "foot=yes" on those to make it clear to everyone who might not understand a "designation" tag). Prior to that tag being adopted, there was some use of "foot=designated" to indicate "this is a public footpath" but about 10 years ago or so (I think) people started using "designation=public_footpath" instead. In summary - I'd agree with the changeset commenter that "foot=yes" was useful on those paths as it made it explicit that there was legal access for foot traffic despite there being no public footpath there. Best Regards, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
On 10/07/2020 13:11, Colin Smale wrote: What does "legally accessible" mean? Are they Public Footpaths? Do we tag all Public Footpaths with an explicit "foot=yes" or is "designation=public_footpath" enough? I don't know the situation in Wimbledon Common, but most footpaths in public park are more correctly described as access=permissive. My understanding is that designated only has meaning if combined with an access type tag with a value of designated. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
The changeset comment seems backwards to me, foot=designated is more specific than foot=yes (which would be the default for any mapped footpath). On Fri, Jul 10, 2020 at 1:12 PM Colin Smale wrote: > What does "legally accessible" mean? Are they Public Footpaths? Do we tag > all Public Footpaths with an explicit "foot=yes" or is > "designation=public_footpath" enough? > > > > On 2020-07-10 13:54, Andrew Hain wrote: > > I have been doing some tidying based on Osmose, including the warning for > highway=footway foot=yes, which is often left over from a preset in > Potlatch 1. > > https://www.openstreetmap.org/changeset/87672607 > > I got a changeset comment querying the edit. > > > >- I note you have removed foot=yes from highway=footway. My >understanding is that the default for a footway is foot=designated, but >designated requires an explicit sign. the paths on Wimbledon Common do not >have an explicit sign, but are legally accessible, hence foot=yes. Perhaps >osmose is wrong. >- Any comments? >- -- >- Andrew > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
What does "legally accessible" mean? Are they Public Footpaths? Do we tag all Public Footpaths with an explicit "foot=yes" or is "designation=public_footpath" enough? On 2020-07-10 13:54, Andrew Hain wrote: > I have been doing some tidying based on Osmose, including the warning for > highway=footway foot=yes, which is often left over from a preset in Potlatch > 1. > > https://www.openstreetmap.org/changeset/87672607 > > I got a changeset comment querying the edit. > > * I note you have removed foot=yes from highway=footway. My understanding is > that the default for a footway is foot=designated, but designated requires an > explicit sign. the paths on Wimbledon Common do not have an explicit sign, > but are legally accessible, hence foot=yes. Perhaps osmose is wrong. > * Any comments? > * -- > * Andrew > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Paths on Wimbledon Common
I have always believed that highway=footway in the UK implies foot=yes (and not foot=designated), though I actually don't know if UK tagging practice is successfully documented. IMHO the use of "designated" is quite specific and probably shouldn't be assumed as an invisible default. Best Dan Op vr 10 jul. 2020 om 12:55 schreef Andrew Hain : > I have been doing some tidying based on Osmose, including the warning for > highway=footway foot=yes, which is often left over from a preset in > Potlatch 1. > > https://www.openstreetmap.org/changeset/87672607 > > I got a changeset comment querying the edit. > > > > > > >- I note you have removed foot=yes from highway=footway. My >understanding is that the default for a footway is foot=designated, but >designated requires an explicit sign. the paths on Wimbledon Common do not >have an explicit sign, but are legally accessible, hence foot=yes. Perhaps >osmose is wrong. >- Any comments? >- -- >- Andrew > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Paths on Wimbledon Common
I have been doing some tidying based on Osmose, including the warning for highway=footway foot=yes, which is often left over from a preset in Potlatch 1. https://www.openstreetmap.org/changeset/87672607 I got a changeset comment querying the edit. * I note you have removed foot=yes from highway=footway. My understanding is that the default for a footway is foot=designated, but designated requires an explicit sign. the paths on Wimbledon Common do not have an explicit sign, but are legally accessible, hence foot=yes. Perhaps osmose is wrong. * Any comments? * -- * Andrew ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The curious case of USRN 20602512
Hi Mark Brilliant comment - "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". Now we need the evidence (errors) collated centrally (OSM?). On 10/07/2020 11:27, Mark Goodge wrote: 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
Re: [Talk-GB] The curious case of USRN 20602512
Hi, On 10/07/2020 11:27, Mark Goodge wrote: So this is a bit of a warning, really, for the open mapping community. Although the open data release of USRN ids and coordinates is welcome, don't be tempted to look up street names on the street list published, with a restrictive licence, on https://www.findmystreet.co.uk and then copy them to our own data. Because it simply isn't reliable enough as a guide to actual usage, even if it is what the "official" name of the road may be. Stick to OS Open Data and local knowledge. Thanks - that's an interesting and informative tale about 'canonical' sources being sourced by human beings from complex and contradictory data. Some years ago, I remember being rather surprised investigating differences between my own surveys and OS open data using ITO tools. After double checking the 'ground truth', OSM is closer to reality than OS in several places around my area - perhaps 3 diffs across a 45k population town (Cramlington, NE23). Geography and human society is more complex with the same space being called many things over time, and by different groups. How many small towns didn't have a 'High Street' until an OS surveyor first visited it and wrote a name down? How many 19th century terraces originally had the buildings named, rather than the surrounding streets? Working in telecoms, I understand the benefits of a UPRN / USRN, however as a geographer they still feel a bit like a more precise version of 'High Street'. I still added U*RN tags to my local area - like a 21st century alt_name tag! :-) James -- James Derrick li...@jamesderrick.org, Cramlington, England I wouldn't be a volunteer if you paid me... https://www.openstreetmap.org/user/James%20Derrick ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] The curious case of USRN 20602512
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
