`preferred_side` as cost/penalty?

[chrstnbwnkl]

Currently the per location parameter preferred_side works as a soft filter, meaning candidate edges that don't comply with it are marked as filtered edges and are only used in a second pass (at least for route; for matrix, they are not used at all currently but that's another story).

In some situations this is a bit harsh I think. It may be inconvenient to start/end the route at the "wrong" side of the street, but not so much that a route starting/ending there is entirely unusable (especially if the alternative is multiple times longer).

I think it would be helpful to additionally have something like a preferred_side_{cost, penalty} that gets applied to origin/destination edges in the algorithms. Not sure yet where/how this would be best implemented, intuitively it feels like a special case of DynamicCost::EdgeCost that only applies to candidate edges.

[mcmasterp]

I would like to always arrive with the destination on my right unless it's absolutely impossible like a dead end etc.

[kevinkreiser]

sometimes there are doubly digitized roads, a road that has two carriage ways and each has a one way. the reason we didn't make the preferred side a hard requirement was that doing so will cause lat lon input that is slightly off or slightly off digitizations of road geometries to put the start/end point of the route on the wrong road entirely. this would be easier to explain with a picture but by making it a hard requirement you can make it so that you route from/to the wrong place.

[chrstnbwnkl]

with #5584 landed, which refactors all the edge cost stuff for initial edges into DynamicCost::PartialEdgeCost, this should be much easier to implement :)