perf(isochrones): Increase edge splitting threshold

[aoles]

Pull Request Checklist

• 1. I have rebased the latest version of the master branch into my feature branch and all conflicts
  have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
  [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
  along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset
  (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
  importer etc.), I have generated longer distance routes for the affected profiles with different options
  (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
  points generated from the current live ORS.
  If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage
  and why the change was needed.
• 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

• Key functionality added: 2x speedup of isochrone generation time.

• Reason for change: Setting the threshold for edge splitting to a low value slows down isochrone generation because of the increased amount of points which need to be processed when calculating the geometry. Initial benchmarks have revealed that increasing the current threshold of 20m to 200m yields acceptable results while drastically improving performance.

The edge splitting threshold has been verified by running some benchmark and assessing the results both in terms of performance and visual aspects of the generated geometries. All files are available on GitLab, while the resulting report can be viewed at RPubs.

The benchmark consisted of performing 10 isochrone queries for the car profile at 10 random locations within the DACH region. Each query requested a 60min isochrone split into 20min ranges. First, the cumulative distribution of edge distances have been gathered. This revealed that for the original threshold of 20m almost 70% of edges get split. Increasing this value 10-fold reduces the amount of splitted edges to 5% as illustrated by the following figure.

Then three scenarios have been evaluated: the original splitting of edges into 20m segments, splitting into 200m segments, and not doing any splitting at all. While the original 20m splitting introduces a significant 2-3x performance penalty, splitting based on 200m threshold is only 20% slower compared to no splitting.

Not splitting long edges may occasionally introduce weird geometrical artifacts. The following figure compares an isochrone without edge splitting (red) to one calculated with 20m splitting.

These issues are mostly resolved with the 200m threshold while keeping the computation time low.

Examples and reasons for differences between live ORS routes, and those generated from this pull request

Blue is the original isochrone geometry while the red one was generated with this PR.

[sfendrich]

LGTM!

[MichaelsJP]

@aoles Thanks for the detailed analysis on the effects of splitting. While not splitting imo is not acceptable, the balance between speed and accuracy with 200 m threshold looks good!