-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
Looks like entrypoint support was added in #4577. What is the timeline for the next release?
Is |
There's no timeline, yet. Since we just released |
@alexamici added the entrypoint here; corteva/rioxarray#281. It seems xarray 0.18+ is required for it to work. Any timeline for the |
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 |
@max-sixty I'm +1 on deprecating xarray flavour of BTW, I would rather prefer the next release to be |
OK great @alexamici |
if we deprecate |
Since it comes up pretty often: should we go through with deprecating |
Now that our backends work is well underway, it seems like a good time to discuss deprecating the
open_rasterio
function 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
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
The text was updated successfully, but these errors were encountered: