Routing over online/internal BRouter

[Radim V]

Please, block routing thru highway=construction in all profiles.

I see, will do also another lifecycle tags, thanks :-)

[0709]

@ Radim V
U- turn navigation instruction generation through Locus (B)Router missing command

Non-directional navigation instruction U-turn instruction delivered by the GraphHopper (-98) router has been nicely supported in most recent Kurviger.
After a non-directional U-turn you return over exactly the same out and return path and thus make a perfect 180 ° trackpoint turn.
In Kurviger you so do find the combination of a Shaping or Via Point together with the U-turn command sharing the same identical track point.

Notification Difference:
With a Shaping Point you only have a U-turn command message.
Example TTS: After 60m Return
With a Via Point you have a combined message: Via Point <name> followed by U-turn command.
Example TTS: After 60m Nice Viewpoint, Return.

Locus does not generate nor use, not even by using the online GraphHopper Router service.
And BRouter does not generate the non directional U-turns.
Question:
Is there a possibility in Locus LM4 with the internal Brouter to generate this as such and to use it?
In picture: See Icon difference. Non-directional U-turn is without arrow, directional U-turns with arrow.
On the left the Locus <sym> command, on the right the corresponding GraphHopper command.

[Radim V]

@ Radim V
U- turn navigation instruction generation through Locus (B)Router missing command

Non-directional navigation instruction U-turn instruction delivered by the GraphHopper (-98) router has been nicely supported in most recent Kurviger.
After a non-directional U-turn you return over exactly the same out and return path and thus make a perfect 180 ° trackpoint turn.
In Kurviger you so do find the combination of a Shaping or Via Point together with the U-turn command sharing the same identical track point.

Notification Difference:
With a Shaping Point you only have a U-turn command message.
Example TTS: After 60m Return
With a Via Point you have a combined message: Via Point <name> followed by U-turn command.
Example TTS: After 60m Nice Viewpoint, Return.

Locus does not generate nor use, not even by using the online GraphHopper Router service.
And BRouter does not generate directional U-turns.
Question:
Is there a possibility in Locus LM4 with the internal Brouter to generate this as such and to use it?
In picture: See Icon difference. Non-directional U-turn is without arrow, directional U-turns with arrow.
On the left the Locus <sym> command, on the right the corresponding GraphHopper command.

Hi, this is something to look into, but currently, there are much more pressing issues to cope with, sadly.   

[zossebart]

May I ask where the Lo* - profiles originate from? Clearly, they are not all from brouter default profiles? I assume some of them are based on poutniks profiles? Or did you create them all from scratch?

Do you plan to create issues and/or pullrequests in the corresponding source github repos for changes users suggest here? Or do you plan to maintain your own (proprietary) modified versions? Because if the former, other users could benefit as well from improved profiles.

And while you are at it: could you please reconsider (optionally) supporting ALL profile parameters instead of only your whitelist? I wrote this before: I think it's ok to use the whitelist as a default. But you could add a setting in expert settings to enable support for all parameters (for power users). I think it is ok to display the description texts from the profile instead of the translations Locus offers for the whitelisted parameters.
I recently enhanced my profile with yet another (non-whitelisted)parameter which significantly changes routing when altered. Without this parameter supported by Locus (unlike e.g. brouter-web), I'm forced to create even more variants of the profile with this parameter set to different values.

I hope you get my point.

regards,
zossebart

[Radim V]

@zossebard
The set o profiles we currently work with is and will be available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Some of them are default profiles from parent brouter repository and we rather want to keep them as they are validated by the previous usage in the app. Some of them are by Poutnik. We also consider your mtb profiles, of course. The modifications we made so far are rather minor. Feedback and improvement are welcome, just let us keep in mind that this set should be a safe set of defaults for all users. Regarding all profile parameters: I think we got your point, Menion will do that.   

[lor74cas]

Hi,
How can I set up the ETA in the planner?

The ETA on the map using planner is not the same on the stat of the panel.

[GMDD]

@zossebard
The set o profiles we currently work with is and will be available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Some of them are default profiles from parent brouter repository and we rather want to keep them as they are validated by the previous usage in the app. Some of them are by Poutnik. We also consider your mtb profiles, of course. The modifications we made so far are rather minor. Feedback and improvement are welcome, just let us keep in mind that this set should be a safe set of defaults for all users. Regarding all profile parameters: I think we got your point, Menion will do that.

At first glance, good profiles, at least they route over the ferry that many other profiles refuse.

[poutnikl]

Hi,
How can I set up the ETA in the planner?

The ETA on the map using planner is not the same on the stat of the panel.

AFAIK, ETAs on the planner are those reported by BRouter according to its internal algorithm, affected by BRouter profile configuration of the Brouter profile kinematic model ( cars or recent ones for bikes ). 

