issues: 767941842

This data as json

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

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

Links from other tables