-
Notifications
You must be signed in to change notification settings - Fork 435
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
Buffer has unexpected boundary artifacts #866
Comments
Yes, the buffer boundary artifacts are probably caused by a robustness bug in the buffer code. Are you using the endcap=FLAT parameter? |
One thing I notice in the sample data is that the gaps are all narrow holes. So in this case at least you can just drop the holes and have a clean result. Removing narrow holesTo make this a robust workflow you may want to remove only "narrow" holes. There a few heuristics you can use to determine this. This GIS-Stack Exchange post has some good suggestions for how to detect narrow polygons. (It's PostGIS-focussed, but the same techniques can be used with JTS). In particular:
Removing GoresDo you also have cases where the outer shell contains narrow "gores"? In this case, the brand new If you have sample data with gores, can you share some of that? And if you try the Note: I see now that the |
Another idea to remove gores (and spikes): use the |
First of all, thank you for all the comments - they are immensely useful.
We are not specifying cap style explicitly. We are using
Yes, in our case we can have both narrow holes and gores. One such case that has both holes and a gore:
We hope to soon experiment with some of the options you outlined, will share the results then.
Sure, if additional samples would be useful, we could try to generate some. What format would work best? A text file with one polygon in WKT per line? |
Good to hear. Note that I have just made a change to the As for additional examples, a WKT test file with one geometry per line is perfect. |
Thanks for the additional examples. From the sample I've tried it looks like removing small holes and then using PolygonHull on the shell with a very small area ratio tolerance (say 0.001) removes all the unwanted artifacts.
|
In 100+ cases
In addition, to generate hull of set of polygons we've used
|
Yes, that case requires a larger |
This does not remove holes from the input polygons. Is that what you are seeing? Perhaps it should do this.
This is actually the expected result. The problem is that on one side of the narrow gap there is no vertex to match to the other side, so the triangle actually has a very long side and so is not included in the result. I'm thinking about how best to address this. Possibly by snapping or introducing a vertex. It's also possible that |
I was expecting holes to be removed from polygons, but they weren't. Not a big deal, we used
|
(Somewhat related to the original issue) @dr-jts I wanted to share one more test case related to negative buffer operation and high precision coordinates. Input polygon looks like this: A small negative buffer makes the polygon disappear in this case:
Reducing the precision slightly before performing the buffer operation makes it produce the expected result. |
The |
That is actually intended - we want the The same buffer operation can be expressed like this for 1.19.0 (producing the same empty result):
Using |
Context:
![image](https://user-images.githubusercontent.com/8446128/166912479-652abfff-c28a-4c7b-9363-8c664e0fec01.png)
We are taking a 3D model of a residential building's roof faces and doing a union of all of them to end up with the building's outline.
For example, this building has 15 roof faces:
However, there the 3D models that we get are not perfect - there may be tiny gaps / overlaps between adjacent roof faces.
Our current logic is to perform the following:
DouglasPeuckerSimplifier
to remove collinear pointsThe result of step 1 for the example building produces such polygon:
Then we inflate it like this:
![image](https://user-images.githubusercontent.com/8446128/166913742-9b7692e0-cdf2-43c0-a784-801171f02821.png)
resultFromStep1.buffer(0.7988331909277314, -10)
and get this result:The extrusion in the top-right corner is not expected.
Changing the second parameter seems to change the shape of it - either make it wider or longer
The reason why we noticed it was that after deflating (using the same buffering parameters and negative distance) a very narrow pointy section is not simplified away:
![image](https://user-images.githubusercontent.com/8446128/166913943-5c6e9d14-0f94-49d6-bc04-de5c0402c9a7.png)
Everything works fine if we reduce the precision after performing the union operation.
JTS version: 1.18.2 with OverlayNG enabled.
Looking at the open issues, #739 seems somewhat similar - maybe they are related?
The text was updated successfully, but these errors were encountered: