-
Notifications
You must be signed in to change notification settings - Fork 260
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
OGCGeometry#union of geometries of different dimensions is incorrect #177
Comments
@mbasmanova The first part of the issue - union of geometries of different type it is similar to the #176. The OGC union delegates to the Esri Operator_union and it produces geometry of highest common dimension only. While the second part (extra vertices), this is something that should not happen in this case, and I'll take a look. |
@mbasmanova I've made this test case, and it passes (no extra vertices). Could you modify it to make it fail?
|
@stolstov Here you go:
BTW, I'm using |
@mbasmanova That's not a bug. Those vertices are result of intersection of the input geometries. They will stay in the output. |
@stolstov Sergey, thanks for clarifying. Just to double check, are you saying that even though in this case one geometry is fully contained in the other geometry, we can expect the result to be having extra vertexes (e.g. 3+ consecutive vertexes on the same line)? |
Yes. First step of the overlay algorithm is to split all segments at intersections. Those vertices are not removed explicitly. |
@stolstov Thanks for explaining. I don't know yet whether this will become a problem, but overall extra vertexes use extra space in both memory and disk and require more CPU for relationship checks (contains, intersects, etc.). If we needed to remove the redundant vertexes, is there a way to do that? I'm also seeing union of |
have you seen the |
@mbasmanova The asText method does not round. Those numbers are due to floating point calculations. The OperatorExportToWKT allows rounding though (see WktExportFlags.java), but OGCGeometry.asText does not have the control. |
@jgravois John, I haven't seen |
We also use the term 'simple' to describe topologically correct geometries. Simplify - checks (and corrects for) topological validity. because |
@mbasmanova Could you verify? |
@stolstov Sergey, the PR includes tests for the new functionality. What else needs to be done for verification? |
@mbasmanova Nothing else, unless you would like to do more verification. |
@stolstov The tests in the PR cover test cases I had in mind. I don't have anything else to add at this point. |
@mbasmanova Thank you Maria! |
I'm seeing incorrect results when calling
OGCGeometry#union
on geometries of different dimensions, e.g. point and linestring, linestring and polygon, etc.For example, the following tests
fail with
I'm also seeing union of
POLYGON ((0 0, 1 1, 0 1, 0 0))
andPOLYGON ((0.5 0.5, 0.7 0.7, 0.5 0.7, 0.5 0.5))
beingPOLYGON ((0.7 0.7, 1 1, 0 1, 0 0, 0.5 0.5, 0.7 0.7))
and notPOLYGON ((0 0, 1 1, 0 1, 0 0))
. The shapes are the same, but union result has redundant points. Is this expected?The text was updated successfully, but these errors were encountered: