-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Implementation of CRS storage in rasterio with PROJ.4 & WKT #2723
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
Comments
Tag: @fmaussion @djhoese |
Sorry for being late on this one. Yes, I agree that the "coordinate attribute" is worth a try. To avoid redundancy in the name one could name the coord variable attributes simply
|
I definitely agree 💯 with you on avoiding redundancy. I actually had the same thought. However, part of the reason for using |
@fmaussion just a ping for what are your thoughts are for next steps on this? |
Going to close this as it is over a year old. For reference, WKT support is in |
@snowman2 @djhoese It'd be nice to update our docs to link to rioxarray and other relevant packages. (e.g. here https://xarray.pydata.org/en/stable/io.html#rasterio). Adding an example on doing these manipulations would also be very welcome. |
What types of manipulations are you thinking about? Reprojection? Export to geotiff? Clip? Reading in files? |
I think we should seriously consider removing all rasterio logic in xarray and make rioxarray an optional dependency to read geotiff files with xarray. |
@snowman2 Any/all of those "common operations" sounds good. We don't have a single geoTIFF example: https://xarray.pydata.org/en/stable/examples.html so at this point anything would be a big improvement
👍 Though maybe we should wait till the backends refactor is done so that things are a little more easy. |
@dcherian Maybe a link to these examples in that section then? |
Continuation of the discussion from #2722 to move onto implementation details.
The text was updated successfully, but these errors were encountered: