Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - neatwheat

Pages: [1]
Versions / Re: [APP] - version 3.46.+ ( 26. 5. 2020 )
« on: June 17, 2020, 16:58:09 »
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)

Versions / Re: [APP] - version 3.46.+ ( 26. 5. 2020 )
« on: June 01, 2020, 11:12:45 »
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 ...

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 ^^


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.

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

Troubles & Questions / Route planning estimated time problem?
« on: May 26, 2020, 12:42:04 »
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?


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.

Troubles & Questions / Re: Question on altitude optimization
« on: May 15, 2020, 16:30:58 »
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?)

Troubles & Questions / Re: Question on altitude optimization
« on: May 13, 2020, 16:24:03 »
(Note: To view gpx tracks I do not use services that calculate gpx altitude data from their own terrain model, so this should not be a source of error)

It is also possible if the altitudes are (partially) GPS based ( even if optimized ), the online service internally filters noisy data. If altitudes are SRTM based, there is nothing to filter, as it is smooth.

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

Hmm I now viewed it via two other well known osm Apps too and it's the same - I don't think they use a filter by default

Troubles & Questions / Re: Question on altitude optimization
« on: May 12, 2020, 12:25:36 »
Thanks for explaining! I only noticed it when using "optimize gps altitude", because the lowest and highest points had different values when viewing the gpx outside Locus. When using the "replace" option it is indeed quite fluent and seems to stay pretty much identical outside of Locus.
(Note: To view gpx tracks I do not use services that calculate gpx altitude data from their own terrain model, so this should not be a source of error)

But since I intend to mostly use the "replace" option it isnt really a problem for me anyway, so thanks for the help.

Troubles & Questions / Re: Question on altitude optimization
« on: May 11, 2020, 19:37:52 »
Thanks for your reply, I got me the Pro Version meanwhile and did some testing. It seems like that altitude optimization via smrt is done after saving the track, and optimized values are only visible inside Locus, so if I export the gpx it contains the standard gps altitude data, is that correct?

Troubles & Questions / Question on altitude optimization
« on: May 07, 2020, 10:05:49 »
Hi! I would like to ask some information on altitude tracking before I go ahead and buy the pro version -

1.I am particularly interested how the  option to "optimize gps altitude" via smrt will work? Is it smoothing the curve in post or calibrating the gps from time to time etc?

2. Can I import LIDAR data and will the above optimization then use this data instead?

thanks in advance!

Pages: [1]