[Talk-GB] Cheers Drive, Bristol
I wondered if it might have come from OS OpenData so I downloaded the latest OS Open Names, but no it isn't there yet. Unless it's come from OS MasterMap (anyone on here have access to check?), it does appear the council are collaborating with the goog. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Features which move...apparently spurious edits: iD bug or "finger trouble"?
On Sat, Feb 15, 2020 at 03:41:40PM +, Andy Townsend wrote: > > Has anyone seen something similar? Presumably this could happen to nodes > generally, there is no reason to think amenity=post_box is a factor. The threading here seems to be odd. Anyway, when I was new to OSM and using an old slow machine with josm, it was easy to drag nodes and ways by accident without noticing. I once moved part of a major road by several kilometers: I noticed about a week later and corrected it. I was very surprised that no one else picked it up earlier. Maybe other editors produce the same problems when run on slow limited machines? Developers may not notice because they are usually using fairly powerful systems. An accidental drag may not show up for a second or more and can be overlooked. ael ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Features which move...apparently spurious edits: iD bug or "finger trouble"?
> Has anyone seen something similar? Presumably this could happen to nodes generally, there is no reason to think amenity=post_box is a factor. Exactly that pattern no - but occasionally new users manage to drag nodes by accident. > Is there any way to identify features which have moved by more than whatever distance might be considered "normal" for someone correcting a previously incorrect position? This might be key to further investigation and correction. Yes - https://www.openstreetmap.org/changeset/81021329 is an example of someone doing it. I'm not sure what software they're using though; you'd have to ask. The mapper who added the comment there is I think German, but I've had plent of conversations with them in English. > I can provide the node and changeset numbers if anyone wants to look into the details and perhaps can spot a pattern, That might be useful so that someone can have a look. If you don't want to post anything publicly you could perhaps just mail me (or anyone else who wants to have a look) rather than post it forever on a public mailing list. > There are some philosophical question here: which features are "allowed" to move and by how much? Natural features probably shouldn't. They do - a bit. For example, while lowland waterways are normally a pretty good match for OS OpenData StreetView (which is from some time ago now) often their upload counterparts have changed quite considerably. Best Regards, Andy On 15/02/2020 12:29, Dan Glover wrote: If there's a better place, please direct me appropriately... I've been using Robert Whittaker's Post Box tool to help fill gaps and fix anomalies in the CT postal area. I think I've now found a pattern which leads to "ghost" entries in locations where there has never been a post box and leaves the actual post box either unmapped or with a new node. I have three examples where the general scenario seems to have been: 1. Mapper "A" creates a node with amenity=post_box. Other details such as reference and collection time may or may not have been entered at this point. 2. Time passes, possibly with edits to the node, but no change of position. 3. Mapper "B" does something apparently unrelated. In the examples I have seen it involves multiple ways/nodes, though not necessarily vast numbers. 4. The node created at (1) is re-positioned in a fairly random manner as part of the same changeset. 5. [possibly] Mapper "C" spots the missing post box and creates a new node for it. The node from (1) is still "out there", in one case it was 1.3 km from the original (correct) position. Note: it transpires Mapper "A" in the three examples is the same user. Three different "B"s. I suppose the first questions are: - Has anyone seen something similar? Presumably this could happen to nodes generally, there is no reason to think amenity=post_box is a factor. - Is there any way to identify features which have moved by more than whatever distance might be considered "normal" for someone correcting a previously incorrect position? This might be key to further investigation and correction. I can provide the node and changeset numbers if anyone wants to look into the details and perhaps can spot a pattern, The edits are by three different users on widely spaced dates and the iD versions are all different. The most recent example was in September 2018, so it's not likely the mapper would remember anything. Robert's tool shows the distance between OSM node and Royal Mail data, which is how I found one of the examples - but it is "normal" for RM data to have discrepancies, sometimes fairly significant. The other two had relatively minor offsets and were picked up through "local knowledge" - but analysis of old/new position could have highlighted them. Unfortunately post boxes do get moved whilst retaining their RM reference but I'd expect that to be done in OSM by creating a new node and deleting the old. There are some philosophical question here: which features are "allowed" to move and by how much? Natural features probably shouldn't. Man-made ones are probably something new when they do move. Boundaries, however, are subject to revision, roads and footpaths get re-aligned. Also what's an acceptable margin for a correction? Dan ___ 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] Features which move...apparently spurious edits: iD bug or "finger trouble"?
If there's a better place, please direct me appropriately... I've been using Robert Whittaker's Post Box tool to help fill gaps and fix anomalies in the CT postal area. I think I've now found a pattern which leads to "ghost" entries in locations where there has never been a post box and leaves the actual post box either unmapped or with a new node. I have three examples where the general scenario seems to have been: 1. Mapper "A" creates a node with amenity=post_box. Other details such as reference and collection time may or may not have been entered at this point. 2. Time passes, possibly with edits to the node, but no change of position. 3. Mapper "B" does something apparently unrelated. In the examples I have seen it involves multiple ways/nodes, though not necessarily vast numbers. 4. The node created at (1) is re-positioned in a fairly random manner as part of the same changeset. 5. [possibly] Mapper "C" spots the missing post box and creates a new node for it. The node from (1) is still "out there", in one case it was 1.3 km from the original (correct) position. Note: it transpires Mapper "A" in the three examples is the same user. Three different "B"s. I suppose the first questions are: - Has anyone seen something similar? Presumably this could happen to nodes generally, there is no reason to think amenity=post_box is a factor. - Is there any way to identify features which have moved by more than whatever distance might be considered "normal" for someone correcting a previously incorrect position? This might be key to further investigation and correction. I can provide the node and changeset numbers if anyone wants to look into the details and perhaps can spot a pattern, The edits are by three different users on widely spaced dates and the iD versions are all different. The most recent example was in September 2018, so it's not likely the mapper would remember anything. Robert's tool shows the distance between OSM node and Royal Mail data, which is how I found one of the examples - but it is "normal" for RM data to have discrepancies, sometimes fairly significant. The other two had relatively minor offsets and were picked up through "local knowledge" - but analysis of old/new position could have highlighted them. Unfortunately post boxes do get moved whilst retaining their RM reference but I'd expect that to be done in OSM by creating a new node and deleting the old. There are some philosophical question here: which features are "allowed" to move and by how much? Natural features probably shouldn't. Man-made ones are probably something new when they do move. Boundaries, however, are subject to revision, roads and footpaths get re-aligned. Also what's an acceptable margin for a correction? Dan ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Cheers Drive, Bristol
I once watched a conference presentation on the in-house software Google
use to update their map data (forget where I came across this). While they
didn't reveal full information on it, a large part of their workflow is
semi-automated and mostly comes down to humans reviewing and intervening in
areas flagged as problematic or requiring updates.
If I remember correctly, their sources for this information were either
user feedback ("report a map issue"); data provided directly by 3rd
parties; or data indirectly sourced from news reports and similar
(presumably using pretty sophisticated machine learning systems).
Wouldn't surprise me if this was either provided directly to Google by the
local council or flagged up by a semi-automated system.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Cheers Drive, Bristol
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. But at least we can say, even in this case, that OSM is the more accurate reflection of reality. On Sat, Feb 15, 2020 at 11:47 AM Jez Nicholson wrote: > Just been reading about the naming of a new road in Bristol "Cheers Drive" > which is apparently a local way to thank a bus/taxi driver > https://www.bbc.com/news/uk-england-bristol-51501412 > > Thing that caught my eye was the reference to Google Maps having it on > already which made me wonder how, because the road signs haven't been > installed yet? Are they importing road change notices from the Council? > > https://www.openstreetmap.org/#map=17/51.46730/-2.54036 > > > https://www.google.co.uk/maps/place/Cheers+Dr,+Speedwell,+Bristol+BS5+7FQ/@51.4669956,-2.5405969,17z/data=!4m2!3m1!1s0x48718fc9fa803fa1:0x28c4a3d7786bfeab > ___ > 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] Cheers Drive, Bristol
Just been reading about the naming of a new road in Bristol "Cheers Drive" which is apparently a local way to thank a bus/taxi driver https://www.bbc.com/news/uk-england-bristol-51501412 Thing that caught my eye was the reference to Google Maps having it on already which made me wonder how, because the road signs haven't been installed yet? Are they importing road change notices from the Council? https://www.openstreetmap.org/#map=17/51.46730/-2.54036 https://www.google.co.uk/maps/place/Cheers+Dr,+Speedwell,+Bristol+BS5+7FQ/@51.4669956,-2.5405969,17z/data=!4m2!3m1!1s0x48718fc9fa803fa1:0x28c4a3d7786bfeab ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
