-
Notifications
You must be signed in to change notification settings - Fork 347
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
Improve performance of unary union for many short lines #213
Conversation
That makes sense. And could help in some cases - but only ones where there is a fair degree of locality in the line set. And ultimately it's not possible to improve intersection computation to the point where noding will be fully robust, because it's not possible to correctly represent all intersections of lines with DP endpoints using DP values. Hence the need for some kind of snapping approach. |
|
Just to be clear, am I right in thinking that this enhancement does not eliminate the possibility that Unary Union will encounter a case which has extremely slow performance? There could be a pathlogical case which contains a noding failure, drops through to Cascaded Union, and then runs very slowly. |
|
Correct, although it still improves performance in the event that a cascaded union is run. |
|
Failing test is |
|
@dr-jts I'm tempted to just change the expected result of |
Can you look at both outputs in the JTS TestBuilder and see where the differences are? The latest TestBuilder includes a Diff.diffSegments function which can help here. Also check that the noding is correct - can use the Noding.findNodePoints function to display nodes (intersections) in the linework. The output should really be fully noded. |
|
I can't build the latest TestBuilder at the moment...I'm certain it's something on my end. Noding.findNodePoints returns |
|
I looked at the two geometries in the TestBuilder. They look very, very close.. Unfortunately the TestBuilder doesn't expose the |
Improves segment unary union perf test by 45%.
Improves performance of segment unary union benchmark by 85%.
- Change two tests to use GEOSEquals instead of WKT comparison, so as not to be sensitive to component ordering. - Change two tests to expect that the union of LINESTRING EMPTY is LINESTRING EMPTY, instead of GEOMETRYCOLLECTION EMPTY. This is consistent with JTS, as with how other types are handled.
Bypassing cascaded union of lines produces a different but still-correct result.
Doxygen is apparently unable to resolve the references to an enum class.
This PR adds a benchmark for the case of unioning many line segments through unary union, and then improves the performance of that benchmark by roughly 90-95% for the case of 200 lines.