ignore hgv=no on second pass via costing option

[nilsnolde]

it's fairly common that hgv=no is tagged on a road, e.g. in inner cities, but certain companies have a legal permit to enter anyways. it's similar to hgv=permit but currently we handle that the same as hgv=private which is fine, that's a hardly used tag anyways and would make such an option data-driven when there's actually no such data. instead I'd propose to make it a costing option, e.g. ignore_truck_access which would switch a truck's access mask to a car's access mask (not sure if possible in code, but smth like that). we already have a ignore_restrictions flag, but that's for all other restrictions (turn, dimensions etc), not base access. (see below, we also have ignore_access)

also smth we could just turn on in a second pass.

I think that would help logistics companies a lot. any opinions on this?

[nilsnolde]

Ha, we do have ignore_access as costing option (really gotta get the docs in order..). It's doing too much though for the use case described above: it just cares if any mode has access and if so, it grants the current mode access. so we'd go down ped/bike paths, ignore bollards etc.

[nilsnolde]

Talking about it again offline, that might not be the best option. If we'd pretend car access on a second pass with such an option, an HGV would of course also take edges in the middle of the route which are hgv=no, not just start/end, which is not desirable.

Another option: a costing option hgv_access_penalty or so which optionally penalizes hgv=no edges but doesn't prohibit them (defaulting to prohibiting them of course).

Ideally we wouldn't apply such a penalty for correlated edges so that we don't get too imbalanced in the forward/reverse trees (one tree starting in an inner city full of such edges, the other close to highways), and also not too imbalanced in between correlated edges for a single location (with a radius set, where one edge might have hgv=no, another might not). If such a costing option is set, the intent is clear that it's fine to take hgv=no so starting/ending a leg ideally shouldn't be extra penalized, only edges encountered after having the first hgv=yes should be penalized as such (similar to no_thru). However, that's quite a lot more impact on the algorithms for a fairly niche use case.

Any opinions on this?

[radekvermirovsky]

That would be greatly appreciated for our use case. We encounter many scenarios where our goal is to adhere to truck restrictions as much as possible. However, in cases where no alternative exists, we accept breaking restriction on edge to find a route at any cost. The 'hgv_access_penalty' appears to be precisely what would solve this issue. It would be a significant improvement over falling back to car mode routing, as it attempts to respect restrictions wherever possible, and only break it on edges where is no other choice. So, +1 from me

[nilsnolde]

leaving again the outcome of our discussion on this topic:

generally the (latest) proposal is fine (i.e. adding a penalty), but we need to make sure that by default we're retaining current behavior, i.e. do the gymnastics to turn this new penalty into a hard hgv=no.

also, we really do want the same behavior as no_thru, meaning we only penalize hgv=no edges after we've expanded on the first hgv=yes edge. that may be right at the expansion's beginning (if our location's correlated edge is hgv=yes) or once the expansion got out of a zone of hgv=no. that would already be enough in theory and we wouldn't need any penalization at all. however, that'd assume that there's no such thing as an "island" hgv=yes inside a bigger region of only hgv=no around. so I'd still do the penalty thing just to be sure.

last thing: I vowed to review our entire current logic for this no_thru kinda logic. this issue would be the 4th custom attribute which needs this general concept of allowing smth just at the beginning of the expansion, but prohibiting/penalizing it otherwise. from our memory the others are no_thru, dest_only, closures and now this. ideally we'd have a place in dynamiccost which abstracts this concept and can be toggled for various attributes by costing option. right now it's all custom coded in each algorithm and, of course, not all algorithms are handling all those attributes equally which is awful.

I'll spend a few hours on seeing if such an abstraction could work in a sane way, in case I should actually work on this anytime soon.