Now that our backends work is well underway, it seems like a good time to discuss deprecating the open_rasterio function and outsourcing it to rioxarray (which would then implement support for the new entrypoint).
From @jhamman's comment
There's also the question of where the rasterio backend should live once #1970 is implemented. I think we can make a pretty strong argument that it should move out of xarray and into a 3rd party package. Perhaps rasterio itself, or, more likely something like rio-xarray (cc @snowman2). See #3166 for a demo of how this may work.
As you can see, there are a few big questions up in the air right now. Work on #1970 will begin this summer so now is a great time to game out the various options for the rasterio backend.
I am in favour of doing this. I see no reason why there should be two slightly divergent versions of the same function, and (anecdotally) the rioxarray version seems to be more full-featured and regularly improved.
@pydata/xarray What do you think?
If we agree to do this (and rioxarray agrees), we could put this as a "deliverable" in our NASA proposal. This work would be totally relevant to that call.
Related: #4142
cc @snowman2@scottyhq@JessicaS11@WeatherGod
Now that our backends work is well underway, it seems like a good time to discuss deprecating the
open_rasteriofunction and outsourcing it torioxarray(which would then implement support for the new entrypoint).From @jhamman's comment
I am in favour of doing this. I see no reason why there should be two slightly divergent versions of the same function, and (anecdotally) the
rioxarrayversion seems to be more full-featured and regularly improved.@pydata/xarray What do you think?
If we agree to do this (and rioxarray agrees), we could put this as a "deliverable" in our NASA proposal. This work would be totally relevant to that call.
Related: #4142
cc @snowman2@scottyhq@JessicaS11@WeatherGod