Snap to "cycle/walking/etc routes" option for navigation
Opened this issue · 12 comments
I often use OsmAnd to pre-plan cycle node-based routes. Currently, I let OsmAnd plan a route to get a rough idea of the distance, then do some manual routing along cycle (node network) routes, writing down the node numbers for quick and easy navigation on the way (i.e. I do not use OsmAnd navigation during the trip, but the node-based signposts where possible).
It would be nice if OsmAnd could support this case a bit better. A (seemingly) simple way to do so would be to have a "prefer cycle routes" option for navigation, which would make the router assign a (significant) penalty to roads that are not part of cycle routes. This penalty should be big enough to allow the generated route to be significantly longer than a route that does not use cycle routes, since a route that mostly follows the cycle node network but regularly takes shortcuts is again not so useful.
My usecase is for cycling, but I think the same would be useful for walking, horse riding, etc.
You could maybe add a distinction between regular routes and node networks, but I'm not sure if that's very useful. Looking at cycle routes in the Netherlands, most non-node cycle routes are also node network cycle routes, and the non-node routes are sparse enough to not be too useful for routing between arbitrary points. I think a similar thing holds for walking routes.
Note that this issue is not about adding a small preference for cycle routes and cycleways, in order to use cycle routes over other roads when they are about the same length. This is the subject of other issues already (e.g. #9576 and #6022 for example). This issue about adding a big preference, to generate routes that almost exclusively use cycle routes.
To support my usecase even better, it would be nice if the turn-by-turn instructions would also include cycle node numbers, but I've reported a separate issue for that: #9596.
Right now we consider to add as a separate option for Plan route i.e. it won't be standard for navigation but it will be for Plan route, it is combined with another issue where you will click on the Route or on the next Route Network point, so the route will be calculated along the route. Sometimes these routes don't match the best or the fastest route but obviously people would like to select it, so it's easy to follow signs visible on the ground
I'm not sure I follow what you're saying exactly. How would the UX flow for this be? Does a user have to select routes or network nodes on the map for this? When you say "Plan route", do you mean the current screen where you enter departure/destination locations?
Nope, there is a new button Plan a route on the drawer. Yes, user will be able to click on Cycle node or on the visible route and select it as a segment for own navigation
Ah, I see it in the nightly, thanks. That's what used to be "measure distance", but a bit more powerful and easy to do route calculation between points as well. If you then select cycle nodes (not necessarily directly adjacent) and it automatically plans cycle routes between them, that would indeed by useful and for a lot of usecases even better than doing this with the directions UI.
However, I would think a feature like this would still be useful for the directions UI as well. Sometimes I think I'd want to go from A to B using as much cycle routes as possible, and I'd want to specify A and B by address, rather than selecting them on the map (which is what the Plan Route offers now, I think).
Nope directions are only will remain for Navigation from Point A to Point B, so it will be always short / fast route based on certain conditions.
It won't be considered as navigate me through a picturesque route or find most beautiful places to visit.
- Navigation is a utility function
- Plan a route is trip-planner
The routes are not necessary fastest, shortest or best routes. Parameters like prefer are not numerical, so there will be an error.
Nope directions are only will remain for Navigation from Point A to Point B, so it will be always short / fast route based on certain conditions.
I'm not suggesting to change that. I'm suggesting to allow "Use only cycle routes" as part of "certain conditions".
Navigation is a utility function
My usecase is cycle holiday, where I want to get from one camping to another camping, but (where possible) only use ways that are also cycle routes (because they are more likely to be bike-friendly, and it allows easier offline navigation based on routes). It would be a great utility for me if I could just punch in the starting and ending addresses and then see how long such a trip would be.
The routes are not necessary fastest, shortest or best routes. Parameters like prefer are not numerical, so there will be an error.
How is "Prefer cycle routes" fundamentally different from "Prefer byways"?
-> Byway is a special tag of the road
-> Routes are relations and often have gaps in the middle of the route.
What you ask is pretty easy to do and give feedback to us. Please modify routing.xml https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml and open it with OsmAnd ( or Change it in navigation settings ).
The tags are possible to use and increase priority:
network=rcn
network=lcn
network=ncn
route_bicycle=
<way attribute="priority">
<select value="2" t="route_bicycle" v=""/>
<select value="2" t="network" v="rcn"/>
<select value="2" t="network" v="lcn"/>
....
Can you give a short help please:
if there are setting which are all valid at same time, which of them "wins" ?
example:
select value="1.8" t="bicycle" v="designated"/>
...
select value="1.1" t="surface" v="compacted"/>
...
select value="2" t="network" v="rcn"/>
if I want the network=rcn to be more important than bicycle=designated or
surface=compacted
I suppose that I have to set it to last line as in example, so last select wins. (or to first line) ?
char "<" removed, I was not able to display correct...
First one takes priority! So only 1 value will be calculated for 1 road. There are 2 values calculated for each road
SPEED * PRIORITY = SPEED_PRIORITY
DISTANCE / SPEED_PRIORITY = TIME
Algorithm always searches route with the shortest total TIME
Can you give a short help please:
if there are setting which are all valid at same time, which of them "wins" ?
example:
select value="1.8" t="bicycle" v="designated"/>
...
select value="1.1" t="surface" v="compacted"/>
...
select value="2" t="network" v="rcn"/>
[...]
I made a small plugin as example. Adjusting priorities for (cycle) routes was indeed enough to render a route in the cases I tested along only cycle networks when possible.
https://github.com/P-a-t-r-i-c-k/snap-to-route-osmand/releases/download/v0.1/snap-to-route.osf - plugin link to release