-
Notifications
You must be signed in to change notification settings - Fork 17
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
Type stable calc extent #98
Conversation
This looks nice! Can we add a test for the type stability (or hit the missing coverage)? |
Its a small union optimisation, so its not guaranteed to be inferred, just fast. I'll try to get the code coverage up |
@evetion this is good to go if you could approve, coverage is passing (needs a squash and cleanup rather than merge tho) |
Extent(; X, Y) | ||
end | ||
end | ||
calc_extent(t::GeometryCollectionTrait, geom) = reduce(Extents.union, (extent(f) for f in getgeom(t, geom))) |
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.
pedantry: note that we call extent
(and thus accept pre-calculated extents) for multigeoms instead of calling calc_extent
(recalculating everything). Old behaviour and quite pragmatic, but it might be slightly unexpected.
@asinghvi17 hit some very slow code with Rasters.jl and GeometryBasics.jl where I had forgotten to use
fallbacks=false
.But it seems it can be a lot faster by using
is3d
to in worst case get small union optimisations (but mostly compiled away), getting the extrema over all points in a geometry in one pass, and avoiding collecting points or makingNamedTuple
at the leaf nodes of the geometry.