Normalizing the profiles

[afischerdev]

We have to change the profiles when the issue #486 goes online and the PR #458 is merged. So it is a good time to think about normalization of the profiles. What I see at the moment:

• our standard profiles have different handling for access rules
• make variable tags (editable in BRouter-Web) available in all profiles
• check if a rule is better to be fully banned or if a heavy penalty should be added
• check avoid_path for other bike/foot profiles
• check fastbike for excluding unused constants #573

What do you think? Other ideas?

[Totorrr]

Hello @afischerdev or @quaelnix,

could you give me an (even fictional) example for "check fastbike for excluding unused constants"? Are you referring to the constants at the beginning of the file that would not be used (currently, I think there are none) or are you referring to writing the profile in such a way, that for example, when "consider_traffic" is false, some blocks of the profiles relating to traffic would be "bypassed" for better routing engine performance? Or something else? :)

Thank you,

[afischerdev]

@Totorrr Thank you for looking into the still unresolved problems.

The unused constants are removed by @quaelnix with this changes.

The consider_traffic problem is still present. The estimated_traffic_class is always used in the fastbike profile. The variable consider_traffic is used a little bit different to the other consider_... . An extra switch is needed, something like

assign trafficpenalty =
      switch not equal consider_traffic 5
      ...
      0

An example could be every route with estimated_traffic_class like this

[Totorrr]

Hello @afischerdev,

The consider_traffic problem is still present. The estimated_traffic_class is always used in the fastbike profile. The variable consider_traffic is used a little bit different to the other consider_... . An extra switch is needed

In the current fastbike.brf, I see this:

https://github.com/abrensch/brouter/blob/037b3385a74af230feadfe2f180499699e1c66fd/misc/profiles2/fastbike.brf#L162-L164

It seems to me that the switch is already there. Is there something that you see me missing @afischerdev?

Thanks.

[afischerdev]

@Totorrr Sorry for the delay. You are right, I think I was looking at the BRouter web profile and missed the current profile in repo.

[Totorrr]

Hello @afischerdev,

in the fastbike.brf profile, I see this:

https://github.com/abrensch/brouter/blob/037b3385a74af230feadfe2f180499699e1c66fd/misc/profiles2/fastbike.brf#L176-L184

Do you think that writing something like this instead:

switch not consider_noise 0
  switch estimated_noise_class=  0

would improve performance (in the case where we don't consider noise)?

If not so, I am not sure I see something obvious to optimise, do you? If not, maybe we can close this issue?

[afischerdev]

@Totorrr I think we can close. And I can't see a performance improvement, if no consider_noise it should jump direct to the end of block and assign a '0' . But I never did a performance test with profile logic.