Another big separate topic in Locus Map 4 we work on, is the routing system.
Implemented since: Locus Map 3.50.0.1 (file: MapGooglePlay_3.50.0.1_981_beta.apk)
After a long discussion, the app now fully integrates BRouter based solution.
Online routing service
- in the app sources available as BRouter Online
Offline routing service
- in the app sources available as BRouter (inner)
Both services use identical routing profiles, so you should get identical results. Internal solutions offer few parameters in every profile. Should be anyway little slower, mainly on low-powered devices.
What do we want to do for now? Fine-tune current existing quite "general" profiles before we step forward in creating more
Responsibility in our team: big routing fan Radim (@Radim V)
,,the app now fully integrates BRouter based solution"
I can't see an option to calculate alternative routes. I'm not going to use it without it. I don't remember how I've set BRouter in the Locus Pro, so I haven't tried it in the beta.
,,Both services use identical routing profiles, so you should get identical results."
I have 2 local BRouters 1 with map icon and second called inner. Both with different profiles, but without mine.
Inner and online have a different number of profiles
I've got timeout code 10102 when downloading routing segments for BRouter inner.
,,What do we want to do for now?"
Autorenaming profile according to the profile file name.
GUI to import custom profiles.
Too many taps to recalculate a route with a different profile, two confirmations are at least one too many.
In profile pop up a cogwheel next to ,,Settings" isn't obvious they are separated things. Put | at least.
Hi everyone,
generally if I have to plan some trips I usually do it with the PC which is certainly more comfortable than doing it on the small screen of the mobile phone. I do planning on my mobile only when I don't want to get up from the sofa and turn on the pc (sometimes I'm too lazy) or when I'm outdoors and I want to get an idea before taking a detour or lengthening the route I had planned previously. The online brouting service makes little sense to me also because often if I'm outdoors I don't have cellular network coverage. I think there are too many options in Locus that compromise its ease of use and scare the average user, it seems to become more and more an application for geeks / nerds (obviously I belong to the category). In my opinion, but it is only my opinion, we should cut, simplify and make what remains more reliable and in this specific case I would not activate the online brouting service, I would only leave the "inner" version with a specific function to notify the user to update the brouter database.
Sorry, but I don't agree with @lor74cas. I choose Locus exactly because of its extra functionality, otherwise what would distinguish it from the many many other GPS apps out there. The default LM4beta on/offline routing for me works well "out of the box", and the additional/ advanced settings are quite well "tucked away" from the "average" user. Just my 2 cents worth. I do generally use a PC for route planning too, but I don't think that would be any different for any Android GPS app, powerful or simplistic.
I understand what lor74cas is saying. The worst thing that can happen to me is when a complete stranger asks me, what nice cards do you have on your phone, what website is that? No ma'am or sir it's an app called Locus. And then the difficult question, is it easy to operate? Then I get very quiet and this geek knows how difficult it is to escape this quickly ;-) Regarding online routing or offline, I don't think this is an extra difficulty, just not that.
Quote from: 0709 on January 10, 2021, 11:47:37
I understand what lor74cas is saying. The worst thing that can happen to me is when a complete stranger asks me, what nice cards do you have on your phone, what website is that? No ma'am or sir it's an app called Locus. And then the difficult question, is it easy to operate? Then I get very quiet and this geek knows how difficult it is to escape this quickly ;-) Regarding online routing or offline, I don't think this is an extra difficulty, just not that.
This is what always happens to me out of 10 people I show locus maybe 1 or 2 don't get discouraged by too many options. For me, the coexistence of brouter's "inner" and "online" service is not a problem, but it was just one example of the many things that could be simplified. And if I had to choose I would prefer the "inner" service. Locus in fact is one of the few apps that guarantees operation even offline and is one of the reasons why I chose it.
A lot has improved with LM4. I think it's very easy to use now. But I'll test that with my brother-in-law. Normally, things like that are not easy for him.
I don't know of any app that is easier than LM4. Since then it has been complicated to navigate as you needed the Brouter App. But now it's very easy. Locus even notices when offline segments are missing.
A big advantage is that there are operating instructions in 3 languages (maybe more will follow). So far, this is very understandable.
If there is already one for LM4, I can take the test with my brother-in-law.
I'll leave main comments here to my colleague Radim, but just my "two cents":
- offline routing in the app is used only in the app, but
- online routing, that uses exactly the same default profiles, will be used in the web planner as well!!
So we see testing and finding optimal routing parameters for various types (car, Mtb, gravel bike, etc) as extremely important, and generally, it is not about online/offline. It is about "how to make calculated routes better"!
My main reason for this topic was to find some clearly visible problems in routing, like "hey, car profile route in this one-way route" or "this bike profile ignore cycle route even it is obviously better" etc.
Thanks ;)
Example MTB:
Personally, I would like to go uphill on easy trails (no steep incline, max. S1) or gravel paths up to max. grade 3.
Downhill trails up to a maximum of S3. S2 would be optimal. I don't want stairs up a mountain. But downhill it can be short stairs.
Now it is so that everyone wants something different. Maybe you can edit some parameters in the profile.
You can anticipate in LM4 that Locus support staff are going to get tied up with endless questions & requests about customizing routing profiles for every personal preference. It will be a fine balance between enough user settings/ range of profiles & "keeping it simple".
Quote from: PawelS on January 09, 2021, 16:12:05
,,the app now fully integrates BRouter based solution"
I can't see an option to calculate alternative routes. I'm not going to use it without it. I don't remember how I've set BRouter in the Locus Pro, so I haven't tried it in the beta.
,,Both services use identical routing profiles, so you should get identical results."
I have 2 local BRouters 1 with map icon and second called inner. Both with different profiles, but without mine.
Inner and online have a different number of profiles
I've got timeout code 10102 when downloading routing segments for BRouter inner.
,,What do we want to do for now?"
Autorenaming profile according to the profile file name.
GUI to import custom profiles.
Too many taps to recalculate a route with a different profile, two confirmations are at least one too many.
In profile pop up a cogwheel next to ,,Settings" isn't obvious they are separated things. Put | at least.
Hi Pawel, thank you for your feedback. First of all we would like to sort the timeout problem. Does it happen always, even when connected to a reasonably fast network?
Where routes profile "river"?
Quote from: starka on January 11, 2021, 18:09:28
Where routes profile "river"?
As the names gives the hint, it routes along OSM mapped waterways. But it is rather experimental and cannot be used for serious navigation in sense of desired navigation line.
Sent from my Xiaomi MI A2 / Android 10, via Tapatalk
When I show Locus to others I focus on what is important to them or me.
Radim, timeout error happened all two times I tried the beta, so maybe 7 tries of downloading, even when connected to a reasonably fast network. Download bar grows quite fast and sometimes stops before ending.
A few days ago I had also timeout errors in Pro with code 12569 downloading a theme from Locus Store and OpenAndroMap like in https://help.locusmap.eu/topic/22122-fail-to-download-map-of-norway-from-openandromaps-org So far I haven't tried reinstallation because I don't want to risk to botch using a backup copy. Previous downloads form the Locus Store was successfull and the map is dated on 05.2020
Please, block routing thru highway=construction in all profiles.
Quote from: Erelen on January 12, 2021, 09:45:08
Please, block routing thru highway=construction in all profiles.
I see, will do also another lifecycle tags, thanks :-)
@ Radim V
U- turn navigation instruction generation through Locus (B)Router missing command.
Quote from: 0709 on January 14, 2021, 11:26:31
@ 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.
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
@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.
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.
Quote from: Radim V on January 19, 2021, 10:53:13
@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.
Quote from: lor74cas on January 19, 2021, 12:03:38
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.
Quote from: poutnikl on January 19, 2021, 13:18:30
Quote from: lor74cas on January 19, 2021, 12:03:38
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
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 (https://en.wikipedia.org/wiki/Naismith%27s_rule) or Tobler (https://en.wikipedia.org/wiki/Tobler%27s_hiking_function) formula.
You could experiment to pretend during running you are a bike, with some experimental tweaking of the to-be-for-bike parameters.
Quote from: Radim V on January 19, 2021, 10:53:13
@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
Quote from: Radim V on January 19, 2021, 10:53:13
@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 (https://raw.githubusercontent.com/poutnikl/Brouter-profiles/master/BikeProfiles/Trekking-hilly-paths.brf) 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 (https://raw.githubusercontent.com/poutnikl/Brouter-profiles/master/BikeProfiles/Trekking-No-Flat.brf) profile, that is intended for the same purposes, but with a different approach.
Quote from: poutnikl on January 19, 2021, 19:38:28
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 (https://en.wikipedia.org/wiki/Naismith%27s_rule) or Tobler (https://en.wikipedia.org/wiki/Tobler%27s_hiking_function) 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 ;D 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 (https://gis.e-education.psu.edu/sites/default/files/capstone/Irtenkauf_596B_20140430.docx)
QuoteFor 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 (https://www.imdb.com/title/tt3758172/) 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 ;)
Quote from: lor74cas on January 20, 2021, 10:32:10
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.
Quote from: poutnikl on January 20, 2021, 11:52:28
QuoteIt 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.
QuoteI 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.
QuoteE.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.
All the above implies the routing is able to assess the route about correctly, based on available OSM data. E.g. and just illustratively, it takes 3 min/km for one part on an easy road and 20 min/km for other part on a steep woody trail.
I repeat my comment about the extremalities. You do not really expect the planner would consider the muddiness, unless there is tag surface=mud. If you do not evaluate in advance yourself the ETA in extreme conditions would not match, is it yours fault when they do not match and you are surprised.
You would also use different profile configuration for short sportive rides and long trips or expeditions.
Thinking is required. ETA calculation is not magic, it is simple calculation, that can be easily fooled. If one does not count with it, it is his fault.
Hello, I have a problem with routing that is apparently present in all the latest versions of LM4.
When using Brouter inner (in both Route Planner and Navigate To) with the car-specific profiles (Fast and Economy), directions are not created and this error appears:
Cannot create path-model:java.lang.IllegalAccessException: void btools.router.KinematicModel.<init>() is not accessible from java.lang.Class<o.tl>
I tried to look it up and I possibly found the beginning of the error in https://github.com/abrensch/brouter/blob/b4dd0edd44439a44178d36e7f13643167f24aa1a/brouter-core/src/main/java/btools/router/RoutingContext.java#L97 (https://github.com/abrensch/brouter/blob/b4dd0edd44439a44178d36e7f13643167f24aa1a/brouter-core/src/main/java/btools/router/RoutingContext.java#L97) but I don't know Java, so...
I'm using LM4 on Android 11 in parallel with LM3 Pro, I already tried removing and reinstalling LM4
@zossebart
Radim promised that we will add "all" custom profile parameters ... well, I still prefer adding only validated and confirmed parameters. But for a long time, I did not receive any request. Do you miss any?
Dynamic parameters generated from brf files like brouter.de web planner do? I hope, this won't be necessary to be true.
@413Michele
thank you very much for this bug report. I've finally found the reason of this issue a few days ago, so it will be solved in the next Beta version! Btw. good detective skills :)
Yes, my request is to do it like brouter-web and dynamically parse and display all parameters from brf file.
I don't have a specific request for confirmed parameters, despite maybe the kinematic model parameters (totalMass, Maxspeed etc.), which are brouter-builtin.
All other parameters I would like to use mostly exist in single profiles only and therefor I wouldn't recommend adding them as supported to Locus just because of this one profile.
For example, I created an enduro-motorcycle profile on user-request which has a "non-standard" parameter to switch the avoidance of paths, or I consider adding another parameter to influence uphill routing on paths to my mtb profile etc...). Without support for generic parameters, I would have to generate separate profiles of all permutations of profile parameters like libor does, but it gets confusing and it's not easily switcheable for example in a routeplanner session (if the profile-variants aren't already assigned to the (limited) slots in Locus).
As I wrote before, I think it's ok that the default setting only shows the whitelisted parameters (as is now).
But I would like to have the possibility to enable "full dynamic parameter" mode in expert settings for power-users (which you clearly embrace with locus (intens, url favourites, bt-buttons, dashboards, quick pois, presets...should I go on with the list? ;) )).
Maybe you could group the whitelisted parameters at the top of the settings dialog and show the other "non-standard" parameters below. Maybe with a caption "additional settings" and in a fainter color?
Quote from: zossebart on January 27, 2021, 14:00:38
I don't have a specific request for confirmed parameters, despite maybe the kinematic model parameters (totalMass, Maxspeed etc.), which are brouter-builtin.
These kinematic model parameters are by their nature personal parameters, supposed to be taylored by end users. They e.g. help to predict the personally taylored ETA, depending on activity and personal fitness.
It can be done either by interactive way in configuration dialogs, either manually by local edit of profiles. I would rather vote for the former, especially if - like for online BRouter - local profiles are not used.
Quote from: zossebart on January 27, 2021, 14:00:38
Yes, my request is to do it like brouter-web and dynamically parse and display all parameters from brf file.
I don't have a specific request for confirmed parameters, despite maybe the kinematic model parameters (totalMass, Maxspeed etc.), which are brouter-builtin.
All other parameters I would like to use mostly exist in single profiles only and therefor I wouldn't recommend adding them as supported to Locus just because of this one profile.
For example, I created an enduro-motorcycle profile on user-request which has a "non-standard" parameter to switch the avoidance of paths, or I consider adding another parameter to influence uphill routing on paths to my mtb profile etc...). Without support for generic parameters, I would have to generate separate profiles of all permutations of profile parameters like libor does, but it gets confusing and it's not easily switcheable for example in a routeplanner session (if the profile-variants aren't already assigned to the (limited) slots in Locus).
As I wrote before, I think it's ok that the default setting only shows the whitelisted parameters (as is now).
But I would like to have the possibility to enable "full dynamic parameter" mode in expert settings for power-users (which you clearly embrace with locus (intens, url favourites, bt-buttons, dashboards, quick pois, presets...should I go on with the list? ;) )).
Maybe you could group the whitelisted parameters at the top of the settings dialog and show the other "non-standard" parameters below. Maybe with a caption "additional settings" and in a fainter color?
Your Enduro motorcycle profile.
Being as none of the profiles really cater to any kind of off road or unpaved roads for motorcycle that sounds exciting. I'm not very tech savvy so I'm still " navigating " my way through the program and trying to talor it to meet my needs for on road / off road motorcycle riding.
I don't want to end up on MTB trails that are not for motor vehicle use.
Sent from my E6910 using Tapatalk
Hi all,
we have updated the set of routing profiles available here:
https://github.com/asamm/brouter/tree/asamm/locus-routing-profiles
Profiles are of course credited inside.
Now we want to ask for some feedback again: More specifically, In landscape (both flat and mountains) you are familiar with:
-Is the MTB profile in your opinion: Too easy, too hard, or just about right and safe for an average biker?
-There will be not much distinction between walking and hiking in flat landscape but there should be some distinction in well mapped mountain areas. Do the results suit their activities?
-road cycling: roads too busy?
-any reason you would not use a particular profile for intended activity?
You can try them here:
https://web.locusmap.app/en/
And of course using brouter-web directly.
Thanks!
Can the internal profiles be accessed from file system side? Didn't find them. Just curious.
Quote from: tapio on March 03, 2021, 09:59:49
Can the internal profiles be accessed from file system side? Didn't find them. Just curious.
No, internal profiles are hidden from user. Anyway we keep them in sync with above mentioned public repository. You can modify those publicly available profiles to your liking and place them in Locus/router/profiles2. Then in advanced settings the app recognizes them.
I think it would be good if the LoProfile modification has been explicitly listed in the profile comments.
It will help with eventual coordinated development of the profile/template, not to be just a one-time action. E.g. I can include generation of explicit Loxxxx profile into my profile generation script (https://raw.githubusercontent.com/poutnikl/Brouter-profiles/master/sedbatch), that creates on demand all profiles from the current template.
This is not limited to my profiles, as the script can take and modify any profile posted on GitHub.
Or, you can create a modified script version to generate LoProfiles from the current versions of the sources, unless you do not have it already.
Quote from: poutnikl on March 03, 2021, 12:19:53
I think it would be good if the LoProfile modification has been explicitly listed in the profile comments.
It will help with eventual coordinated development of the profile/template, not to be just a one-time action. E.g. I can include generation of explicit Loxxxx profile into my profile generation script (https://raw.githubusercontent.com/poutnikl/Brouter-profiles/master/sedbatch), that creates on demand all profiles from the current template.
This is not limited to my profiles, as the script can take and modify any profile posted on GitHub.
Or, you can create a modified script version to generate LoProfiles from the current versions of the sources, unless you do not have it already.
Modifications: I will keep manual comments at the bottom of the files, that is an easy think to do, but we also encourage the usage of Git.(Tools like gitk do much better job in history bookkeeping than manual comments). Also changes via pull requests are encouraged. Currently all profiles include some minor changes (lifecycle tags awareness, turning instructions mode...), some of them are "hidden behind" the initial commit, sadly.
Generating profile variants from a template: Thanks, I wasn't aware of this script really. However we don't need to generate multiple files implementing ranges like "very easy - easy - medium - hard - very hard". What is going to happen more likely is: a single parameter ("difficulty level"), modifies a single profile (a temp. copy) in the time of request - some form of "request interceptor" inside brouter servlets. Multiple switch statements in this single profile can be seen as "difficulty presets", depending on a single variable, modified runtime. However your tool may be useful while generating those "presets". Hope this makes sense.
Hmm, I use git, gitk and git gui, on Window and Linux. And git also on Android/termux, manually or within the profile generation script. But gitk is IMHO much better in the job of reviewing history of file versions within the same repository. Keeping track on changes and current code of locus versus original profile is less handy and in git context knowledge challenging, in my case at least.
The script was not meant in LoProfile context to be used for many variants. Rather as eventual handy script-based alternative to "git rebase", which advanced usage is still a nightmare for me. So I am unsure about optimal approach. For now, I feel I may will leave it on you, in case you will want some occational profile refresh.
P.S.: It may be better if LoProfiles based on my profiles were based directly on profile templates and not on final profiles, as any development is done there . See the respective template master and develop branches.
Bicycle profile repository (https://github.com/poutnikl/Trekking-Poutnik/) and template (https://github.com/poutnikl/Trekking-Poutnik/blob/master/Trekking-Poutnik.brf) // Hiking profile repository (https://github.com/poutnikl/Hiking-Poutnik/) and template (https://github.com/poutnikl/Hiking-Poutnik/blob/master/Hiking.brf)
So ,,fully integrated BRouter based solution" doesn't have alternative routes. Do you have any plans for this?
Hi,
I got the "Gold Abo" and did some tests with the new Routing System.
cool stuff, but.....
so here's my list of issues where I think it's not yet golden but a little rusty:
- I had a hard time to initially set-up Locus to use the external SD card. Found the panel to switch standard directories. "router" missing in the list of detail directories. Switching the global Locus directory to the SD-card worked. But afterwards my first attempts to download routing data files failed with only a generic error message ("operation not successfull"). Very annoying. After copying an initial rd5-file to the {ext-Sd}.../router/segments4 directory subsuquent downloads were successful. No idea...
-
- "fast recalculations" do not work. With more then 50km routed distance ahead, automatic recalculations are just not usable.
-
- There's no way to stop a (long-)running route calculations. Don't know if there's a timeout. But with the routing library integrated my expectation was that there's an explicit "stop current route calcilation" funtionality, for the navigation mode as well as for the route-planner. Currently, the only way to stop a long-running operation is to restart Locus Maps
-
- The online LoRouter does not recognize nogo-areas. Excpectation is that online/offline behave similar. At least for the functionality that is offered to the user, like nogo-areas. For profile modifiers ("is-wet", ..) they are not offererd in online mode, which is good, but gold-standard would be to have them working in online-mode as well.
-
- I'm not completely sure if the current heading is considered in recalculations. I did some tests but did not found positive proof that it is. Expectation is that it works in favor of going straight ahaed and using the next junction, instaed if doing a u-turn
Don't get that wrong. Great work overall and I would like to switch to the integrated offline-router for my personal use. But missing "fast-recalcluations" is a showstopper for me. I would be happy to help get that working.
regards, Arndt
In choosing routing profiles there are options to " avoid unpaved roads ".
Is there a particular profile that would be best used if you " prefer unpaved roads " ?
Thanks
Sent from my E6910 using Tapatalk
Hello Arndt
appreciate your feedback!!
1. external card is not (yet) supported. I'm slowly preparing on hard times with coming Android 11 changes (09/2021). So it is possible that it simply won't be possible at all. We will see later...
2. Fast recalculations: hmm, here I will probably need some help. Probably some missing parameter in the 'RoutingContext' that allows re-using previous partial results?
3. bottom-left icon where you choose routing type should be working as "progress" indicator and also "cancel" button when some routing computes is in progress. 'MaxRunningTime'is currently set to 10 minutes, hmm ???
4. Online ignore No-go. Another task for @Radim V, thanks. Extra parameters are planned. We have to extend the server system because the app does not send the whole routing config to the server like BRouter.de probably do, so we have to invent a mechanism how to pass a set of parameters to the routing server.
5. 'startDirection' value should be set, but I'll rather check it.
@SonnyS
as I wrote in 4. to Arndt. Best profile for "unpaved" is again question mainly to @Radim V
Quote from: Menion on April 22, 2021, 14:42:46
2. Fast recalculations: hmm, here I will probably need some help. Probably some missing parameter in the 'RoutingContext' that allows re-using previous partial results?
Nearly.
checking the "nearbyTrack" is done inside the core code and is activated by setting a (full) filename to it's binary data:
RoutingContext.rawTrackPath
but writing the "nearbyTrack" is done outside the core code so you are probably missing that (see BRouterWorker.java):
if ( cr.getFoundRawTrack() != null )
{
try
{
cr.getFoundRawTrack().writeBinary( rawTrackPath );
}
catch( Exception e ) {}
}
Perfect, second point (from the BRouterWorker) was missing.
Together with some other minor changes, it seems to work correctly now, thanks.