Stats in the panel are calculated by Locus from its builtin activiity profiles for horizontal/vertical speed, according to the route altitude profile and chosen activity, independently on BRouter.

IMHO, both have their place, but perhaps the user could choose either of them as the planner default.

Using a brouter profile for ETA has an advantage - when using an external profile - that one can tune the profile according to his physical conditions or intended effort. E.g. you can set the biker's steady mechanical power, tyre rolling resistance, aerodynamical drag or the total bike mass. It becomes handy for planning long distance trips/expeditions, where a bike is heavy and affordable mean sustained power is rather low.

Most of these parameters can be well estimated but the power. My advice here is to tune the estimated mean power up/down, until its prediction for the relevant scenario matches the reality. E.g. I use for myself for 4+ hours trips 85 Watts.

[lor74cas]

Hi,
How can I set up the ETA in the planner?

The ETA on the map using planner is not the same on the stat of the panel.

AFAIK, ETAs on the planner are those reported by BRouter according to its internal algorithm, affected by BRouter profile configuration of the Brouter profile kinematic model ( cars or recent ones for bikes ). 

Stats in the panel are calculated by Locus from its builtin activiity profiles for horizontal/vertical speed, according to the route altitude profile and chosen activity, independently on BRouter.

IMHO, both have their place, but perhaps the user could choose either of them as the planner default.

Using a brouter profile for ETA has an advantage - when using an external profile - that one can tune the profile according to his physical conditions or intended effort. E.g. you can set the biker's steady mechanical power, tyre rolling resistance, aerodynamical drag or the total bike mass. It becomes handy for planning long distance trips/expeditions, where a bike is heavy and affordable mean sustained power is rather low.

Most of these parameters can be well estimated but the power. My advice here is to tune the estimated mean power up/down, until its prediction for the relevant scenario matches the reality. E.g. I use for myself for 4+ hours trips 85 Watts.

Thanks for the answer, I thought the same too. By adjusting the brouter profiles I could get a more accurate estimate.
I generally do hiking, trail running and running activities.
I tried to understand where to act in the brouter profiles to get a custom version for my needs. But even looking at a lot of documentation on the net I did not understand where I can act for example to increase the basic speed.
In the profiles I saw I read "4 km per hour on the flat and 600 meters of altitude as a base". I should take them to 10.5 km and 800 meters how can I do?
To get an idea, I'll post a strava link of my recent activity https://www.strava.com/activities/4634408193 I don't know how true that can be, but I have a value of ~ 182 w Estimated Average Power.
Thank you for your time

[poutnikl]

I am afraid tweaking of foot profiles will not help in tweaking hiking/running ETA. ETA calculation for foot profiles is AFAIK hardcoded to BRouter, perhaps some variant of Naismith or Tobler formula.

You could experiment to pretend during running you are a bike, with some experimental tweaking of the to-be-for-bike parameters.

[zossebart]

@zossebard
The set o profiles we currently work with is and will be available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Some of them are default profiles from parent brouter repository and we rather want to keep them as they are validated by the previous usage in the app. Some of them are by Poutnik. We also consider your mtb profiles, of course. The modifications we made so far are rather minor. Feedback and improvement are welcome, just let us keep in mind that this set should be a safe set of defaults for all users. Regarding all profile parameters: I think we got your point, Menion will do that.

thanks for the information! nice to hear that you consider supporting more parameters. this way power users will e.g. also be able to tweak kinematic model parameters to optimize ETA (if supported by the profile).

Sent from my G8441 using Tapatalk

[poutnikl]

@zossebard
The set o profiles we currently work with is and will be available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Some of them are default profiles from parent brouter repository and we rather want to keep them as they are validated by the previous usage in the app. Some of them are by Poutnik. We also consider your mtb profiles, of course. The modifications we made so far are rather minor. Feedback and improvement are welcome, just let us keep in mind that this set should be a safe set of defaults for all users. Regarding all profile parameters: I think we got your point, Menion will do that.

Hmm, hmm.. Deriving LoMTB profile from my (to be experimental)Trekking-hilly-paths profile could be considered rather crazy. As I consider this my profile rather crazy myself, making it on demand of a "crazy" MTB user. It was not  really intended for wide use for possibly less experienced bikers. It would give good results for really hardcore up to crazy purposes, but far less than optimal ones for more reasonable or recreational ones.

I would rather call it LoMTBPlus or like that, and as LoMTB I would use MTB profile from Zossebart or my one.  All responsibility lays on the profile user and LocusMap developers. You have been warned. 

Edit: The similar is valid for Trekking-No-Flat profile, that is intended for the same purposes, but with a different approach.

[lor74cas]

