id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,active_lock_reason,draft,pull_request,body,reactions,performed_via_github_app,state_reason,repo,type
767941842,MDU6SXNzdWU3Njc5NDE4NDI=,4697,deprecate open_rasterio in favour of a rioxarray entrypoint?,2448579,closed,0,,,8,2020-12-15T18:05:58Z,2021-10-02T20:38:35Z,2021-10-02T20:38:35Z,MEMBER,,,,"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](https://github.com/pydata/xarray/issues/4142#issuecomment-642413509)

> 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 


","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4697/reactions"", ""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue