-
Notifications
You must be signed in to change notification settings - Fork 15
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
Grid features #16
Comments
Would it make sense to use a range instead of hand-coding the start, step, length? |
Yes. |
Thanks for bringing this up. Didn't think about this that much yet, but it seems like a good addition to this package. First we must decide what an AbstractRaster (name tbd) is, to be able to make an interface. Some points:
Does that make sense so far, what am I missing? Is there a basis that we can use for this? Would be good to at least be partly compatible with https://www.gdal.org/gdal_datamodel.html. |
I think that looks quite complete in terms of base attributes. But, is it worth thinking of But on the other hand maybe not? That distinction derives from the concrete implementation in traditional GIS systems, where the representations of rasters and shapefiles are very different. Since a Julia Matrix can hold anything it might be possible to represent these things the same way? Not sure here. |
I would not make this distinction here. As you already mentioned, the difference is more an implementation detail than a conceptual one. I think it should be possible to implement e.g. an So my suggestion would be to define an Interface for |
See also yeesian/ArchGDAL.jl#37 (comment) for some related discussion. Main issue; if we have an |
There is https://github.com/JuliaArrays/AxisArrays.jl. (Edit: never mind, you're aware of it as stated in the issue you link) As for the rest, probably best to start simple and add bits as needed. |
The issue about storing time is also something we're discussing a lot in the context of SpatialEcology.jl. WRT the index ordering, that seems like an aspect of implementation rather than interface? At least I always store my grid data in the long format (lats, longs, various values) because that plays more nicely with how we treat the data in analyses. |
Good to know that the GDAL folks (Even) are also thinking about adding support for extra dimensions in the GDAL data model in RFC 75: |
Hi, when I do geographical stuff, our sampling units are very frequently laid out as a spatial grid. This can be represented very compactly (e.g. https://github.com/EcoJulia/SpatialEcology.jl/blob/mkb/dev/src/DataTypes.jl#L19-L26 / https://github.com/EcoJulia/SpatialEcology.jl/blob/mkb/dev/src/DataTypes.jl#L40-L43 or https://github.com/FugroRoames/SpatialGrids.jl (where they call it a "raster"). I think of this as something distinct from a Raster, which is a Matrix holding a single value in each cell, and essentially we treat them as square polygons.
Does such a type have a place in your model here?
The text was updated successfully, but these errors were encountered: