Some thoughts on conditional rules

[afischerdev]

This is a topic that comes up again and again. Here is a workaround for a 'conditional lite' version.

Most definitions of *:conditional tags refer to a temporal context, for example:

no @ (Nov - May)
no @ (Nov 1 - May 15)
no @ (18:00-07:00)
no @ (Mon-Sun 18:00-07:00)

Now BRouter cannot do time-controlled routing. Conditional statements with times are therefore not possible. On the other hand, the rd5 data is generated every day. A date could therefore very well be taken into account. A path that is currently closed from November to May, is wrong on seven months a year. On lazy rd5 update handling (once a month) it is only wrong on 2 months.

A test class and a small condition handler were created for these long-term rules.

This will need some new rules.

In the lookups.dat, e.g.

access;0000319927 yes
access;0000144799 no
access:conditional;0000000001 *

The conditional rule must follow the plain rules and it can only have values that are defined in the plain rules. When the conditional rules it active the plain values is changed to value specified by the conditional rule.

Result from sample test class:

access=no access:conditional=no 
foot=yes foot:conditional=yes 
bicycle=yes bicycle:conditional=no 

The access is active so set to no The foot is not present in data but set on conditional rule active The bicycle is not active, so it has its origin value

As you see the presentation is very small, you only see there is a conditional rule and the result of the rule. But you don't see the used dates. This brings a very small data use in rd5 tile - only the conditional value index is saved.

This is a very lite version, but it involves very little data consumption and no changes to the profiles. The biggest issue is the dependency on changes to lookups.dat - please note the pending changes at #458

Playground at my repo

[poutnikl]

It may be a good idea, but some things must be well thought through, and even cooperation with routing application developers may be needed.

I see two issues with time conditional access:

Date issue: Some users prepare navigation tracks in advance, like in application planners or downloaded as GPX from BRouter web. It may happen that routing across a segment with conditional access is allowed/available at the date of route generation, but not at the date of the following.

Time issue: Similarly, if there are opening hours, the routing through may be possible at the route generation time, but not at the time when you arrive at the affected segment.

The same for vice versa, routing through seems not possible at route generation time, but would be when arriving there.

It should not be a big problem if the user is aware of such conditional access. But in majority of cases users are not aware about the field conditions and there could be a big surprise....

[devemux86]

Another approach is a switch on / off of these restrictions, so users can prepare their routes regardless of date / time.

But include information about these restrictions in the route response, so that apps can inform the users about them.

[afischerdev]

@poutnikl

Date issue: Some users prepare navigation tracks in advance

Yes, that is exact what we have at the moment: planning in summer for winter on a way tagged no @ (Nov - May) delivers wrong result for the winter. With the condition lite variante there is the same wrong result for summer planning. But you get a better result when your planning date comes nearer to the condition date.

Time issue: ...

There is no time-based routing in this variante, sorry.

@devemux86 Please note: the info access=no and access:conditional=no give you the chance to ignore this in profile.

[poutnikl]

Date/Time issues - I mentioned it rather as a general problem to address for any routing, regardless of if or how the routing tries to address it. I do agree the date interval base conditional access is an important step to address it.