Cycle Travel Question

Cycle-touring, Expeditions, Adventures, Major cycle routes NOT LeJoG (see other special board)
SA_SA_SA
Posts: 2358
Joined: 31 Oct 2009, 1:46pm

Re: Cycle Travel Question

Post by SA_SA_SA »

Thanks for your reply...

Could the go direct feature be sort of hacked into manual routing by allowing it to be split into vias which can then be dragged, in combination with the disable recalculate autoroute button option you hinted at wishing to add earlier , to reduce work at server, recalculating same route parts)?

In the meantime I suppose one could generate a rough autoroute in cycletravel then export to gpx and load into a dumb plotter to finish.
 
Thanks for all the hard work, just a pity that a mixed auto/manual mode is probably too hard to belatedly add in. :D

Once again thanks for your work, I use cycletravel a lot. :)
------------You may not use this post in Cycle or other magazine ------ 8)
User avatar
andrew_s
Posts: 5795
Joined: 7 Jan 2007, 9:29pm
Location: Gloucestershire

Re: Cycle Travel Question

Post by andrew_s »

SA_SA_SA wrote: 13 Apr 2021, 3:00pmCould the go direct feature be sort of hacked into manual routing by allowing it to be split into vias which can then be dragged, in combination with the disable recalculate autoroute button option you hinted at wishing to add earlier , to reduce work at server, recalculating same route parts)?
The thing, as I understand it, is that if there's no auto routing, there's no route dragging.

If I want a 100% manual route, I set my start point, and then drag the end point along the route I want to follow.
Any time the displayed blue route jumps away from the roads I dragged the end point along, I move the end point back along my chosen route until the blue route hops back, and then add a via point just before the end point, and carry on dragging the end point along my planned route.
Recreating last night's ride to the pub :) (40 km), I set 6 via points - 3 to force the right roads out of town, and 3 to prevent shortcuts.

Image
A shows the end marker having been dragged along the correct route.
B shows it having been dragged a bit too far, with the displayed route having changed itself.
I move the end marker back to where it is in A, then add a via point at the arrowed location.

You would use direct routing when cycle.travel refuses to use a section of route, either because it's a footpath (no cycling!) or because there's some problem with the underlying OpenStreetMap data, such as a side road that doesn't actually connect to the main road.
Angstrom
Posts: 178
Joined: 21 Nov 2018, 6:57am
Location: Montpellier, France

Re: Cycle Travel Question

Post by Angstrom »

@Richard
A small bug: I asked CT to suggest a round trip to a point B from my departure point A.
I liked it a lot, but wanted to ride it in the reverse order (clokwise vs anti-clockwise as it was suggested). I chose the option to reverse order in the drop down and it actually did it, but departure was set at point B instead of point A as I wanted.
Oddly, it permuted departure and destination.
"A cycle tourist doesn't have a track record. Just memories". Jean Taboureau
richardfm
Posts: 963
Joined: 15 Apr 2018, 3:17pm
Location: Cardiff, Wales

Re: Cycle Travel Question

Post by richardfm »

Angstrom wrote: 15 Apr 2021, 8:53pm @Richard
A small bug: I asked CT to suggest a round trip to a point B from my departure point A.
I liked it a lot, but wanted to ride it in the reverse order (clokwise vs anti-clockwise as it was suggested). I chose the option to reverse order in the drop down and it actually did it, but departure was set at point B instead of point A as I wanted.
Oddly, it permuted departure and destination.
I could argue that is not a big, just a different interpretation of the expected behaviour.
Richard M
Cardiff
Angstrom
Posts: 178
Joined: 21 Nov 2018, 6:57am
Location: Montpellier, France

Re: Cycle Travel Question

Post by Angstrom »

