poutnikl / Trekking-Poutnik

Profile template for Trekking bike profiles for Brouter application
8 stars 3 forks source link

Parameter without effect? #21

Closed LeopoldKellers closed 7 years ago

LeopoldKellers commented 7 years ago

Hi, while playing around with the updated profiles, I noticed an oddity. This may or may not be a bug, but I'd like to understand what is going on.

Example I used your current nightly here, but it is the same with the other profiles.

So far I thought that when entering a way/node without bikeaccess, then the last line should represent the action of getting off the bike by adding the value 100 (which I thus called dismountpenalty).

assign initialcost =
        add ( if highway=traffic_signals then 120 
              else if highway=stop  then 60 
              else if and highway=crossing bicycle=no then 60 
              else if and highway=crossing crossing=no then 300 # workaround affecting road routing
              else if ( ford=yes ) then ford_initialcost_node
              else initial_cost_node )
            if bikeaccess then 0  else ( if footaccess then 100 else 1000000 )

However, in the short piece of route posted above, this 100 does not show up in the computed cost. The middle piece is explicitly tagged bicycle=no, so bikeaccess should be set to false by means of

assign bikeaccess =
       if nodeaccessgranted=yes then true
       else if bicycle= then
       (
         if vehicle= then defaultaccess
         else not vehicle=private|no
       )
       else not bicycle=private|no|dismount

(unless nodeaccessgranted=yes, but that shouldn't be the case, since cycle route networks are absent)

The map data is simple enough in this case, so I believe that I can rule out incorrect tagging despite my (still) lacking proficiency in that area of OSM. What is going on here, is it intended behaviour and if so, why? Changing the value from 100 to sth. else has no effect at all on the computed cost. Shouldn't it?

Another Example

poutnikl commented 7 years ago

See the data tab. The bicycle=no tag relates in this case to the way context, not to node context. Therefore the respective costfactor is penalized , but the node initialcost is not affected.

So, currently it works as written.

poutnikl commented 7 years ago

The true is, there should be Initialcost of the way, related to the dismounting, or it should be propagated to node context. One has to careful not to implement double actions. I will look at it after weekend, I will be away.

poutnikl commented 7 years ago

I see the probable solution as the extra initialclassifier, being common for all roads with no bicycle access, to avoid excessive penalization for changing road types.

LeopoldKellers commented 7 years ago

Ok, I believe I figured out what is going on. In an example like the one given above, the line

if bikeaccess then 0 else ( if footaccess then 100 else 1000000 )

has no effect because it only relevant to the node context, right?

When adding this line (together with the access logic preceding it) to the initialcost assignment in the way context then things work exactly in the way I imagined it. That is, the constant of 100 (or dismountpenalty if you like) is applied when changing from the road onto the path where cycling is forbidden.

Now the question is: should there be sth like a dismountpenalty every time when changing from a way with bikeaccess to one where the bike needs to be pushed (well, if one is willing to abide the law at least)? Or do you consider the increased costfactor alone as sufficient? My opinion would be that the action of getting off the bike should be represented separately.

Regarding double actions in the node context: I have quickly tried out several long, random routes through major cities in Germany and varying the dismountpenalty in the line quoted above (ie. in the node context) from 100 to 0 or 7777 never had any impact, neither on the suggested route nor on its total cost. So this value never seems to be added at all in the current profiles.

poutnikl commented 7 years ago

Right, it applies only on node context and there is no node with bikeccess affecting tags.

Initialcost in way context is applied every time when Initialclassifier changes value. So if there were joined OSM segments, all with forbidden bikeaccess, but with different Initialclassifier, the dismount penalty would be applied to all of them, even if just one occurence is justified. That is why, IMHO, bike forbidden roads should all share the same Initialclassifier value.

Both CF penalization and initialcost penalization should be applied. I already expressed the intention in my last post:

I see the probable solution as the extra initialclassifier, being common for all roads with no bicycle access, to avoid excessive penalization for changing road types.

Wrong and easy to fix logic is not justified by low probability.

poutnikl commented 7 years ago

@LeopoldKellers : The way Initialcost reflecting the dismounting is implemented in aacd86ff6a3b3df15f56a00dfbf113a5da5063b2 with small fix in ecc7c3fb01097d29ae1fb610304e25474a95187e

Note that I moved the Initialcost section below the Access section within the way context, as now the former is referencing the latter and must be below it.

LeopoldKellers commented 7 years ago

Finally found some time again to play around with this. Thanks a lot for your effort, the proposed solution looks good to me! Generally now, even without the stricter penalization in the tandem mode the template profile seems to route less aggressively through pedestrian precincts within city centres than it used to.