cost for routing over "ford"

[utack]

Hi,

maybe fords can be added? https://wiki.openstreetmap.org/wiki/Key:ford
A part of a street that is marked as ford=yes could be assumed flooded, and have a really high penalty. Same goes for crossing a ford=yes point, that is on the way.

Or are they too rare to be considered in the route calculation?

Thanks

[poutnikl]

Hi utack, you can see the frequency of BRouter relevant OSM tag combinations key=value for Germany in Brouter lookups.dat file.

Fords seem frequent enoug to consider. But penalizing them can be very tricky.

Where is just a node with ford=yes, it can be (almost) dry, or passable by a bicycle ride, or just by simple pushing or carrying bike barefoot.

Where is a way with ford=yes, it is supposed to be wider, but what is passable for cars, is usually passable for bikes as well, by one of above methods.

So it is a question of opinion, what initiialcost for a node and initilcost and costfactor for the way to use. The ford ways should use the ford node as well, being joined with water strams ( both with ford=yes, as highway=ford is deprecated ).

What values do you suggest ?

[poutnikl]

• by default I see fords should be allowed, but penalized. Penalization could be done with smaller initial cost for ford nodes and higher for ford ways, with significant but not strongly avoiding costfactor.

  • E.g.: way context: initialcost = 1000, costfactor = 50
    ( if properly mapped , both initial costs for node and way would be triggered )
  • node context : initialcost = 500

• I have an idea about the ford like options between 0=ignore for MTB, 1=penalize(default),2=avoid by high penalty,3=forbide

• It could be done explicitly manually, with parameter ford_treatment=0/1/2/3, or being derived from value of MTB_factor ( more exactly MTB_factor - smallpaved_factor difference ). E.g. ford_treatment=3 for MTB_factor <= -1.5 ford_treatment=2 for MTB_factor <= -0.5, > -1.5 ford_treatment=1 for MTB_factor <= 1.5, > -0.5 ford_treatment=0 for MTB_factor <= 1.5, > -0.5

• Another option would be not treat it stepwise, but progressively based on particular MTB_factor value, with hard avoiding and ignoring as extreme values.

[poutnikl]

As "way fords" should be marked as highway= ford=yes, it should be considered. A ford on main network highway with declared surface ( e.g. surface=concrete ) is probably easier to overcome then a ford on a track/path with expected stones on the river bed.

[utack]

ford I would say gets a bit more penatly than walking, because you might have to carry your bike?
A node needs to represent time to get off and on the bike, and 5m carrying it maybe? Quite honestly I am not sure what kind of cost that would be

[poutnikl]

Try Trekking-Poutnik in Ford-handling branch. Use parameter ford_handling ( line 47 ) = 0/1/2/3 for 0=ignore(like before),1=penalize(default),2=soft avoid , 3=forbide

[poutnikl]

eventually, play with numerical values on lines 120-133, where are manages both initialcosts and the costfactor ( additive to the highways costfactor )

[poutnikl]

The initial cost depends on if you go through like a hardcore biker, so initialcost is minimal if you just carry it , so it is like 50m if you additionally have to adjust yourself ( shoes, cloth ) , like 200-500m if you additionally have to unload your bike when travelling, like 1-2 km

[utack]

Yes it works. This is mode 2 My guess would be that mode 1 is currently too low penatly and mode 2 too high penalty, but it works

[poutnikl]

Every penalty would be too low and too high at the same time, depending on circumstances,
what is the physical situation
and what is your approach to it. :-)

[utack]

I guess 500 for nodes is ok. Carring a bike over a water is not pleasant, worst case we better drive 200m around a dry ford, it is not like they are so common it will influence long routes a lot Thank you for adding it so quickly

[poutnikl]

BTW, I am still thinking about the ford penalty system automatically derived from MTB factor. MTB_factor < -1.5 - fords forbidden, MTB_factor > +1.5 - fords ignored, rest something ( non linearly ) between.

[utack]

That would be smart, there are so many parameters already

[poutnikl]

My approach is to make the profile template tuneable, not to have a profile one size fits all. OTOH, to have some default settings that would fit the need of majority.

[poutnikl]

I think the used MTB_factor for the ford handling would explicitly express the user attitude to troubles, so he would got what he wanted.

[utack]

Absolutely, it is a good idea

[poutnikl]

Version 2.5.10 BETA - the link as above: * ford_handling via MTB_factor ! fixing penalizations of empty tracktype and surface + added progressive decrease/increase of turncosts for positive/negative MTB_factor