Dynamic BRouter profile configuration

>how many people here is able to make it's own profiles with such settings?

I'm a profile tweaker not author, but agree with Libor. Why should all profiles necessarily have all parameters or be constrained to a fixed set? Each profile should have freedom of just relevant parameters. Some authors may provide simple profile with no choice of parameters, some author (for own testing, experimentation or super flexibility) may want to provide lots more parameters. A marketplace of ideas.

For example I can imagine modifying a profile to expose some parameters uphillcost, uphillcutoff, just to see whether I can get better match for my own preferences. This proposal provides an elegant & fast way to perform this testing.

Hello Libor,

sorry, small "typo". .. "parameter that force using cycle routeS". I'm not skilled with these BRouter profiles because I never needed them and I'm trying to keep it as is because then I should think as simple bloody user :). On a vacation, BRouter often led me to target on the road, even that not far away was little longer cycle route, so something like "Stick to cycle routes" should be welcome from my point of view. Anyway I'll gladly let this technical decision to people like You, who use BRouter a lot more and mainly ride a bike a lot more. Thanks for your time!

Aaah, I see. Well, both the standard trekking profile and my trekking template address level of marked route preference. Both profiles with default setting use a mild preference of cycleroutes.

Additionally, The standard Trekking uses

assign ignore_cycleroutes = false # set to true for better elevation results

assign stick_to_cycleroutes = false # set to true to just follow cycleroutes

The former works like no marked routes ever existed.

The latter uses strong marked route preference ( but not absolute preference, as there is always trade off between preference boost and undesired detours )

My Trekking profile template follows similar schema, but implemented diffrerently. It uses numerical tuneable parameter

1. cycleroute_pref

and pregenerated profiles.

assign cycleroute_pref 0.2 is use for default Trekking-dry

assign cycleroute_pref 0.0 is use for Trekking-ICR-dry ( ignore cycle routes )

assign cycleroute_pref 0.6 is used for Trekking-FCR-dry ( follow cycle routes )

BUT, similarly as for car profiles, it will be simple to introduce the same logical flags as are in standard Trekking profile, following the comment convention, that would overrule the settings.

Good day zossebart,

I'm not sure if this settings is useful. Mainly because all four parameters has shared settings across all configurations. So once set to true/false, it will be same in new loaded profile.

I wants to say that if user played at least once with BRouter in Locus, these default values are already set to "false". So not matter what settings will be in custom profile, "false" remains as preselected value.

Ahh ok, haven't recognized that the selection is global/shared across Profiles.

I ask for this because in my mtb-profile, I have implemented two "modes": one for "normal" (easy) routes and one for trickier (also potentially more dangerous) routes. The "avoid_unpaved" parameter was the only one of the four which at least partly fits for switching the mode.

So I use avoid_unpaved=1 as the deafault for normal routes and avoid_unpaved=0 for the trickier routes. But this means the user has to set avoid_unpaved through the Locus UI in order to not get the hard routes...

As the parameter selection is global, this means all other profiles also work differently after the user had set avoid_unpaved=1 in order to get "normal" routes with my profile.

Would it at least be possible to save the selected parameters together with the profile instead of globally?

Complicated tasks. When I made first version of this "BRouter configuration", all settings were independent as you want. Anyway there were negative votes that it is not so useful, because you have to always check what settings is set for certain profile, so it is now united.

I personally do not have clear opinion on this, because both sides has it's usage and it's +/-. Anyway as I use navigation in the field, current solution looks for me more useful. When I set "avoid unpaved", I just do not have to take care of this settings anymore because it's always set to wanted value.

Ok, I understand.

Perhaps you are right, maybe it gets too complicated.

Allowing user-defined parameters in addition to the four "standard" ones should also add too much confusion I think (how to label?, no translation, no consistency across profiles).

So I think I have to think about other ways of solving this with my profile. Perhaps I will split it into two seperate profiles again (I just united them because of the new Locus UI features ;-) ).

Currently, Locus supports four parameters.

If consensus can be found with other users that create routing profiles ( anyway except Libor? ), I see no problem to add support for more parameters directly into Locus.

Main point of this idea was to create dynamic parameters that will be defined in config file itself. I'm anyway against this mainly because of translations.

Anyway I'll gladly add few more parameters if needed and if it will make sense.

Ok, thanks for the offer. But I'm afraid my special case is only useful for my profile but not general enough for other profiles. It would be something like "take more risky routes into account" or "experienced rider".

Independent of my mtb-profile, you could think about a "prefer cycle routes" parameter. You asked for this in this thread before. Libor said that it would be no problem to implement a switching parameter for this in his profiles. In the default brouter trekking profile there is a (opposite) switch for this purpose (ignore_cycleroutes). So we should find a consensuns on how to name and define the parameter first...

Analogous to the "avoid_toll" parameter for cars, maybe an avoid/allow ferries parameter could be helpful for bike and foot profiles.

That is rather a topic for an independent profile.

How would that motor bike profile be different to a bicycle profile?

In many possible ways. Different road class priorities, different surface priorities, different elevation priorities...

Libor is correct, Thank you.

There are also options for dirt roads that you would not want to take a car/bicycle down. Many of the roads lead way back in the boonies. Round trip for a motorbike or a overnight stop for a bicycle.

They are different. With different laws. Motorbikes can not use bike lanes. for instance.

Hello Lucas,

interesting progress, I'm looking forward to resulting :).

Current Locus Map implementation is pretty simple. I'll reveal some technical details for easier explanation.

---

Locus Map firstly checks if one of four predefined parameters is in the configuration file with:

Pattern pattern = Pattern.compile(
    String.format("(\\d\\s*#\\s*%s)", key.replace("%", "\\%")));
return pattern.matcher(config).find();

config.replaceFirst(
    String.format("(\\d\\s*#\\s*%s)", key.replace("%", "\\%")),
    (isEnabled() ? "1" : "0") + " # ");

So If I look correctly, then while syntax remains as mentioned

assign <<parameter>> 0 # %<<locus_supported_key>>%

it should work correctly even if after this text will be more information.

---

As mentioned in your discussion on GitHub, I'm generally against some special custom parameters from the usability point of view. Anyway "boolean" based values or some "enumeration" may be doable. Anyway, I'm really against numbers. It may really complicate life with some validation, limits, etc.

---

So generally after these two years, I can imagine supporting syntax

assign <parameter> = <value> # %parameter% | description | type

I would just really vote against support for numbers. The same system used on the web and also in Locus Map should be really useful for people trying to optimize the profiles, so "thumbs up" from me :).

I can confirm that Locus remains compatible despite additional comment information. Did a small Test with one of my profiles.

I'm really looking forward to having support for more parameters in Locus, as well as in Brouter-Web!

Thanks for the feedback on this! Great to hear that the syntax we currently devised is retro-compatible with the

current syntax supported by Locus.

Concerning the support of numbers, I'd be inclined to have this for all configuration options which makes sense for a given profile within the profile (so the trekking.brf profile from BRouter would have all the required comments for the interesting variables) and then any app / consumer would be free to set or ignore part of the configuration options (for instance with a whitelist as currently done in Locus).

BRouter-web is looking into translations of these variables names and descriptions as well, so it might end up filtering them as well.

Just wanted to let you know that this is implemented in brouter-web now. See the Options pane for the default trekking profile for example.

It would be very nice if support for (general) parameters could be implemented in Locus as well! Maybe disable it by default and make it switcheable through expert settings to not confuse new users.

Hi, seems there is quite a lot of these parameters. At least some most important may be added, agree.

Do you or Lucas know, is somewhere any list of these parameters? Can't find it, thanks.

There is no general list. With this feature, it is possible for the theme developer to expose a user-interface for ANY profile variable he thinks is necessary/useful, along with a short description. Certainly the trekking profile carries this to the extreme by exporting nearly every global variable (brouter-internal and user-defined) possible. I think it's mainly meant for demonstration purposes.

However, only some of the exposed parameters are user-defined (allow_steps, allow_ferries, ignore_cycleroutes, stick_to_cycleroutes, avoid_unsafe, consider_elevation), the rest are brouter builtin variables (which means their name is fixed).

By the way, there seem to be 3 possible parameter types:

boolean

number

select (predefined discrete values)

Ah good points, thanks, got it. I completely forget how this system worked.

So it is on me, which parameters will Locus Map support. I'll try to think about it little more and add support for few from this sample file, to keep some kind of compatibility. Once there will be something to test, I'll let know here.

It's ok if you create (or extend) a whitelist of parameter names Locus will support, but please add an expert option to ignore the whitelist and show all of the parameters offered by a profile for power users!

Please also look at other profiles and their parameters in brouter-web when deciding which parameters go on your whitelist. The car profiles for example have a very different set of parameters compared to bike or foot profiles (mainly for fintuning of ETA and energy calculation through maxspeed, vehicle weight and air drag etc.)

I would also like to join the request for the implementation of parameters like on brouter, disabled by default and made switchable through the advanced settings so as not to confuse new users. It would be convenient to have the parameters on the screen without having as many profiles as there are combinations of parameters. In my profile, I have about a hundred combinations, it would be unthinkable to have so many files, while having a single profile with the parameters to choose from would be perfect.

@Menion, you wrote "Anyway "boolean" based values or some "enumeration" may be doable. Anyway, I'm really against numbers." Do you mean numbers in parameter names (so e.g. numbers as in highwayClass1, HighwayClass2,... provided as "highwayClass[1-6]") or in paramter value's / data types? If names, 100% agree. If values, then feedback for your thoughts that current limitation to booleans is strongly limiting routing profiles' usefulness in real life, while enums or numerics would boost precision & usefulness, for example

• TooSteepUphill is the max slope, cruicial for useful cycling route selection – with muscle bike, a longer time more than 5% uphill is beyond my fitness level, while with e-MTB, 15% to 20% are fine for me, while for my mate, around 10%. A boolean is too limited. An enumeration of e.g. 6 ranges (<5%, <10%, <15%, <20%, <25%, unlimited) would work OK. A number would allow finer tuning and for "unusual" fit people, also allow to cap at e.g. <30%
• maxSpeed, totalMass and bikerPower are numeric BRouter parameters, massively affect accuracy of travel time computation, and may change between each tour, e.g. mass of luggage for afternoon bike trip is 1kg but for full-day climbing tour 15kg and with kid on the luggage carrier 35kg, bikerPower as adult with e-bike is completely different (350W) than with kids on muscle bike (25W), etc.
  I can't imagine to solve that via booleans in a usable way.
  As enumerations, GUI may be a horizontal slider line. It may have at most around 6 stops in the range selection, because more are a little dense if texts shall still display or selection shall be possible with a thumb on a 4" display / on 6" while moving. That would allow to have few and very wide/rough ranges for selection (<40kg, 40-80kg, 80-120kg, 120-160kg, 160-200kg, >200kg e.g. for tandem, or for cargo bike with 2-3 kids in the trunk).
  We could also use GUI spinning/rotating wheel (image) as known from e.g. date & time selections in apps. That would allow much more enum values to be precisely & quickly selectable, but works not only with enums but similarily well with numerics: Users cannot enter any string, but only select from integer values in a meaningful range, e.g. totalMass from 15 to 400kg, bikerPower 10 to 1500W to also reflect strong e-bikes with 1000W motors.
  

Side note: avoid_toll for cars shall also be enum IMHO. I have a vignette for Switzerland but no Pickerl for Austria and as in France, national streets are parallel to highways and nearly as fast, I'd like the router to avoid toll in AT + FR but not CH. So enumerations would be great, i.e. avoid_toll=AT,FR but I have no idea whether BRoute or LoRouter support this.

Best regards,

Georg

In my case, I don't use the same variables as you, but I would really appreciate it if it were possible to select or enter the parameters that I have identified during programming for my needs, which in this case are for off-road motorcycles.

I would be happy to see this implemented either through an add-on or via an expert menu option. This would allow me to fine-tune the routing profiles to my specific needs and preferences, which would greatly improve the usefulness of Locus for me.

It seems support for (almost) all parameters of a profile finally got implemented in 4.24!? Menion, thank you so much for this, after all these years!

