-
Notifications
You must be signed in to change notification settings - Fork 4
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
Fix polygonize #141
Fix polygonize #141
Conversation
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.
Exciting optimizations. I don't think the logic is quite there but let me know what you think about my comments.
We should propagate Edit: implemented in #143 |
With the changes from the last commit, even Rasters work with roundtripped CRS. The only thing remaining to be done is to figure out how to generate edge vectors for interval sampling, which would probably be an extension on Rasters in GeometryOps, since we're overriding an internal GO method.
Co-authored-by: Rafael Schouten <rafaelschouten@gmail.com>
Co-authored-by: Rafael Schouten <rafaelschouten@gmail.com>
I forgot to PR this months ago.
But it mostly rewites
polygonize
and uses the uglier but more practically useful exact pixel approach rather than having any angles or curves in the output. It also fixes some bugs and lets you define the contour cutoff yourself.@skygering I added a performance optimization on
coveredby
, because it a huge gain forpolygonize
.I'm not sure if that's the way to do it, it should probably go into_line_polygon_process
so its used for everything. But, there are cases where not intersecting should returntrue
and others where it should returnfalse
depending on the other arguments?Extent checks are done generically for all predicates now
Oh and this needs tests!!