I am afraid tweaking of foot profiles will not help in tweaking hiking/running ETA. ETA calculation for foot profiles is AFAIK hardcoded to BRouter, perhaps some variant of Naismith or Tobler formula.

You could experiment to pretend during running you are a bike, with some experimental tweaking of the to-be-for-bike parameters.

Yes, I had already experienced that as a human bike  the ETA was much closer to my time. Unfortunately, the bike in the downhill and flat sections on easy terrain has too much advantage over one that runs on foot, so the ETA becomes similar on hard terrain, but if there are asphalted sections or fast descents the difference grows again.
In general, the ETA is very subjective and combining it with profiles that were created for navigation without being able to insert a personalization makes little sense, in particular when the ETA provides an absolute time and not a range between minimum and maximum. Specifically, the ETA calculated by Locus also provides an estimate of rest times, which is even more subjective thus providing an arbitrary total ETA. It would be enough to warn the user that the ETA is calculated without the rest times.
How difficult is it to calculate the ETA?
A lot to judge from this study:
Analyzing Tobler’s Hiking Function and Naismith’s Rule Using Crowd-Sourced GPS Data

For both rules, 35% of tracks had predicted times within +/- 10% of the actual moving time.  70% were within +/- 25% of the actual time and 93% were within +/- 50%.

So I'm wondering if it makes sense to provide data that can be subject to such a high variation?
IMHO wrong information is worse than no data. The ETA at this point only makes sense for road routes by bike or car, it makes no sense on foot and on paths.
I would never want to know about a lost hiker in the woods (I saw Jungle yesterday and was influenced) based on the ETA provided by Locus. It is better for everyone to evaluate their abilities in accordance with the type of track and weather conditions without blindly relying on a data that we know may not be correct. I know it would all be part of natural selection as Darwin teaches, but it would still be a marketing damage 

[poutnikl]

So I'm wondering if it makes sense to provide data that can be subject to such a high variation? IMHO wrong information is worse than no data. The ETA at this point only makes sense for road routes by bike or car, it makes no sense on foot and on paths.

It makes still sense to provide ETA, if you provide also information, what you can and should expect and the range of applicability. Applying it in extreme circumstances and expecting standard behaviour would be rather an extreme than standard state of mind.

I remember it was also discussed, not sure if implemented, that the "nominal" ETA, calculated at route planning, would be in real time updated by comparison of partial values of nominal versus real time for the passed part of the route. (whole or last x km/minutes ).

E.g. a route has estimated ETA in 100 minutes. After passing the first half ( by expected spent time ), i.e. with the nominal  ETA 50 minutes, you realize you have spent 55 minutes, i.e. 5 minutes more. So for the rest nominal 50 minutes, you should expect rather 50*55/50=55 minutes  as well. Or, it could be evaluated for the last nominal 10 minutes, instead of the whole 50 minutes. So 50*11/10=55 min.

[lor74cas]

It makes still sense to provide ETA, if you provide also information, what you can and should expect and the range of applicability. Applying it in extreme circumstances and expecting standard behaviour would be rather an extreme than standard state of mind.

I agree.

I remember it was also discussed, not sure if implemented, that the "nominal" ETA, calculated at route planning, would be in real time updated by comparison of partial values of nominal versus real time for the passed part of the route. (whole or last x km/minutes ).

Yes, locus adapts the ETA based on the pace held in the previous period and the path still to be covered. But of course this is not the context of the planner.

E.g. a route has estimated ETA in 100 minutes. After passing the first half ( by expected spent time ), i.e. with the nominal  ETA 50 minutes, you realize you have spent 55 minutes, i.e. 5 minutes more. So for the rest nominal 50 minutes, you should expect rather 50*55/50=55 minutes  as well. Or, it could be evaluated for the last nominal 10 minutes, instead of the whole 50 minutes. So 50*11/10=55 min.

Not necessarily, you have to consider the type of path you have already taken and what remains to be done. If in the first 55 minutes you did the flat part, on easy terrain and then you still have 1000 meters of altitude difference left on a bumpy path? Not everyone is able to make this type of assessment, it takes experience and knowledge of their skills that are lacking in those who rely more on technological tools.
Furthermore, I have not seen the fatigue in the formulas that calculate the ETA. If on journeys within 3 hours it may not even be taken into consideration, beyond a certain threshold is instead decisive. If we take an example similar to yours, a 6-hour ride estimated by the ETA: if after 3 hours and 30 minutes I am halfway (with the same track between the first and the second part) it will not take a total of 7 hours, but maybe 8 due to performance degradation due to fatigue. In addition, the longer the routes are, the easier it is for the difference between real time and ETA to become large, also entailing the risk for those who are out to find themselves still far from their destination and with the sun setting down.