Recent app feature highlighting full length of Routes fails on some.

Re recently introduced feature for i-Phone and Android:

(Using Android, latest version and latest CT; on Samsung Galaxy.)

I am finding the operation of this feature to be inconsistent. Selecting some Routes always results in highlighting as intended (eg Route 10); on some Routes, highlighting works intermittently ie whole route or none (eg (R72)); some never gets highlighted (eg R7) . Where the highlighting fails, the map has nevertheless detected that the tap was on the Route, as the pop-up that names the Route does appear, consistently.

The behaviour appears to be the same regardless of whether a self-created planned route (blue line) is being displayed or not.  Logging off and logging on makes no difference, nor does completely exiting CycleTravel and restarting (I have not tested whether having a simultaneous session on the website makes any difference.)

Note there is a message on the Cycling UK forum on 4th Oct from MrsHJ querying the operation of the highlighting, which appears to arise from similar experience.. 

HTH. 

Feature request: Adding Travel Tiles manually

(On Android app, automatic update to latest versions) I find that at times, I pass through a hexagon that is not recorded as a tile. I think this may correlate with times when the phone battery has been getting low, although the route tracking still seemed to be working. I know from other feedback that RF is looking at picking up tiles via GPX import, but would it perhaps be possible (simpler?) to add an option to add a hexagon manually? 

(I'm guessing the current option to delete an unwanted tile relies on the existence of the highlighted tile as a record, so it isn't possible extend that to include "add a tile" to that menu. But maybe it could become an option in the menu that is brought up by a via point?)   

(I am finding the travel tiles feature rather addictive...)

Sharing route with friends

(my typos corrected and bits of wording slightly cleaned up - SD 9/5) 

Unless I am being v dim, I don't think there are any instructions about sharing a route with friends; so a candidate for attention? (I learned of it thru the patreon newsletter or the cycling uk forum, can't remember which, or was it both; but was then a struggle...)

By trial and error, I found that the option in the app under "Save" to "Send to friends" worked fine so long as the route was set to be public. (Sending was from Andoid and receiving was to both Apple and Android).

So suggestions, in suggested order of priority:

- the error message when recipients entered the code was the the effect that "can't be done"; if the reason is the route is private, tweak the error message to advise "route can't shared as it is set to private; advise author to save as public" (and perhaps needs "then try again"?)

- enhance instructions in app and in website to explain the "Send to friends" process.

- add the "Share with friends" feature in the website version (obviously at present can be done simply by creating in website and saving , then opening in the app, then Save > send to friends; but more intuitive to be able to do it from the website too.

- given that the route being shared has a unique access code, it seems unintuitive for a route to need to be public. (eg use case: meeting at my house with friends to go on a circular ride together returning back to house, so one might prefer not to make that a public route.)

In gradient profile, a descent highlighted as if an ascent

(In website) In case you wish to pursue absolute perfection, feedback about wha tseems a slight glitch:

eg route from Coldcotes to Simonburn (Northumberland). At about 3 miles, the profile is correctly showing a descent but it is highlighted as if an ascent. I have not seen this previously, so seems a rare thing, just drawing to your attention in case you are not aware of this happening.

Note by using the spot heights shown for each ascent from the trough to the peak, the sum of the 11 ascents (some v slight!) came to 466 ft which aligns exactly with the total ascent shown on the profile (470ft); so clearly the incorrectly highlighted descent is not corrupting your  overall data, which would have mattered slightly more.

Incorrect total of elevation gain/loss

(Website and Android) The website estimated height gain/loss seems to have become materislly inflated compared to previous results, and with differing results to the Android app.

eg 

- See route name Durham - Bishopton circular saved as public just now. This used to show as a 1290ft ascent/descent, but now gives 1800ft. Google gives 1306 ascent, 1293 descent; ie v close to the previous result from CT. On the basis of the difference in height between the foot and top of each identiable ascent, as per the elevations indicated in CT, the ascent sums to 1158ft (with other minor oscillations not yet accounted for), which seems to support the previous CT estimate, and to be incompatible with the total currently given in CT website. (Planning the same route on the Android app give ascent 911ft, which does not aseem right either ... ).

- Stanhope (Co Durham) - Hexham railway station with a via point at Allenheads (excellent cafe!). Desktop app reports as total 2100ft ascent. However, planning the route in the Android app gives the total ascent as 1991ft. Noting the ascents in the website version of the route profile, in the same way as above, they sum to 1900ft. ie very compatible with the Android app result. (Puzzling, as I had assumed it was the same underlying engine...) Google gives just 1791ft ascent.

Is there perhaps something now going wrong in the totalling of the separate ascents in the latest version of your algorithm for the website??