Skip to content
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

deprecate open_rasterio in favour of a rioxarray entrypoint? #4697

Closed
dcherian opened this issue Dec 15, 2020 · 8 comments · Fixed by #5808
Closed

deprecate open_rasterio in favour of a rioxarray entrypoint? #4697

dcherian opened this issue Dec 15, 2020 · 8 comments · Fixed by #5808

Comments

@dcherian
Copy link
Contributor

dcherian commented Dec 15, 2020

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

@snowman2
Copy link
Contributor

Looks like entrypoint support was added in #4577. What is the timeline for the next release?

and rioxarray agrees

Is rioxarray agreeing to allow the addition of entrypoint support? If so, 👍

@keewis
Copy link
Collaborator

keewis commented Dec 19, 2020

What is the timeline for the next release?

There's no timeline, yet. Since we just released 0.16.2, maybe in about 2-3 months?

@snowman2
Copy link
Contributor

snowman2 commented Apr 19, 2021

@alexamici added the entrypoint here; corteva/rioxarray#281. It seems xarray 0.18+ is required for it to work. Any timeline for the 0.18 release?

@max-sixty
Copy link
Collaborator

I think we could release 0.17.1 fairly soon — nothing is pending but it's also fairly easy to do a release.

Do we want to deprecate open_rasterio and point people towards rioxarray? We can do that now.

@alexamici
Copy link
Collaborator

alexamici commented Apr 19, 2021

@max-sixty I'm +1 on deprecating xarray flavour of open_rasterio and direct users to rioxarray.

BTW, I would rather prefer the next release to be 0.18.0 as the backend changes are both large and user visible (open_dataset now accept **kwargs that are added to **backend_kwargs).

@max-sixty
Copy link
Collaborator

OK great @alexamici

@keewis
Copy link
Collaborator

keewis commented May 27, 2021

if we deprecate xr.open_rasterio we should also do the same for xr.tutorial.open_rasterio and get xr.tutorial.open_dataset("RGB.byte") to work.

@keewis
Copy link
Collaborator

keewis commented Jun 18, 2021

Since it comes up pretty often: should we go through with deprecating open_rasterio and the builtin rasterio backend?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants