Experimentally support CRSIndex

[dcherian]

It'd be nice to experiment some with this prototype CRSIndex (though there are still bugs and work to do)

We could experiment with optionally adding such an index through rioxarray.open_dataset(..., use_crsindex=True) and then get some experience with it before refactoring it out to a ecosystem package like geoxarray

Reprojection seems like a high value application where assigning a new CRSIndex would be quite impactful.

Is there an existing example that might benefit a lot from propagating CRS information automatically?

cc @djhoese

Original Xarray Issue - "Add CRS/projection information to xarray objects"

[snowman2]

Thanks for making the prototype. That looks pretty nice.

Do you think it would be better to wait before officially adding it to rioxarray so some wrinkles can be ironed out first? Or do you think that adding it to rioxarray will help the development process for indexes in xarray?

Thoughts:

• Add the CRSIndex in rioxarray in the rio.write_crs method. That is used everywhere and should propagate to all of the rioxarray methods that use the CRS.
• As an initial implementation, we could start with warnings instead of errors. This way, we aren't preventing operations from working that should work if the user really knows what they are doing. Later on, as we gain more experience with indexes and feel more confident in the implementation, we can update to exceptions.
• We may want to ignore axis order when comparing the CRS with the ignore_axis_order kwarg.

[dcherian]

adding it to rioxarray will help the development process for indexes in xarray?

I think this will be a very useful experiment.

dd the CRSIndex in rioxarray in the rio.write_crs method. That is used everywhere and should propagate to all of the rioxarray methods that use the CRS.

IMO it would be good to try this and see what fails in the test suite. That would be a more exhaustive test than my suggestion to pick a single "workflow" example./

[snowman2]

Sounds like a good plan to me.

Anyone who would like to try implementing the CRSIndex and adding it to rio.write_crs is welcome to, If you do get started, please post a comment here so we can coordinate our efforts. I will make sure to post in the thread if I get some free time to work on it.

[scottyhq]

Anyone who would like to try implementing the CRSIndex and adding it to rio.write_crs is welcome to, If you do get started, please post a comment here so we can coordinate our efforts.

@snowman2 we've finally been making some headway trying this out. Currently testing things on my fork in this PR scottyhq#1, and borrowing from @benbovy's linked xvec implementation and @dcherian's prototype notebook. The example notebook in the PR highlights some use-cases and goals (https://github.com/scottyhq/rioxarray/blob/crsindex/docs/examples/crs_index.ipynb).

[snowman2]

Nice 👍

My first thought is to make use_crs_index=True/False a global option ref. Another idea was to add a crs_index_error=True/False global option to raise an exception if enabled and the CRS are different, otherwise raise a warning.

[dcherian]

make use_crs_index=True/False a global option

Could this screw up a downstream package though? Or maybe we want that to shake out all the bugs :P

crs_index_error=True/False global option to raise an exception if enabled and the CRS are different,

It may be prudent to be strict now and loosen things later. If fixing the error is simply .rio.write_crs(...), then the error message could print out whats needed.

[snowman2]

Could this screw up a downstream package though?

It works as a context manager and so it can be applied locally as well. Though, the current strategy would work as well. And as you mentioned, it would be good to have a way to do a thorough bug search.

[snowman2]

It may be prudent to be strict now and loosen things later.

Since it is optionally enabled (and off by default), being strict is fine.

[dcherian]

FYI @scottyhq and I are thinking of hacking on this during the SciPy sprints. let us know if anyone interested in this stuff will be around