Support for access:conditional

[arminus]

I would be nice if brouter would support the access:conditional tag. This tag is rather important when observing restrictions inside protection areas (one example are the German Wald- und Wild Schongebiete).

Typically, these areas are not rendered in standard map tiles, users build there routes and end up in areas they are not supposed to be at a given time, claiming that some app, probably bases on OSM "has sent them there without warnings".

One solution to this would be to at least pop up a user-friendly warning when a route is created, e.g. in brouter's web frontend and otherwise make the access information fully available in brouter's API so that other apps can pick it up, too. Typical values for that tag are discouraged or no with the respective timerange information as per the opening hours spec.

I haven't checked if access:conditional does not appear in brouter at all, but access:conditional: discouraged @ (Dec-May) - of which we have ~ 620 in Southern Bavaria alone at this time (amount growing) - does not appear at all in the web frontend's route data table way tags.

[poutnikl]

I bet there would be difficult implementation problem for coding it to RD5 files, and then evaluting them during route generation and real time route following. As it has highly variable syntax of the tag values. BRouter naturally prefers a list of enumerated tagvalues, often limited to the most frequent or grouped similar ones. Some tags have dozens or possibly even hundreds of possible values, often with just 1 of few usages.

If there is time conditional restriction, it may be allowed at the time the route is calculated, but forbidden when the route is followed. Or vice versa. Other issue can be circumstanced or trave mode related restrictions.

[abrensch]

I had some thoughts on conditional restrictions a while ago: #193

however, that's the general case including intraday-changes

conditions on a seasonal timeline could be processed at the preprocessor-level, which is much simpler. But still not high on the priority list currently

[arminus]

I'm not saying the values need to be parsed and interpreted necessarily. After all, I might create a route in winter but actually use it in summer when the condition no longer applies.

But IMHO the user should be made aware at the time of route creation that there are some restrictions on a route. It could be left to the client on what to do with the actual values (just display them or interpret them somehow). Komoot for instance pops up a generic warning.

According to taginfo, access:conditional ion ways is used 21029 times right now...

[polyscias]

But IMHO the user should be made aware at the time of route creation that there are some restrictions on a route. It could be left to the client on what to do with the actual values (just display them or interpret them somehow). Komoot for instance pops up a generic warning.

Yes, that is I think a good idea that can be implemented with less effort than handling it within the brouter App.

It would be nice if also the OSM way/node id for the restriction is given. With that information for example brouter-web could retrieve those ways/nodes and present the user with the list of conditional restrictions to evaluate.

[polyscias]

Had a look on this again in the light of #416.

First though was to encode :conditional=, i.e. all conditional keys with all possible values. First I realized that there is also "maxspeed:conditional" etc., so restriction on access/transport keys and then I had a look at Taginfo keys and filtered on ":conditional", tagged 318198 times on 20220410

The top 10:

key                             count  fraction
maxspeed:hgv:conditional        59814   18.8%
maxspeed:conditional            59513   18.7%
access:conditional              30072   9.5%
motor_vehicle:conditional       21731   6.8%
maxweight:conditional           17164   5.4%
maxspeed:psv:conditional        10995   3.5%
restriction:conditional         10196   3.2%
hgv:conditional                  9076   2.9%
foot:conditional                 8126   2.6%
bicycle:conditional              7748   2.4%
overtaking:hgv:conditional       6790   2.1%
vehicle:conditional              5616   1.8%

So, yes, filtering on access/transport is needed.

Filtering on access/transport and splitting out ways/nodes you get (top 25):

key                                   ways  nodes
access:conditional                   25988   3857
motor_vehicle:conditional            20784    877
hgv:conditional                       9015     50
foot:conditional                      7839    285
bicycle:conditional                   7300    394
vehicle:conditional                   5476    112
motorcycle:conditional                2965     77
goods:conditional                     1413     25
motorcar:conditional                   757    115
bus:conditional                        746     29
hov:conditional                        559      1
mofa:conditional                       429      1
moped:conditional                      422      7
hazmat:conditional                     398      0
horse:conditional                      383     12
taxi:conditional                       327      5
psv:conditional                        328      0
agricultural:conditional               302      1
atv:conditional                        276      0
motor_vehicle:forward:conditional      261      3
tourist_bus:conditional                248      5
motor_vehicle:backward:conditional     244      0
hgv:forward:conditional                237      0
coach:conditional                      193      4
hgv:backward:conditional               162      0
motorhome:conditional                  146      1

I would propose to take into account:

1. access
2. motor_vehicle
3. hgv
4. foot
5. bicycle
6. motorcycle
7. motorcar