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