I tried to plan a trip within Hungary to go from Balatonaliga (train station stop) to Révfülöp along the northern side of lake Balaton. These are both towns along the EuroVelo 14 "Waters of Central Europe" route.
1. However the default 'Any' setting wants to take me along the southern side of the lake and then take a ferry over to the north side. There should be an option to "avoid ferries" -- as they have in car navigation software.
2. The "Routes" option, limited to cycle paths looks better, and closer to the path I want to take, but surprisingly in the middle near Tihany, it takes a loop on the Tihany peninsula --incurring a 110m to 165m climb-- that is really not necessary and could be bypassed by staying on the road.
3. When using he 'Paved' option to plan the route. It still want to take me across the lake on a ferry, where I do not believe there to be paved roads.
I kindly ask you to consider putting in an 'Avoid Ferries' option. Also I am very curious as to why the 'Routes' option has chosen to plan the navigation on a massive hillclimb. Allow me to also propose a "family touring" option for your navigation algorithms, which always try to pick the safest routes in cities (along protected cycle lanes) and also tries to minimize the uphill climbs for kids.
Comments
Thanks for the detailed examples!
The ‘Routes’ option follows signposted cycle routes – i.e. not just cycle paths, but anything that is a EuroVelo route, national cycle route or otherwise.
In this example, OpenStreetMap (cycle.travel’s source data) appeared to have an error where the section of cycle path missing out the hill had been erroneously marked as “not in a waymarked cycle route”. I’ve fixed this in OSM and it’ll be reflected in cycle.travel’s next routing update.
Unfortunately the way that cycle.travel’s routing works doesn’t allow for custom options except at great expense (see the FAQ). I’ll give some thought into whether the ferry weightings should be adjusted, but you can of course always drag the route to take it away from the ferries.
Many thanks Richard for your response and fixing the relevant OSM sections.