Add support for multi via-way restrictions

[lukasalexanderweber]

Follow up to #2689:

With the existing approach for single via way restrictions, multi via ways should become quite trivial:

  a   b   c   d
0---1---2---3---4

  a  /--b--\ /--c -\  d
0---1       2       3---4
     \--b'-/ \--c'-/

A restriction a via b via c to d is modeled as restrictions

1. a via 1 to b (so the route must procceed on artificial b')
2. b' via 2 to c (so when being on a artificial edge we can't go back to the original graph) NEW
3. c' via 3 to d (so we can't reach d when coming from a)

using b and c, we can reach d trough other edges crossing at 1 or 2

---

I checked some real life examples from the via way restriction gist which all worked as expected:

1747816, 2063168, 2063172, 2081739, 2896789, 4497772, 4498302

One thing I noticed for only restrictions (e.g. 4498302) is that the route becomes wrong if it ends within a (multi) via way restriction (same as OSRM). If it goes all the way to the end of the restriction it works perfectly fine.

[lukasalexanderweber]

I've added another test to show when this approach does not work:

      a   b   c   d
    0---1---2---3---4
        |e  |f
        5   6

with the restrictions e via b to f and a via b via c to d.

when turning right from e, we'll be detoured on b'. However, we cannot reach d due to b' via 2 to c and c' via 3 to d of the second restriction. We should actually be able to reach d from e.

On the other hand, we can not reach f from a since b' via 2 to f is restricted by the first restriction.

SUMMARY

The presented approach will fail if a via way of a multi-via-way-restriction is already in use by another via-way-restriction. I tested that this is the case in 115 of 150 multi-via-way-restrictions in germany.

@easbar we already have the need of multiple artificial edges for overlapping ONLY restrictions. Do you think we should go in this direction or have you any concerns introducing them?

[easbar]

Thanks for continuing with this. I won't be able to properly review this this year, but will definitely pick up on this afterwards.

Do you think we should go in this direction or have you any concerns introducing them?

I don't think introducing multiple such edges introduces conceptually new problems compared to using just one such edge, so I would not try to avoid this at all costs. However, I'd like to be able to tell whether an edge is an artificial one and which original edge it belongs to. Imagine you wanted to block a certain road after the OSM import. You'd have to know if there is a (or if there are any) artificial duplicates that also need to be blocked.
One possibility to identify artificial edges would be sharing the pointer to the edge's geometry. Currently we store the geometry of an edge (the nodes lying between the tower nodes) separately from the edge data. When we create an artificial copy we simply copy the geometry as well. But if we simply pointed to the existing geometry entry of the original edge we would be able to tell one is a copy of the other by simply checking if the pointers (I mean the index into the geometry storage) are the same. And we would safe a little bit of memory as well, but that is not the main point here.
So for any edge we could use an edge iterator at one of the two tower nodes and see if there is another edge with the same geometry pointer and this would even work if there were multiple artificial edges.
It could also be useful to use one bit of edge flags for a true/false value that tells us if an edge is artificial. This way we would not be able to find the corresponding original/artificial edge, but for example we could use this to avoid snapping to an artificial edge. For the case of single via way edges it seems like we got away without such a check though.

Btw the single via-way restrictions are now live on graphhopper.com/maps and so far I heard no complaints :)

[easbar]

The presented approach will fail if a via way of a multi-via-way-restriction is already in use by another via-way-restriction. I tested that this is the case in 115 of 150 multi-via-way-restrictions in germany.

This is also the case for single via-way restrictions: #2907, and not only for the 'only' restrictions which we already ignore.