LinkingTest.testSplitting intermittent failure

[miklcct]

Expected behavior

The test should always pass

Observed behavior

The test sometimes fails. The result when it fails is below.

[ERROR] Failures: 
[ERROR]   LinkingTest.testSplitting:98 expected: <136625.227> but was: <136625.226>

Version of OTP used (exact commit hash or JAR name)

2.7.0-SNAPSHOT

Data sets in use (links to GTFS and OSM PBF files)

irrelevant

Command line used to start OTP

irrelevant

Router config and graph build config JSON

irrelevant

Steps to reproduce the problem

Run mvn build

[optionsome]

You can create a pr that increases the epsilon/delta to ensure this test doesn't randomly fail and we can discuss this issue more then.

[abyrd]

Discussed in developer meeting this week: The comment just before the assertion that fails says "distances expressed internally in mm so this epsilon is plenty good enough to ensure that they have the same values". The epsilon in question is 0.0000001 on a value expressed in meters, so 1/10000 of a millimeter (100 nanometers) in a context where we're operating on integer millimeters. "Good enough" here must mean "demanding enough" or "sufficiently strict", but this is perhaps overly strict considering the input data resolution.

If we had no special handling for splitting edges in opposite directions, it would clearly be expected for the beginning segment of one edge in a pair to differ by up to one millimeter from ending segment of the opposite edge in the pair, and we could bump this epsilon to 0.001.

However: in the method splitDestructively a comment explains in detail that "we have this code implemented in both directions, because splits are fudged half a millimeter when the length [...] is odd. We want to make sure the lengths of the split streets end up exactly the same as their backStreets so that if they are split again the error does not accumulate and so that the order in which they are split does not matter." These are good points. Streets are often split recursively, and the split points may be applied in an arbitrary order as they arrive from some unordered collection.

So given that there are already separate forward and backward split implementations to ensure exact equality at millimeter precision, I'd suggest we test equality at one order of magnitude immediately beyond millimeter (0.0001). If we still see failures using that epsilon value, then there probably is a genuine bug.