-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf(isochrones): improve isochrones performance #1607
Conversation
1265275
to
d0c4593
Compare
Some preliminary benchmarks are available here. Compared to the current master branch it looks quite promising. Apart from faster query times, the produced geometries seem to be more accurate as well. In particular, there seem to be less artifacts around long highway stretches. |
Hi @aoles - the test combinationsAsGeojsonFiles was only a means to write isochrones results to files to make them visually comparable after code changes. But I think, the test could/should now be removed or at least |
0f58403
to
238d93c
Compare
A comprehensive benchmark of 60 min car isochrones split into 3, 6, and 9 intervals across 100 locations in the DACH region suggests an average performance gain of around 25%. Additionally, there seem to be an overall improvement to the geometries. Consider the following examples, where
|
238d93c
to
cfec678
Compare
Replacing `ConcaveHullOpenSphere` with jts own `ConcaveHull` algorithm
Removing nearest neighbour search for rejecting isochrone point-cloud.
…actors Removing nearest neighbour search for rejecting isochrone point-cloud.
Removing nearest neighbour search for rejecting isochrone point-cloud.
cfec678
to
3d76075
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Replacing
ConcaveHullOpenSphere
with jts ownConcaveHull
algorithmPull Request Checklist
have been resolved.
[Unreleased] heading.
along with a short description of what it is for, and documented this in the Pull Request (below).
(at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
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.
and why the change was needed.
Fixes #1573.
Information about the changes
Examples and reasons for differences between live ORS routes, and those generated from this pull request
Required changes to ors config (if applicable)