A RasterStack can be backed by a NetCDF or HDF5 file, a NamedTuple of Rasters holding .tif files, or all Rasters in memory. Users do not need to worry about the specifics of spatial file types.
ππ Effortless Spatial Lookups
Projected lookups with cylindrical projections can be indexed using other cylindrical projections by setting the mappedcrs keyword during construction. You donβt need to know the underlying projection, as the conversion is handled automatically. This means that lat/lon EPSG(4326) can be used seamlessly if needed.
Because there are so many raster file types and variations of them, most of the time we need the exact file that caused your problem to know how to fix it, and be sure that we have actually fixed it when we are done. So fixing a Rasters.jl bug nearly always involves downloading some file and running some code that breaks with it (if you can trigger the bug without a file, that's great! but its not always possible).
To make an issue we can fix quickly (or at all) there are three key steps:
Include the file in an accessible place on web without authentication or any other work on our part, so we can just get it and find your bug. You can put it on a file hosting platform (e.g. google drive, drop box, whatever you use) and share the url.
Add a minimum working example to the issue template that first downloads the file, then runs the function that triggers the bug.
Paste the complete stack trace of the error it produces, right to the bottom, into the issue template. Then we can be sure we reproduced the same problem.
Good issues are really appreciated, but they do take just a little extra effort with Rasters.jl because of this need for files.