-
Notifications
You must be signed in to change notification settings - Fork 25
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
Read a polygon with a hole from a ShapeFile #80
base: develop
Are you sure you want to change the base?
Conversation
from Shapefile specs, page 8-9
so basically testing for rings CW and CCW orientation is the correct way of doing things. |
…hat are not inside any shell, due mainly to invalid inputs with shell and holes not correctly oriented - as separate shells
The
The idea of this PR is to let the |
Does one polygon contain the other? In that case the result would be invalid. |
Yep, exactly (made explicit in the unit test). I see few different strategies:
I'm open to suggestions :) |
@DGuidi , I think we should
I think the PR I pointed you to yesterday does it in a similar way. |
|
when a potential hole of a shell is found, we check also the shell holes, to see if any hole contains potential hole. If so, the potential hole can not be considered a hole for the shell, but a separate geometry.
@FObermaier I slightly changed the logic. |
@FObermaier any advice on this? |
I actually don't quite know how to proceed. There are complaints that current ShapeFile implementation is (dreadfully) slow. That is why I pointed you to the WIP/redo everyting PR. If we do thorough topology test on the rings we read, I assume it gets even worse. Maybe we can enable the thorough test conditionally, if the user of the library really wants it? |
Actually, I have the same feeling: with the "new" polygon builder logic all the tests are green, but I fear that some behavior not covered by some test can be broken.
that shows the same problem, actually
the "new" polygon builder logic I think is similar to the older one, in the sense that I didn't expected to be too much slower. But actually this is just a feeling, I haven't tried no comparison tests
I can work on it: a flag can be helpful also to build some performance test my2cents |
TODO: flag needs to be handled differently, suggestions well accepted
@FObermaier added a "temporary" static property as a flag, I need to think a bit better about how to manage the entire "flag" thing... suggestions are welcome! after a brief inspection: adding a flag property to the viable, not so complicated at all, maybe acceptable for an "experiment", but I hope to find a better alternative |
…nce checks (not good vibes...)
but actually - based on some poor-man's performance tests - it's much (~3X) slower
|
Added 2 more variants to build the polygons. * Sequential Assumes that polygons are always serialized `shell[, holes][, shell[, holes][, ...]]` and thus starts a new polygon when the current ring is not contained by the current polygon. This is slightly faster than the current default implementation. * UsePolygonizer Throws all rings at the `NetTopologySuite.Operations.Polygonize.Polygonizer` and lets it build the polygon. This is really slow.
just a small note: tests marked as |
AFAIK |
In GDAL/OGR shapefile driver, all rings are converted to I have not bisected the algorithm altogether, but it seems to be a bit of everything... |
exactly what happens to me |
maybe we can refactor this check to speed up a bit the computation:
|
I'd assume that without the cheap envelope precondition test we'll see a performance degeneration. |
I just mean that |
I got that, but |
yep now I see your point. curiously, from performance tests I see performance improvements |
If you only have polygons with holes that might be true, but for multipolygons whose shell ring envelopes don't intersect, I doubt that. |
can be this PR cancelled, considering the discussion in #81, and in particular this comment ? Maybe part of this work can be added to #69 , if worthy |
To investigate #70