Dynamic BRouter profile configuration

Libor Poutnik Striz shared this idea 7 years 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.

Best Answer
photo

Hi guys,

based on recent changes on the BRouter web site, here is a list of supported parameters by Locus Map 3.45 version (with a short description for what they may be used).

The app does not support all parameters in the configs, because I want to guarantee quality, translation, consistency. Also currently only "boolean"-based parameters are supported.

Parameters:

  • avoid_motorways - avoid motorways/highways
  • avoid_primary - avoid primary roads
  • avoid_toll - avoid roads with tolls
  • avoid_ferries - avoid ferries (if possible)
  • avoid_tunnel - avoid tunnels (if possible)
  • is_wet - flag usable to avoid muddy roads or really in case of wet weather
  • avoid_unpaved - avoid unpaved roads
  • ignore_cycleroutes - ignore cycle roads during computing
  • stick_to_cycleroutes - stick to cycle roads as much as possible

Replies (9)

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
2

>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
photo
1

Hi,


We are currently working on a similar feature in BRouter-web (https://github.com/nrenner/brouter-web). Relevant discussions there so far can be found in https://github.com/nrenner/brouter-web/issues/223 and current proof of concept in https://github.com/nrenner/brouter-web/pull/235.


As far as I understood, Locus currently supports a limited set of configurable options, using a syntax such as

assign avoid_motorways 0 # %avoid_motorways%


in the profiles. I am currently trying to extend this behavior (see for instance https://github.com/Phyks/brouter/blob/fc13c5c1594575cc92b912536c7fa9b77bd72d1c/misc/profiles2/trekking.brf#L12) with the following syntax


assign allow_steps = true # %allow_steps% | Set to false to disallow steps | boolean


That is including the Locus "%<PARAMETER>%" special comment and extending it to provide a description and a type (boolean / number / options) for the parameter.


I don't really know much about Locus' internals. Would the current implementation be indeed compatible with our extension? That is, would

assign avoid_motorways = true # %avoid_motorways% | Set to false to stop avoiding motorways | boolean


be compatible out of the box with Locus?


Thanks!

photo
1

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();
And if the result of this test is correct, later value replaces with the method:


config.replaceFirst(
    String.format("(\\d\\s*#\\s*%s)", key.replace("%", "\\%")),
    (isEnabled() ? "1" : "0") + " # ");
Where "key" is parameter key and "isEnabled()" call is the result of checkbox in UI. 


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

photo
1

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!

photo
1

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.

photo
2

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.

photo
1

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.

photo
2

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)

photo
1

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.

photo
2

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

photo
1

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.

photo
1

@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

photo
photo
1

Hi guys,

based on recent changes on the BRouter web site, here is a list of supported parameters by Locus Map 3.45 version (with a short description for what they may be used).

The app does not support all parameters in the configs, because I want to guarantee quality, translation, consistency. Also currently only "boolean"-based parameters are supported.

Parameters:

  • avoid_motorways - avoid motorways/highways
  • avoid_primary - avoid primary roads
  • avoid_toll - avoid roads with tolls
  • avoid_ferries - avoid ferries (if possible)
  • avoid_tunnel - avoid tunnels (if possible)
  • is_wet - flag usable to avoid muddy roads or really in case of wet weather
  • avoid_unpaved - avoid unpaved roads
  • ignore_cycleroutes - ignore cycle roads during computing
  • stick_to_cycleroutes - stick to cycle roads as much as possible

photo
2

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

photo
1

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.

photo
2

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.

photo
1

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

photo
1

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.

photo
1

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

photo
1

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

photo
1

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.

photo
1

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.

photo
2

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.

photo
1

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

photo
1

Perfect, progress :).

External profiles sorted by name > next version.

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

photo
1

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.

photo
1

@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!

photo
2

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.

photo
1

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

photo
1

@Michal: Thank you, looks good :)

photo
Leave a Comment
 
Attach a file