Route planer and estimated time problem

[neatwheat]

Hi,

it has been some time since I made a post on this issue, but there still seem to be problems with the route planers estimated time when adding shaping points. I attach some pictures from a scenario where it occured for better understanding. I've seen similar behaviour on many routes now.

As you can see in Picture1 (P1) the estimated time for the route is 2:08, when adding another point, the time only changes by 3min for almost 1,5km.
When measuring the section itself, it shows 25min.

In a variant of the route, the est. time is 2:23 when only using a start- and endpoint. When adding a shaping point, time decreases to 1:58min.

In this case I used GraphHopper and the hiking profile - when using BRouter the overall timeframe changes, but the problems appear to be the same.

On top of that, the "estimated travel time" which can be accessed under statistics, also isn't of great help because the profiles imo would need some tuning or be customisable.


Greetings

[poutnikl]

Possibly related:
@Menion I remember myself reporting for early beta version of the planner something similar for bicycle route planning, that you promptly fixed.

In that case the issue of obviously wrong time occured only for long enough route segment, with the total ETA time fixed with following, formal very short extra route segment.

I guess it had something to do with internal timing.


Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[Menion]

Hi guys,
thanks for this bug report. I think I've found the issue (removed first navigation waypoint for the second segment that had attached time to next waypoint).

Should be fixed in the next app version.

[lor74cas]

However, I think the ETA estimate is too optimistic, 1500 meters of positive difference in altitude in 2 hours, means 750 meters per hour. The estimate should be at least 3 hours, so there is a 1/3 excess. A mistake of this kind becomes dangerous on long journeys, especially in autumn with the hours of light that are decreasing. So be careful to plan with too much trust in the ETA, even the same planner should warn the user that the ETA is only an estimate and that travel times must be calculated based on their abilities, the type of terrain and weather conditions. This IMHO of a now old hiker.

[poutnikl]

AFAIK, this is hardcoded in Brouter, so modification has to be coordinated with Brouter author, as all 3 Brouter versions (external, online, internal) should provide consistent results. IMHO, personalized settings exposed to profiles, already available for bicycle and car profiles, should be implemented.

OTOH, relying on ETA calculations for mountain hiking is dangerous and quite a stretch. Common sense and consulting available hiking info is assumed. If a tool fails because it was used, where it should not be, it is not the fault of the tool.

Bicycle route  planning has advantage ETA calculation can be directly affected by Brouter routing profiles, mostly by tuning the effective mechanical power of "human engine" in the used kinematic model. I use for myself 85W and true total weight for long/loaded trips, which includes fatique and technical/recreational stops.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[neatwheat]

@menion that's awesome!

@lor74cas
Router/ETA in this case was GraphHopper which always estimates too optimistic - I normally only use BRouter which tends to be too "pesimistic" -  @poutnikl is right though, different Brouter "foot" profiles produce no difference in ETA.

I agree that the ETA is definitely a pretty subjective thing and nobody should solely rely on an app calculation for hiking - but I still consider it very important to get consistent results from the route planer as I use it for rough route comparison etc.

Since Locus seems to have its own "estimated travel time" (the one under RP "statistics"), it would be great imo, if there was an option to personalise these profiles and have these results shown in the bottom panel too, instead of the Routers ETA. But I guess that might be too much work for too little user demand.

[poutnikl]

I think the both Locus ETA systems ( routing service ETA for the planner + Locus usage profiles for track statistics)  should be unified.

It would be nice to have the routing and the custom settings as the 2 extra options in addition to Locus ones.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[Andrew Heard]

IMHO, personalized settings exposed to profiles, already available for bicycle and car profiles, should be implemented.

+1

From the Route Planner/ saved track, we have 15+ profiles for calculating ETA; all a compromise; none include a powered vehicle profile even though many powered vehicles are available as the routing service.

Then to add confusion (maybe just me) there are different set of 35+ track activities; many of which seem to serve the same purpose/ overlap with the profiles, but here there are 9 powered "transportation" options.

[lor74cas]

If a tool fails because it was used, where it should not be, it is not the fault of the tool.

If there is a profile for hiking and the ETA is calculated, this is a tool that any inexperienced person can consider suitable. Not everyone who uses Locus is experienced hikers, some of them may be tricked into trusting the ETA and risk getting into trouble. I hope it never happens, but if someone gets hurt or needs to ask for help because they based their hike on the Locus ETA estimate, without any warning in the app, who would legally answer?
I think a warning is needed in the app, to protect developers from possible legal action, but even more so to clarify that ETA is not an exact science, but a rough estimate.

[poutnikl]

I agree, as some unnamed inhabitants of the unnamed continent may use Locus this way and some 15 page disclaimer should be used, like what you should not do with a  microwave oven.

I personally insert short comments in similar spirit for some my challenging (on demand) profiles for MTB, that following routes given by that profile may cause heavy fatique, injury or even death of inexperienced users.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[lor74cas]

I agree, as some unnamed inhabitants of the unnamed continent may use Locus this way and some 15 page disclaimer should be used, like what you should not do with a  microwave oven.

I personally insert short comments in similar spirit for some my challenging (on demand) profiles for MTB, that following routes given by that profile may cause heavy fatique, injury or even death of inexperienced users.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

Don't use the microwave when hiking! 

[poutnikl]

I personally insert short comments in similar spirit for some my challenging (on demand) profiles for MTB, that following routes given by that profile may cause heavy fatique, injury or even death of inexperienced users.

One of such 2 profiles have been for some reasons originally included as the built-in  MTB profile of the Locus internal Brouter, until I strongly recommended to replace it.:-)



Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[Andrew Heard]

I think a warning is needed in the app, to protect developers from possible legal action, but even more so to clarify that ETA is not an exact science, but a rough estimate.

@lor74cas - if user has to enter their details for their own profile, then onus is back on the user for the ETA. Not fully because there is the algorithm behind the scenes, but still one more reason that user specified profiles are +1.

[neatwheat]

@Menion

I've tried out the new app version and it does seem that the time/shaping point problem is fixed when using GraphHopper -
unfortunately when using Brouter/LoRouter (I've tried LM Pro and LM 4) it seems that the issue is still there

[neatwheat]

I've tried out the new app version and it does seem that the time/shaping point problem is fixed when using GraphHopper -
unfortunately when using Brouter/LoRouter (I've tried LM Pro and LM 4) it seems that the issue is still there

Just wanna bring this attention again after some time now - the above mentioned problem (see examples) seems to be still present with LoRouter/Brouter