where i live there are many footpaths parallel to main streets. CS/OSM does not recognize those footpath and they never have any nodes on them. But unfortunately the route builder algorithm seems to prefer those paths.
Technically those footpaths have nodes in OSM (see below). Footpaths generally don’t have names though and the ‘Path’ & ‘Footway’ are ignored in CS import anyway (Google Doc of types imported & further info on import process.
As to why the route builder may route onto path vs street, that’s likely because the builder is looking for ways with foot access set to yes (or other allowed options). Which makes sense because we are traveling by foot but I get what you mean since we are aiming to complete streets. I’ve found when building routes, if I do see it want to go onto a path, I’ll draw shorter spans between clicks; especially around corners I’ll make one near end of one street and just around bend to where I’m turning. From there you should be able to route straight for the rest of that block without it jumping curb onto footpath/sidewalk.
This doesn’t seem like a huge issue, as long as that walking path isn’t too far from the street (not to say it shouldn’t be fixed).
I’m using the GraphHopper Routing API, so there might be a way to adjust my request in a way that prefers the actual street. I can look into that.
Not a dev but was looking at Grasshopper API and stumbled upon ‘weighting’. At least based on their description, it sounds like that may be part of change to deprioritize sidewalks. There is also a ‘snap_preventions’ though that may be overkill.
