-
Notifications
You must be signed in to change notification settings - Fork 5
add DimensionalData extension #178
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
base: main
Are you sure you want to change the base?
Conversation
ext/GeometryOpsDimensionalDataExt/GeometryOpsDimensionalDataExt.jl
Outdated
Show resolved
Hide resolved
import GeometryOps as GO | ||
import GeoInterface as GI | ||
|
||
function GO.polygonize(A::DD.AbstractDimArray; dims=(DD.X(), DD.Y()), crs=GI.crs(A), kw...) |
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.
What happens with the dims that aren't given (time etc)?
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.
Yeah I haven't done that yet, this should be WIP.
But I image we make a feature collection with a feature for each slice, and put the lookup values as properties?
Otherwise return a DimArray of geoms of the remaining dimensions ?
Probably a single feature collection or table is most useful?
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.
Actually this is a case for R style vector data cubes.
But we can just broadcast over the other dimensions and get a DimArray of X/Y geometries with time/etc dimensions.
We should be able to write that directly as a FeatureCollection with GeoJSON/ArchGDAL/Shapefile without any more work as long as we name the array :geometry
.
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.
Do we then want to add an assert here that the dims can only have length 2?
Does that last commit set minimum version to Julia 1.10 instead of 1.9? |
Oops wrong commit message, we can fix it in the squash |
Is this just waiting on the datacube stuff/implementation? |
Waiting for me to have time 😭 |
bounds_vecs = if DD.isintervals(lookups) | ||
map(DD.intervalbounds, lookups) | ||
else | ||
@warn "`polygonsize` is not possible for `Points` sampling, as polygons cover space by definition. Treating as `Intervals`, but this may not be appropriate" |
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.
Doesn't this just mean that the ring vertices are located at the points? That seems pretty exact...
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.
Hmm not sure I understand you. It's just saying that points don't cover any space so polygonizing them doesn't make sense
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.
I was thinking of it more in a sense that the polygonizing operation is the concave hull of the set of points that satisfy f
...but that is also probably a different algorithm!
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.
Yeah, somehing else! polygonize
is like a groupby/combine for lots of little square polygons
This adds a DD extension for
polygonize
so that any DD array can be polygonized with X/Y (or custom withdims
keyword) lookup values.