Discovered some time ago, when attempting to plot a route along Pennine Way in Cheviots the ‘snap to’ deviated away from Way, for section between ‘The Street’ (east of Mozie Law) and North West of Green Law (just above the ‘O’ of Cheviots on map).
OS maps advised reporting to yourselves as this is where their data comes from.
Would appreciate any feedback as to why this section has been left like this, and if anything can be done to correct?
We’ll need to know exactly what the issue is and how things appear on our own map to be able to investigate. I assume this is the area we’re talking about: OpenStreetMap
I haven’t actually walked it yet. As only doing day walks alongPennine Way it is taking some planning to find a parking spot and route to parts I need to get to!
Have been out of action for quiet a while so struggling with distances required to walk.
Did report this to OS Maps a long while back, when initially undertaking route planning, so issue has been there for a long time.
I’m afraid that without some more information about exactly what you think is wrong in OpenStreetMap, we’re unlikely to be able to provide any help. Can you answer what I asked in the first reply to your initial post?
Reading your initial post again, I’m wondering if you were trying to plot a route using some third-party (OS?) tool, and the route you were being given (with ‘snap to’) turned on didn’t match the kine of the footpath indicated on the base map. If this is what happened, please let us know what the tool is, and where you believe the basemap and snap-to data come from. (Presumably OS have told you that one of them is OpenStreetMap data, but which one, and what is the other one?) Could you also provide a screenshot of the issue so we can take a closer look?
Can you explain what exactly you think is wrong? It’s a little unclear from your description.
If it helps, here is the public bridleway in OSM (light blue) overlaid with what the local authority things the bridleway is (dark red), and what OSM thinks the Pennine Way is (purple dots). You can zoom right in to where the problem starts and ends and just copy the location from your browser address bar.
What OSM thinks is a bridleway agrees with the LA data, but after that there is a discrepancy. I can’t comment on this area, but elsewhere (e.g. Yorkshire) this isn’t unusual. What I normally do when I find something like this is go and have a look, see what the path is, and see what is waymarked.
There do not appear to be any screenshots in this forum thread.
There are many organisations that use OpenStreetMap data in their products and none of us are familiar with the details of all of them.
So far you have said that this is occurring in an OS (presumably Ordnance Survey) product and your phrasing appears to suggest that it is some sort of app or website, but until we can tie that back to specific data visible on OpenStreetMap.org we won’t be able to tell what if anything is the issue with the underlying data.
Which app, website or printed product are you using and are you able to publicly share images of the issue on this forum that demonstrate what you think is incorrect?
I’m not the original poster obviously, but as a bit of background a couple of these sorts of questions have crossed the DWG’s desk in the past, so perhaps I can fill in a few details from there - I’m guessing that they might apply here too.
What you used to get in the free OS app was OSM data, looking very similar to what you can see online here. That path that you can see at the left is from OSM. If you move the map a bit to here you can see where the OSM “public bridleway” finishes, although designation information isn’t shown in this OS map.
My understanding is that if you pay you get the option of other map types to the default Mapbox one, including ones from OS themselves. That would show the OS’s “official” location for the bridleway, which does not match the path in OSM - as noted above there may or may not be an actual path on the “official” route, and OSM may just be wrong and actually the path needs updating in OSM. Someone needs to go there and see.
Where it gets complicated is when someone tries to calculate a route. Do the OS have fully routable data for that bridleway? My guess, based on the experience of a DWG correspondent from a few years ago, was that they did not (then). The OP’s question suggests that they might not now, either.
This might explain why a displayed map (perhaps based on OS Explorer) shows a bridleway in one place, and a calculated route (based on OSM) does not use that, but an adjacent path.
If anyone reading this has an OS app installed with coverage of this area it’d be great to know:
what appears on screen and what map backgrounds are available
if a route is calculated in this area, does it follow the official route of the “public bridleway” or the path in OSM?
if a non-OSM map background is used, but routing uses OSM, what accreditation is shown at the bottom of the screen?
I’ve adjusted it so the path goes through the gate. I’ve also added foot, horse and bicycle access tags based on the existing designation and also the local authority data.
Of the three router implementations on osm.org, the OSRM one thought that it couldn’t route pedestrians on a highway=bridleway without a foot access tag (that’ll resolve when OSRM updates). I’ve no idea what the OS app uses internally for routing, but that will need an app or app data update before it sees any change (for the gate or the access tagging).