Messages

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

@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

@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.

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

[@neatwheat]

@neatwheat
the difference in times is currently most probably caused by the difference of track segment: in case, the segment is computed by the router, the time comes from this router, otherwise, time is estimated by the app based on few internal variables. I can't improve this now, but it is definitely something that needs to be "fixed" as soon as possible.

Thanks for the info. If I may push an additional idea for that topic:
an option to have the route's  travel time (movement) be shown in bottom panel, regardless of which routing service is chosen would be awesome (and could maybe even serve as a workaround for the shaping point problem)

[@slarti76]

@slarti76
Incorrect time in the "Trip time" screen happens also with the latest beta? Because I made some changes there.

I wanted to send the track, but in 3.46.1 trip times for this track look reasonable. Whatever you did, it worked Thx!

Can confirm problems with travel time seem to be gone with new version.

Problem still remains:
Route planner seems to have problems to calculate correct time when adding shaping points - Same routes will have much different times in bottom panel when adding points.

Also toogling Include navigation hints on and off seems to change the time too.

If experimenting with the template and if a little familiar with Linux, you may find the use for the sedbatch bash script in Brouter-profiles, that can be run in Android termux Linux console, generating profiles directly from the local or GitHub template. You may want to taylor it for your own modifications.

Thanks a lot, but I fear the script might be too much for my small skillset ...

*Update
Toogling "Include navigation hints" on or off also changes the ETA from RP bottom panel massively

It is getting aged and definitely may deserve some updating ( rather the hiking profile template in the other repository ).

Thanks for the hint, I'll try the template too!

AFAIK, BRouter use some internet formula for slope aware hiking speed, and a constant power bicycle kinematic model for bicycle ETA ( in recent built-in profiles, not yet in my profiles ).

I have realized 85W constant power provide ( for my total mass and travelling habits/performance) quite good  long time average effective travel speed.

I'll keep that in mind for the next bike trip!
In terms of hiking the BRouter Internet formula unfortunately seems to not be very sophisticated. I often tried calculators based on the Naismith Rule for trips in the past and it seemed to produce a better "rough" ETA.

Thanks for clarification! Then it definitely seems that Locus sometimes has problems taking the correct values from Brouter - on the same route Locus sometimes adds time when adding a second waypoint and sometimes it doesnt.

Btw I'm also trying out your SAC6 profile from Github - is that still recommended or obsolete?

Edit: Sorry didnt see your Edits before answering ^^

*Update

1. The completely wrong estimated time in the routeplanner bottom panel (e.g. 16min for a 1700m altitude ascent) seems to be fixed after a preference reset in Locus.
It still shows weird values in some situations or sometimes after adding a second point, but I guess it's like that for everybody atm.

@poutnikl
It seems to me that the est. time in rp bottom panel comes from the chosen routing service (Brouter, Graphhopper) and the values in "travel time" from Locus? Because travel time seems to always stay the same.

hmm yeah that might be related, seems like something is off here.

I tried the route inside Locus with BRouter and GraphHopper, and there seems to be no change to the values. Route-planner bottom panel time is always massively wrong and travel time has at least a realistic value for ascent - but same route as descent always shows only 1min for whole trip down.

Edit: I just tested it on PC in my Emulator, and the wrong values on the Route planner bottom panel seem to be okay there, so a setting on my phone seems to break it. The broken time for the descent shown in travel time still exists there.

Edit 2: also noticed that after setting a shaping point in certain areas, the summation of the additional time seems to become incorrect on RP bottom panel time

I've got some strange problems with the route planner:

1. the estimated time shown on bottom bar shows somehow wrong values. For example: for a 6km mountain-hike with 1700m elevation it estimates 16 min, when I go to "travel time" it estimates 4:50h. (Planning profile is set to hiking).

2. On the other hand when I plan the same route from the peak downwards, it's the same, but now "travel time" also doesnt work correctly it estimates 1 min for the whole trip down.

Am i doin something wrong?

@freischneider

Das war etwas unklar formuliert von mir, es geht bei 1. und 2. um dieselbe Route. Der Weg ist ok und wird von den Locus BRouter Profilen "Wandern" bzw. "Gehen" auch beim Routing miteinbezogen, die steigen aber höher oben bei den schwierigen Wegen aus (wohl weil über SAC4).

Hab jetzt allerdings die BRouter Locus Profile mal abgeschalten und auf Profil "Gehen" gesetzt, was soweit ich das verstehe bedeutet dass das Profil direkt vom BRouter übernommen wird? Da scheint diese Route jetzt vollständig und mit den logischen Wegen berechnet zu werden.

Hi! Hätte eine kurze Frage als neuer BRouter Benutzer

Einsatzgebiet der Routenplanung ist Wandern, auch Hochgebirge mit höheren Schwierigkeitsgraden, als Kartenquelle nutze ich OpenAndroMaps. Wenn ich jetzt die Locus Profile benutze, habe ich das Problem dass

1. bei den Zu-Fuss Profilen "Hiking-Alpine-SAC4" auf schwierigeren Routen das Routing verweigert, Schwierigigkeit SAC4 ist anscheinend ja die Grenze, Zu-Fuß Profile mit höheren Graden seh ich nicht.

2. die Trekking Profile beziehen zwar die schwierigeren Routen mit ein, aber da ja eigentlich fürs Fahrad gedacht (?) wird dann in gewissen Bereichen z.B. eine längere Forststraße dem kürzeren Wanderweg vorgezogen, was auch nicht praktikabel ist.

Mach ich da was falsch oder ist es einfach notwendig BRouter in diesem Fall ohne die Lokusprofile zu benutzen? Danke im Vorraus.

@menion 
One more question if you don't mind - does the "fill elevation" option completely replace altitude data of a track with smrt data? (So it would be basically be the same result as if you choose "replace gps values" before recording?)