Assertion `!hasTurnType(steps.front()) && !hasTurnType(steps.back())' failed.

[woodpeck]

I am running 560ed5c on a planet-wide dataset with CH and the car profile, and there is one specific, but innocent-looking routing request (with steps=true&geometries=polyline&overview=full) that consistently triggers the above assertion (in /src/engine/guidance/collapse_turns.cpp:594).

I am presently debugging this further and will report findings.

[woodpeck]

I was able to isolate and reproduce the problem. It occurs when an OSM data extract of the region 8.561,49.8,8.627,49.875 (near Darmstadt, Hesse, Germany) is prepared with CH and a route is then requested like this: /route/v1/driving/8.596111,49.860439;8.59682,49.85312?steps=true

The .osm.pbf of this area is available at http://www.remote.org/frederik/tmp/osrm-issue7287-broken.osm.pbf.

The problem does not occur if ?steps=true is omitted from the request. The problem also does not occur if the 7 "type=manoeuvre" relations that are contained in this data set are removed before processing. All of these 7 relations share the following characteristics: type=manoeuvre, manoeuvre=fork, direction=slight_right or slight_left, and they all have one way member in the to and from roles and one node member in the via role.

The .osm.pbf file of the same area with these relations removed, that does not exhibit the problem, is available at http://www.remote.org/frederik/tmp/osrm-issue7287-working.osm.pbf.

I am unable to debug this further but I hope that someone with more OSRM experience than I have will be able to use my findings. I will now go ahead and try to paper over the exception in osrm-routed so that it somehow handles this gracefully rather than dying altogether ;)

[woodpeck]

The problem can be papered over with woodpeck@f36ba3b - this is not a real fix but it won't make the process abort just because it can't properly describe a route.