I noticed a last small bug (or intentional feature?), however: parameters with an enumeration type (in the form of [ 1=option1, 2=option2 ] ) are not displayed in the ui. Is this intentional? Because some paramters are only useful in a specific range or with a set of discrete (named) values.

I also noticed some nice sliders in the UI of your internal LoRouter profiles. I assume these are a special implementation which are only accessible through your internal profiles? I tried to use the corresponding profiles from your github as manual profiles, but they don't show these sliders :(

You are welcome, after all these years :)

Enumeration > ah, I've completely missed this option. Will look at it, thanks!

And slider > yes, it is more complicated. We have our profiles on GitHub, but it is not so easy to use them. So for now, suggest sticking with the official BRouter app and it's profiles if you want some customization.

Ok, I just thought I could modify my own profile in a way so that it would also display a nice slider in the Locus UI. But it seems like it is a special Locus-internal imlementation which doesn't work with external profiles at all.

Maybe some time in the future...

May I ask if you found some time to look into the brouter profile enumeration type parameters? Do you think it will be possible to support them in the locus ui? This would be great, IMHO it's the only thing missing for full brouter profile parameter support.

And as I already wrote: it would be nice to have those sliders that you use with your internal profiles available also for external profiles. But I know: this is only nice to have. ;-)

Enumeration is in the @Radim Večerek todo list ... I'm eagerly awaiting it, too :).

Nice to finally have more options to play with.

Unfortunately, my profiles do not benefit from these changes, as I use at least one own parameter which is not in your whitelist. I had the hope that I could re-merge my two mtb profiles, because they only differ in the value of this one parameter.

Nontheless, I understand why you decided this way...just hoped that you would make it possible for power-users to disable this whitelist (through expert-settings or even config.cfg). Maybe in the future? ;-)

Which parameter is missing to unite your profiles? I'm curious also because I was already some time ago, thinking about contacting you with the offer to include your profile(s) directly into Locus Map.

As the parameter is only used in my profile(s), I don't think it makes sense for you to support it. Also it's an integer type, although it might be converted to a ranged type, which you don't support either.

That's why I hoped for general support as in brouter-web.

Hi @Menion,

how can I activate stick_to_cycleroutes? The bike profiles do often not use existing & mapped cycleroutes leading to the destination.

I would like to have a switch telling to avoid longer uphill bike routes (BRouter paramter uphillcost) - my city stretches several hundret elevation meters... Any chance something like that is added?

Best regards, Georg

Hi, Georg D,

The profile must internally support the respective parameter, then it must expose it to LocusMap the way LocusMap expects it.

stick_to_cycleroutes is the internal BRouter parameter of the profile Trekking, named in Locus as check inoption "Prefer cycle routes". It does not mean absolute preference, just putting more preference to the routes than usually.

Other profiles, provided by users, may not use this parameter, which is therefore not available. E.g. Poutnik's profiles use numerical parameter cycleroute_pref, that is for user convenience preassigned in different profiles. ( ICR, FCR, LCR and not published yet NCN, LCN )

Uphillcost Brouter parameter is not currently directly exposed in any profile, as Locus map supports logical parameters only ( switches ). It is indirectly supported by numerical parameters of some profiles, like "hills" or "MTB_factor" in Poutnik's profiles.

Libor, thank you for your reply.

Sadly, I simply do not find "Perfer cycle routes" in Locus 3.45.1 despite trying advanced settings and using/discarding "Locus profiles" and reading the manual - please see attaches screenshots. Can you point me to where I can find it?

Thank you for pointing to Poutnik's profiles; with that I found a link to the github project in Locus manual. I will have a look for a profile with high cost of uphill but elsewise "normal everyday routing" and may edit a profile accordingly.

Best regards, Georg

It should be there. I suppose you do have installed BRouter and you have access to BRouter profiles.

In your file Screenshot_20200507-171320.png I do recognize a heading "BROUTER PROFILES" in the middle of the profiles listing. This heading does not appear here, see my attached screenshot. Do I need to do a certain setting to "unhide" these options?

Yes, BRouter is installed and working for navigation within Locus.

