New lib and the shortest profile

[afischerdev]

During my tests I found this 'bad way' for the shortest profile. Please see sample on BRouter-web

lib 1.6.3	lib 1.6.4

The different is not in the profile, it comes with the new lib. We changed the rounding rules: return (int) (d + 1.0); to return (int) Math.max(1.0, Math.round(d));

I still think it was a good decision. Old distance is 629m, new 610m

So what to do?

I moved costfactor a little bit down in the profile and add a penalty.

assign costfactor
  add accesspenalty

  switch isgoodforcars                                2

  switch and highway= not route=ferry                 100000
  switch     route=ferry                              5.67
  switch or  highway=motorway highway=motorway_link   100000
  switch or  highway=proposed highway=abandoned       100000
  1

What do you think about?

PS: the other profiles with shortest_way=1 like hiking, paved, walking have a similar problem

[quaelnix]

What do you think about?

That it was pure luck that the old (incorrect) code produced the result you were expecting, see: https://brouter.de/brouter-web/#map=17/52.36085/9.72077/standard&lonlats=9.722735,52.362138;9.720412,52.360599&profile=shortest

I moved costfactor a little bit down in the profile and add a penalty.

But with what rationale? Should the shortest.brf not always return the shortest way?

[afischerdev]

@quaelnix

That it was pure luck that the old (incorrect) code produced the result

No, that was the chance for your to get test values. The pictures are produced by the new lib, Using this or that rounding rules.

But with what rationale? Should the shortest.brf not always return the shortest way?

Yes, I would agree, but is also has a validForFoot set.

[quaelnix]

But validForFoot only has to do with turn restrictions and travel time estimation, not which ways to include or exclude?

I think it is perfectly legitimate to ask what is the target audience of shortest.brf and what behavior should the profile show. But I don't understand the connection with the rounding method.

The two routes in your example are almost identical in length (615.25 m vs. 615.18 m, that's around 0.01 % relative difference) and it was pure luck that the old rounding method resulted in picking the "better" route.

Look at this example: https://brouter.de/brouter-web/#map=17/52.35676/9.72249/standard&lonlats=9.722066,52.354523;9.721833,52.359127&profile=shortest, both new and old rounding method pick the same route, and it would be an awful choice if you actually wanted to walk it.

When the "better" highway=path foot=designated alternative is less than 2 % longer.

[quaelnix]

So what to do?

Decide if shortest.brf should generate the shortest possible route or the shortest possible route that makes sense as a pedestrian.

A profile developer may prefer the former, a typical end user may prefer the latter.

I personally prefer the former, but I am fine with both.

[afischerdev]

what is the target audience of shortest.brf

Yes, I would see here only developer. As well as for the dummy.brf

A nice new sample. Shows that it is more needed than a small change on shortest.brf

I would prefer to have at least one ready to use pedestrian profile. If we want to show how powerful the routing engine could be.

[devemux86]

what is the target audience of shortest.brf

I would prefer to have at least one ready to use pedestrian profile.

Indeed, shortest profile is useful for pedestrian routing.

[quaelnix]

Shows that it is more needed than a small change on shortest.brf

But why do you see the need for change when the target audience is just developers?

I would prefer to have at least one ready to use pedestrian profile.

I absolutely agree, but then we should create a new one and call it pedestrian.brf or something like that.

[afischerdev]

@quaelnix Please get this right, I'm not attached to the shortest profile. It's just a vehicle to get into a discussion.

I absolutely agree, but then we should create a new one

May be we have a sponsor for that.

@poutnikl What do you think about using hiking, walking or something like that as the default profile for the BRouter app?

[quaelnix]

Sorry to be the bogeyman again, but if BRouter stands for Bike Router, why use a foot profile as the default?

[afischerdev]

What is your meaning on default?

The serviceconfig.dat contains the defaults for the modes:

bicycle_fast fastbike
bicycle_short trekking
foot_fast shortest
foot_short shortest
motorcar_fast car-fast
motorcar_short car-eco

We have three modes, in two flavors and with defined default settings.

Also, we have several foot and car definitions in lookups.dat. Don't you think we should have a usable profile for every mode offered?

[quaelnix]

We have three modes, in two flavors and with defined default settings.

Now I understand what you mean and all starts to make sense. Sorry!

Don't you think we should have a usable profile for every mode offered?

Yes, I totally agree with that. However, it is very time consuming to develop a new profile that works really well.

[quaelnix]

So what to do?

The problem in your sample in the first post could be fixed like this:

assign costfactor
  ...
  switch or highway=proposed highway=abandoned        100000
  switch or bicycle=use_sidepath foot=use_sidepath    1.5
  1

---

switch isgoodforcars                                2

The problem with this is that the data quality is usually not good enough to determine if a way is really only suitable for cars or if there is a nice sidewalk or not. I do believe that the optimistic guess that you can walk along a street is the best we can do for now.

[afischerdev]

@quaelnix Sorry for the delay. I have found the hiking-mountain.brf in stock. So there is no need of more. I'll switch the foot defaults to this.

[quaelnix]

@afischerdev, sounds reasonable, but I would recommend to lower the SAC_scale_limit to 2 or maybe even to 1.

[afischerdev]

@quaelnix What is the reason for your limit? I thought to make it variable for direct use.

assign   SAC_scale_limit          3    # %SAC_scale_limit% | all paths with sac_scale higher than  SAC_scale_limit are forbidden | [0=avoid any SAC paths, 1=SAC T1, 2=SAC T2, 3=SAC T3, 4=SAC T4, 5=SAC T5, 6=SAC T6]

[poutnikl]

@quaelnix What is the reason for your limit? I thought to make it variable for direct use.

assign   SAC_scale_limit          3    # %SAC_scale_limit% | all paths with sac_scale higher than  SAC_scale_limit are forbidden | [0=avoid any SAC paths, 1=SAC T1, 2=SAC T2, 3=SAC T3, 4=SAC T4, 5=SAC T5, 6=SAC T6]

Having variable available - on web or in the app - is always good. In times of lack of such feature, I made Linux Bash script to generate profiles with near all kinds of possible SAC preferred/limit values, with respective generated names. The script is for a peek or reuse available in my repository.

https://raw.githubusercontent.com/poutnikl/Brouter-profiles/master/sedbatch

[poutnikl]

@poutnikl What do you think about using hiking, walking or something like that as the default profile for the BRouter app?

LocusMap use some in their own BRouter internal/online implementation. I have no problem in using some of my scripts as BRouter default, but I do not push them ( figuratively, not in GH sense ) Note that AFAIK all my pedestrian ( and most of bike ones ) scripts are generated from the template, they differ in few details of the particular parameter choice, as the tunable template is my profiles philosophy.

[areynoua]

Decide if shortest.brf should generate the shortest possible route or the shortest possible route that makes sense as a pedestrian.

A profile developer may prefer the former, a typical end user may prefer the latter.

Hi! I have developed some profiles for my personal use, but as an end user I prefer to have a shortest profile that really gives the shortest path, even if it does not make sense. I have several use cases, in known locations or to have a reference to compare “real” routes to. It should just be clearly mentioned in the profile.

[poutnikl]

Hi! I have developed some profiles for my personal use, but as an end user I prefer to have a shortest profile that really gives the shortest path, even if it does not make sense. I have several use cases, in known locations or to have a reference to compare “real” routes to. It should just be clearly mentioned in the profile.

I assume a single shortest profile will not please everybody. There is place for switches for hard nogoways and hard costfactor = 1. OR, having more than 1 profile addressing it. E.g. to have normal, "reasonable" Shortest profile and a "hardcore" really Shortest profile.

[quaelnix]

What is the reason for your limit?

T3 includes ways which are definitely not suitable for the typical pedestrian.

as an end user I prefer to have a shortest profile that really gives the shortest path

Afaik the plan is to only change which profiles the BRouter app uses by default. The profiles themselves will not be changed for this purpose. You can still manually select the shortest profile if you prefer it.

[poutnikl]

T3 includes ways which are definitely not suitable for the typical pedestrian.

T3 is not meant for typical pedestian, but for hiking. For ordinary pedestians is Walking T1 profile as max, I guess.

**Walking** "SAC T1 - hiking - Trail well cleared,  Area flat or slightly sloped, no fall hazard"
**Hiking-SAC2** "SAC T2 - mountain_hiking - Trail with continuous line and balanced ascent, Terrain partially steep, fall hazard possible, Hiking shoes recommended, Some sure footedness"
**Hiking-Mountain-SAC3** "SAC T3 - demanding_mountain_hiking - exposed sites may be secured, possible need of hands for balance,    Partly exposed with fall hazard, Well sure-footed, Good hiking shoes, Basic alpine experience "