Barrier edge leads to near-infinity value of average_speed

[karussell]

The problem is that the distance of these barriers is 0 (The point is a lift_gate: https://www.openstreetmap.org/node/9664334304 )

See https://discuss.graphhopper.com/t/wrong-average-speed/7411

Related #2620.

[otbutz]

Just a quick thought but can't we fix those values in a postprocessing step by replacing them with fitting values from adjacent edges?

[easbar]

I think @karussell meant the average_speed path detail here, which is not stored for each edge, because it depends on the weighting that is used. So it is calculated as distance / weighting.calcEdgeMillis(edge), and since calcEdgeMillis is typically proportional to the distance (which is zero) we divide by some small number. But yes, maybe we could just use the resulting path detail value of some neighboring edge in this case. Or just do the same as we do when the distance is too small also when calcEdgeMillis is too small...

[karussell]

The tricky thing in the case above is that the elevation interpolation for ferries, tunnels and bridges rewrites the distances. And if the barrier edge is involved in this interpolation the distance might increase e.g. only one node is lifted, then the distance increases, in this specific case it increases to 0.011m but the ETA for this edge is 0.

It might be a bug or limitation in the interpolation code as the distance to the next node should be considered to know the value for the elevation change and a distance of 0 should either not change the elevation or change the elevation for both nodes (?)

For now I'll fix the problem as @easbar suggested: do the same for the same like we do when the distance is too small.