Consolidate no_thru & destination_only

[nilsnolde]

We talked about it before: no_thru & destination_only are really the same thing, especially after #3812. We can't (sanely) re-purpose the bit in the tiles I think, but we could at least slate it for removal in v4. Personally I'd vote to keep the name not_thru, I find it more descriptive than destination_only.

[dnesbitt61]

Do you mean not_thru? These flags are populated by searching the graph to see if graph expansion stops (exhausted) when expanding edges but disallowing expansion using the opposing edge. This would mean there is only 1 entrance/exit to access edges beyond the not_thru edge. We use these to prune graph expansions (bidirectional) that might enter such regions.

Destination only is used when OSM tags specify a way should not be used unless required to get to a destination. This can be different than not_thru since there may be more than one entrance/exit to edges marked as private (or other tags that generate the destination only marking of an edge).

I do not think it makes sense to consolidate these.

[nilsnolde]

Sure, both are determined very differently, but semantically they seem very close, if not identical, at least after #3812. Both signal that we'd rather not enter it in the middle of an expansion but have no problem starting the expansion on top of destonly or inside a not_thru area.

For bidir A* it wouldn't make much of a difference (I think), we prune the branch trying to enter such a region full of not_thrus/destonlys, but we allow expansion from such an edge. And then we could also disallow destonly edges in unidir A* if none of the correlated destination edges is destonly/not_thru, as now we could be sure that all edges inside a private area are marked as such.

Does that make sense or I'm misunderstanding smth?

[nilsnolde]

Hm, maybe for bike/ped it does make a difference whether it's not_thru or destonly.. they don't care about destonly but still want to avoid those private areas.

[nilsnolde]

The middle way could be to mark all edges inside those private areas as destonly but keep the no_thru marking of the entrance edge.. that's not really "consolidating", more a detail for #3812 . still, we could somewhat improve how unidir a* handles destonly.