richardfm wrote: 16 Apr 2021, 12:34pm
Angstrom wrote: 15 Apr 2021, 8:53pm @Richard
A small bug: I asked CT to suggest a round trip to a point B from my departure point A.
I liked it a lot, but wanted to ride it in the reverse order (clokwise vs anti-clockwise as it was suggested). I chose the option to reverse order in the drop down and it actually did it, but departure was set at point B instead of point A as I wanted.
Oddly, it permuted departure and destination.
I could argue that is not a big, just a different interpretation of the expected behaviour.
I can see that. It's a special case to have a start and arrival at same place.

I can't get "suggest ride" to work on mobile anyway (impossible to select one of the 2 proposed rides).
"A cycle tourist doesn't have a track record. Just memories". Jean Taboureau
ChrisF
Posts: 662
Joined: 22 Mar 2014, 7:34pm

Re: Cycle Travel Question

Post by ChrisF »

Elevation data accuracy. OK, I know this topic is fraught with problems but I'd like to share my recent experience with cycle.travel vs. Wahoo Elemnt Roam vs Strava. And I'm sure I've seen a recent post about this but can't find it now.
I've plotted (and riddden) about 10 rides in the last fortnight and each time cycle.travel 'underestimates' the climbing compared to what's recorded on my Roam (which uses a barometer). Usually the Roam shows about 50% more climbing than cycle.travel, but today it was very nearly 100% more (cycle.travel=1000 metres, Roam=1967m) over a 160km course. (btw I know that rides near to steep cliffs or through tunnels can really mess things up, but none of my recent rides have been like this - they're all rolling countryside or open hills).
The odd thing is that, for 3 of these rides, I've later plotted the exact same routes using Strava's routing algorithm and it's agreed with the Roam each time, to within 5%.
Of course, I've no way of knowing which is correct, maybe cycle.travel is accurate and the others aren't. But an extra 500m of climbing on a long day's ride can be quite tiring! If the error was a consistent percentage I could learn the difference and take it into account, but today's effort shows that it's not consistent, and all of the rides I mentioned have been long enough (>80 km) to get a representative data set.
Chris F, Cornwall
Richard Fairhurst
Posts: 2028
Joined: 2 Mar 2008, 4:57pm
Location: Charlbury, Oxfordshire

Re: Cycle Travel Question

Post by Richard Fairhurst »

It is consistent, it's just not consistent in the way you're expecting. ;) Different calculation methods affect different types of terrain, so the discrepancy will vary according to whether it's a very hilly route or a very flat route. More or less, cycle.travel currently makes a good fist of hills, but currently under-reads on flattish routes with small undulations - so, for example, I can find a typical five flattish miles round here where cycle.travel calculates 10m total and RWGPS calculates 60m, and the real total is somewhere between the two (working from spot heights on OS maps gives me 40m). I know what the issue is, I just haven't had the time to fix it yet.
cycle.travel - maps, journey-planner, route guides and city guides
Psamathe
Posts: 17617
Joined: 10 Jan 2014, 8:56pm

Re: Cycle Travel Question

Post by Psamathe »

ChrisF wrote: 26 Apr 2021, 8:38pm....
Of course, I've no way of knowing which is correct, maybe cycle.travel is accurate and the others aren't. But an extra 500m of climbing on a long day's ride can be quite tiring!....
Although ascent is normally given in meters, I regard it as nothing more than an index. So it yesterday I did 300 units of climb and was knackered and tomorrow is 600 units then it will be "tough" whereas 100 units would be easy. Just an index for comparing one ride against another with the constraint you always get the index from the same source.

I have little idea what an absolute 300 m climb over a 20 mile ride is actually like, only how easy/hard a similar ride has been in the past. (I don't bother comparing my rides with other people).

Ian
Bmblbzzz
Posts: 6249
Joined: 18 May 2012, 7:56pm
Location: From here to there.

Re: Cycle Travel Question

Post by Bmblbzzz »

Toughness of climb depends very much on distribution and gradient rather than just total amount, and different people will be affected differently by these. And of course the normal variables such as surface, weather, traffic... IMO at least!
Angstrom
Posts: 178
Joined: 21 Nov 2018, 6:57am
Location: Montpellier, France

Re: Cycle Travel Question

Post by Angstrom »

ChrisF wrote: 26 Apr 2021, 8:38pm Elevation data accuracy. OK, I know this topic is fraught with problems but I'd like to share my recent experience with cycle.travel vs. Wahoo Elemnt Roam vs Strava. And I'm sure I've seen a recent post about this but can't find it now.
I've plotted (and riddden) about 10 rides in the last fortnight and each time cycle.travel 'underestimates' the climbing compared to what's recorded on my Roam (which uses a barometer). Usually the Roam shows about 50% more climbing than cycle.travel, but today it was very nearly 100% more (cycle.travel=1000 metres, Roam=1967m) over a 160km course. (btw I know that rides near to steep cliffs or through tunnels can really mess things up, but none of my recent rides have been like this - they're all rolling countryside or open hills).
The odd thing is that, for 3 of these rides, I've later plotted the exact same routes using Strava's routing algorithm and it's agreed with the Roam each time, to within 5%.
Of course, I've no way of knowing which is correct, maybe cycle.travel is accurate and the others aren't. But an extra 500m of climbing on a long day's ride can be quite tiring! If the error was a consistent percentage I could learn the difference and take it into account, but today's effort shows that it's not consistent, and all of the rides I mentioned have been long enough (>80 km) to get a representative data set.
This has got to do with "thresholding", I think. In a nutshell: when does one start considering a slope a hill?
Devices with barometric sensors tend to count every uphill meter as an elevation gain. In theory, this can't be contested. The problem is twofold:
1) It is not consistent with a number obtained in a traditional way (with a map), without computers. Small ups and downs are not taken into account (too tedious if even possible). I believe getting the algorithm to match more or less what number would be obtained in a meticulous yet traditional manner is a good endeavour. Personally, that's my preferred approach even if it produces a lower number. I consider it to be more helpful
2) Devices using GPS triangulation to "guess" altitude produce "reading" errors in both ways (up and down), and this causes "virtual" elevation gains/losses". Thresholding and averaging are used to automatically remove those errors, but obviously can't sort out perfectly good readings from bad ones.

As a consequence, it isn't possible to have one's cake and eat it too. An algorithm applied to a file coming from a barometric device producing a "good" result won't output a good one from a file produced by a non barometric device.

My take on this is that either the CT elevation algorithm can automatically take into account the source of the file and apply the proper parameters or it should offer the user options to change settings or manually choose between a couple of preset settings.

In the mean time, I thing experience acquired by using different other tools that do exist (Strava being one; I use VisuGPX which lets me select thresholding, number of points for averaging etc.) in combination with CT is how I deal with this problem. I don't suggest this is best for everyone. Just my way to deal with it.
Of course, any improvement will be welcome.
"A cycle tourist doesn't have a track record. Just memories". Jean Taboureau
ChrisF
Posts: 662
Joined: 22 Mar 2014, 7:34pm

Re: Cycle Travel Question

Post by ChrisF »

Thanks for all the replies and suggestions.
Richard Fairhurst wrote: 26 Apr 2021, 9:32pm ..... More or less, cycle.travel currently makes a good fist of hills, but currently under-reads on flattish routes with small undulations -.......
Now I think about it, that equates with my experience. My long route yesterday ( https://cycle.travel/map/journey/215999) was less climbing per mile than others I've done recently. Also, I should mention, Richard, that I think it's the first one I've done where I have just asked cycle.travel to decide a longish route from A to B (in this case Kirkby Stephen to Carlisle) and then back using the 'round trip' method. I didn't change anything and the resulting ride was great - certainly good ways into and out of Carlisle :D
Chris F, Cornwall
Richard Fairhurst
Posts: 2028
Joined: 2 Mar 2008, 4:57pm
Location: Charlbury, Oxfordshire

Re: Cycle Travel Question

Post by Richard Fairhurst »

Right, I have poked the fiendishly complex climb calculation algorithm for the n (hundred)th time. It should be less likely to underestimate flattish routes now. You'll probably find it's still lower than other sites calculate, but I'm happy with that!
cycle.travel - maps, journey-planner, route guides and city guides
gloomyandy
Posts: 1140
Joined: 16 Mar 2012, 10:46pm

Re: Cycle Travel Question

Post by gloomyandy »

Hi Richard, I'm not sure if this has been mentioned before, but I only noticed I today. It seems that old routes (from the "my journeys" tab when opened in map view will have the route recalculated in some situations. In particular I clicked on the "mountain" symbol to get elevation about on old route I planned to ride again and the route changed to something rather different to the original. Although I can understand why this might happen (your computed routes changing), I'm not sure it is desirable.
User avatar
RickH
Posts: 5832
Joined: 5 Mar 2012, 6:39pm
Location: Horwich, Lancs.

Re: Cycle Travel Question

Post by RickH »

Richard Fairhurst wrote: 28 Apr 2021, 5:21pm Right, I have poked the fiendishly complex climb calculation algorithm for the n (hundred)th time. It should be less likely to underestimate flattish routes now. You'll probably find it's still lower than other sites calculate, but I'm happy with that!
We did a route - 25 miles pretty flat but with 1 substantial hill in the middle (CT plan, start/finish location changed to protect the innocent, & Strava log) - on Monday.

CT originally gave an ascent of 170m (& the course shipped into Garmin connect still lists 173m), Ascent recorded by my Garmin was 307m (1007ft). CT now gives total ascent as 260m. So a lot closer to recorded on a fairly flat route.

(Click to enlarge)
(Click to enlarge)
Former member of the Cult of the Polystyrene Head Carbuncle.
Richard Fairhurst
Posts: 2028
Joined: 2 Mar 2008, 4:57pm
Location: Charlbury, Oxfordshire

Re: Cycle Travel Question

Post by Richard Fairhurst »

RickH wrote: 30 Apr 2021, 1:23am CT originally gave an ascent of 170m (& the course shipped into Garmin connect still lists 173m), Ascent recorded by my Garmin was 307m (1007ft). CT now gives total ascent as 260m. So a lot closer to recorded on a fairly flat route.
That's good. Worth noting of course that even a Garmin with a barometric altimeter can suffer from fluctuations in the height readings. The other gotcha is that the digital elevation model used by cycle.travel (or pretty much any site) measures height on the ground, so humpback bridges and the like won't be picked up by its total climb.

Measuring c.t against contour-counting on an OS map, which is probably the most reliable method, c.t will still under-read slightly in some circumstances but it's generally in the same ballpark. RWGPS consistently overestimates elevation, sometimes by very large amounts (150% more in one example I tried), while brouter underestimates - I think due to not enough, and too little, smoothing respectively! Oddly, given how lousy their bike routing is otherwise, Google Maps' elevation calculations seem to be pretty good - I guess Silicon Valley engineers are good at crunching abstract datasets. ;)
gloomyandy wrote: 30 Apr 2021, 12:49am Hi Richard, I'm not sure if this has been mentioned before, but I only noticed I today. It seems that old routes (from the "my journeys" tab when opened in map view will have the route recalculated in some situations. In particular I clicked on the "mountain" symbol to get elevation about on old route I planned to ride again and the route changed to something rather different to the original. Although I can understand why this might happen (your computed routes changing), I'm not sure it is desirable.
Yep, that's a fairly inevitable artefact of the way the elevation calculation is done I'm afraid. If it's an issue then you can pin the route on its previous course by adding a via point in the section that diverges.
cycle.travel - maps, journey-planner, route guides and city guides
Post Reply