perf(fastisochrones): apply modifications from regular isochrones

[aoles]

Pull Request Checklist

• 1. I have rebased the latest version of the main 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.

Information about the changes

Build- and query-time optimizations based on the previous work on regular isochrones in #1607:

• Replace concave hull algorithm with JTS implementation
• Do not perform neighbor search when adding new elements to the point cloud, both for preparation and for query
• Reduce splitting length according to splitting factor
• Avoid unnecessary edge splitting in fully reachable and active cells

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

Changes to isochrone geometries in API tests (blue is reference, red is new)

testIntersections

testPolygon

testSmoothing

[aoles]

Comprehensive assessment of the changes introduced by this PR:

• Performance benchmark
• Modifications to geometries
• Detailed analysis of geometry modifications based on notorious location 7

To summarize, changes introduced to the preparation part (constructing cell geometries) doesn't seem to have much impact on the overall performance, neither the actual build times, nor the query times. Some small differences in the resulting geometries are observed after switching the algorithm from ConcaveHullOpenSphere to JTS ConcaveHull. The actual performance gain comes from adapting the query time optimizations:

• removing neighbor search
• and reducing the splitting length based on the smoothing factor

each of which individually improves the performance by around 18% and 17%, respectively. The combined performance gain introduced by this PR is around 33%.

Last but not least, there now seem to be a better overlap with the geometries produced by regular isochrones.

[sfendrich]

Just a few minor questions.

[sfendrich]

LGTM! Thank you!