I don't know what you mean by "have access to BRouter profiles" respectively how to check that. When starting BRouter directly I see profiles but a different amount and different names than appearing in Locus' BRouter settings.Just to avoid that different versions are causing confusion: I have Locus v3.45.1 and BRouter v1.6.1 and Android 9.

In certain Locus and Brouter configuration, mainly related to Locus and BRouter files locations and mutual access rights, Locus may not have access to Brouter internal profiles, relying only to those profiles directly embedded to Locus. As I have both Locus and Brouter data folders in the internal storage "root" folder, I had never such problem.

AFAIK, it helps to create a folder Brouter in the Locus data folder and move them. Try to search help.locusmap.eu or forum.locusmap.eu for such info, as Menion has mentioned something like that somewhere.

Yes, thanks Libor. Suggest to forget on profiles stored in BRouter directory and used by other apps. Since Android 11, this won't be possible at all.

For using custom BRouter profiles is best place them into directory mentioned by Libor, so into Locus/data/brouter.

Thank you both, now I see downloaded Poutnik's profiles including "valley" which is what I was looking for :-)

@all: I still wonder why Libor has two checkboxes "prefer cycle routes" & "Ignore cyle routes" (at the bottom Screenshot_20200507-171053.png) and I do not. IMHO it would be useful to have these checkboxes as default active in standard Lovus profiles because that would reduce the amount of profile variations needed.

@Menion: Profiles listed below heading "BRouter profiles" seem chaotic, i.e. car, bike and hike are all mixed. If it is low effort to sort them by profile name or profile's file name, please do so, because that makes it a lot easier to find the desired profile.

Who has the required rights to update Locus documentation? Especially Menion's hint with directory is missing in Locus pages as well as Poutnik's Locus page.

https://docs.locusmap.eu/doku.php?id=de:manual:user_guide:functions:navigation:settings&s[]=brouter

old text: Für den BRouter kann man auch eigene (non-Locus) Profile erstellen und verwenden, nur ist das nicht ganz trivial und nur sehr erfahrenen Nutzern zu empfehlen. Mehr dazu finden sie hier >>

new text: BRouter kann die von Locus bereitgestellten Profile nutzen oder auch von anderen Nutzern bereitgestellte oder selbst erstellte - wobei das Erstellen nicht trivial ist und nur sehr erfahrenen Nutzern zu empfehlen ist. Poutniks GitHub-Seite bietet weitere Informationen und viele gebrauchsfertige Profile, die man nach dem Download im Verzeichnis Locus/data/brouter (selbst anlegen falls es fehlt) ablegen sollte.

https://docs.locusmap.eu/doku.php?id=manual:user_guide:functions:navigation:settings

old text: BRouter can be used also with custom (non-Locus) profiles which is a bit advanced problematics. More info can be found here >>

new text: BRouter can be used with the profiles shipped with Locus and also with profiles provided by other users or self created ones - saying that, creating custom profiles is not trivial and recommended for quite advanced users. Poutniks GitHub page provides further information as well as many ready-to-use profiles which shall be downloaded and then placed in the directory Locus/data/brouter (create if non-existent).

Perfect, progress :).

External profiles sorted by name > next version.

Documentation always forward to @Michal Stupka , he will take care of it. Thanks Michal ;)

You may try these ones. Consider master as releases and develop as betas. ( Master and develop are GitHub code branches )

Just for curiosity, these archives were generated locally from the remote GitHub profile template on the target Android device by Linux Bash script, running in (very fast) termux Linux console emulator.

@Menion: Thank you :)

@Libor: Thanks for providing them. I tried both, but the checkboxes did not appear - with BR-Bike-Profiles-develop-locus.zip a new checkbox "avoid unpaved" appears, so the mechanism works in general but just not for ignoring/preferring cycle routes. For me, no further investiment required, but if you wanna investigate, I'm happy to help!

That is because my profiles do not use the flags ignore cycle route nor stick to cycle route.:-)

They use more sophisticated approach with the numerical parameter cycleroute_pref, by which there are tuned.

@Menion , @Georg D: done, thank you for the update :)

@Michal: Thank you, looks good :)