Dynamic BRouter profile configuration

Libor Poutnik Striz shared this idea 9 months ago
In Progress

Arndt ( BRouter author ) has recently mentioned a very interesting idea about dynamic config screen for BRouter profile parameters. Locus config screen for the profile would be defined by the profile itself.

Profiles currently use this syntax to assign values to variables

  1. assign parameter value

The idea is to add a specialized comment ( # is line comment character )

  1. assign parameter value # %parameter% Locus GUI name|Locus GUI description

I guess Locus should consider only first 3-4 parameters ( AFAIK MapQuest has 4 ), in case the profile author got crazy.

I have recently proactively implemented it for some parameters in my car profiles. But am not aware, how exactly is paramater management implemented, if the idea was already considered, or if such dynamic screens are possible at all.

Anyway, I am posting it on the Helpdesk for the idea not to get lost.

Comments (20)

photo
1

Hello Libor,

interesting idea. I can imagine, that such option gives quite a lot of freedom to profile creators and also a lot of options.

Tell me ... how many people here is able to make it's own profiles with such settings? I believe there won't be a lot of them.

I'm little but worried about inconsistency in translation (here won't be any) and about possible mess that this may cause in case of incorrect usage.

Hmm can't say I'm big fan of this, on second side, Locus Map is about "options" and some "freedom" also for users. Have to think about it more when I come back to work...

photo
1

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

photo
photo
1

Hi Menion,

The point is, that this feature is not for the profile authors. It is for the users, to get desired options and avoid the profile flood. I doubt the 5 votes suddenly appeared are from the profile writers.

I agree that the localization can be problem, but it could be feature for advanced users.

Take your time for the consideration, the main point was to have the idea registered.

photo
1

Hi,

Ah so if this idea is mainly for users, should be possible to create some list of possible parameters... like top 10 most useful ... and offer these to profile authors? Currently there are only three and these also hase to be directly as third argument. I see no problem to support ten of them (which will be also correctly localized) and which may be wrote in profiles in similar schema as comment ( as you suggested ). Should this help?

photo
1

Good day Libor,

so for now, let's stick with some set of predefined parameters that will be supported by Locus.

Format of parameters as you already have in some car profiles will be supported in next version. I see benefit of this system that you may generate single profile file that will works for BRouter as is and for Locus Map as well without any modifications.

  1. assign avoid_motorways 0 # %avoid_motorways%

In such case, Locus recognize that parameter may be substitued and will offer UI for it.

Currently supported parameters are

avoid_motorways , avoid_toll, is_wet , avoid_unpaved

What I miss is parameter that force using cycle router. Rest is no you or on discussion here. If you find some time and modify hiking and cycle profiles, I'll include them into next Beta version and also extend support for some other parameters if will be interest.

photo
1

Hi Menion,

I am glad you like it. I will try to select the parameter candidates for bike and hiking profiles later, as it is less obvious what the good set should be like - I have to think it through...., also to let some time for discussion.

I may not understand properly, what exactly you mean by "parameter that force using cycle router." The scope of usage is given by the profile context. Explicit statement about intended usage is defined by BRouter flag parameters

assign validForBikes 1

assign validForCars 0

assign validForFoot 0

These parameters are used in BRouter GUI during old way of mapping profiles on the transportation modes car/bike/foot fast/short, with preselection of all allowed combination. The user than may to narrow the selection.

This definition is constant for given profile, usually is just for a single mode of transportation. and I do not suppose to be exposed in GUI flags.

Well, I can imagine a special profile can be used in range road bike - electrobikes - mopeds.

http://brouter.de/brouter/profile_developers_guide.txt

photo
1

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!

photo
1

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.

photo
photo
1

Thanks for implementing support for the 4 predefined parameters!

Would it be possible to also read out the default setting of these parameters from the profile and "preselect" them accordingly in the UI? Because at the moment, the parameters seem to be set to not selected ( =0 ) by Locus, regardless of the default setting in the profile.

photo
1

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.

photo
1

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?

photo
1

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.

photo
1

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 ;-) ).

photo
1

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.

photo
1

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.

photo
photo
1

I would love to see one specifically for motor bikes.

We could avoid the big cities, avoid the motorways and take the slower, more secnic route with better curves and hills.

photo
1

That is rather a topic for an independent profile.

photo
1

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

photo
1

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

photo
1

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.

photo