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

[XARRAY] add env settings to fallback to WGS84 when no CRS is provided #725

Closed
wants to merge 2 commits into from

Conversation

vincentsarago
Copy link
Member

closes #717

cc @j08lue

Copy link
Contributor

@j08lue j08lue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The config option makes the behaviour nicely explicit.

I would probably recommend to pretty much all users to turn this WGS84 default option on, since rectilinear lat/lon grids are so very common for Xarray datasets (climate data in NetCDF), so it is a pretty safe guess. One could add some heuristics around it, too, but that is not rio-tiler material.

Had a few questions regarding the implementation, please see below.

Comment on lines +94 to +98
if not self.crs:
warnings.warn(
"Dataset doesn't have a valid CRS set. rio-tiler might not work properly",
MissingCRSWarning,
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we not throw an exception in this case?

Using an XarrayTiler for anything meaningful without a (valid) CRS, will inevitably fail.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We usually don't fail for this because you can still access the dataset 🤷

Let me think about it

"Dataset doesn't have a valid CRS set. Automatically setting CRS to WGS84",
OverwritingCRSWarning,
)
self.input.rio.write_crs("epsg:4326", inplace=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mutates the self.input Xarray object (DataArray).

If we do not copy what the user passed in earlier, this behaviour could be unexpected for a user.

If there is a chance that the XarrayReader mutates the input, should we perhaps always have it create a copy up-front?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 good point

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😬 sadly rio-tiler gets the input directly from the user so we can't really avoid editing the origin data array

@vincentsarago
Copy link
Member Author

I would probably recommend to pretty much all users to turn this WGS84 default option on, since rectilinear lat/lon grids are so very common for Xarray datasets (climate data in NetCDF), so it is a pretty safe guess. One could add some heuristics around it, too, but that is not rio-tiler material

🤔

Well I usually don't like magic, meaning if would prefer that people know what they are doing instead of trying to patch for every issues. IMO not having CRS set in their dataset is their issue, and shouldn't be rio-tiler one.

As think what we do in titiler-xarray is better https://github.com/developmentseed/titiler-xarray/blob/dev/titiler/xarray/reader.py#L170-L172

@vincentsarago
Copy link
Member Author

in #726 I've proposed another approach which raises errors instead of trying to fix the dataset and then expect the bad dataset to be handled at application level

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

Successfully merging this pull request may close these issues.

Handle Xarray dataset without CRS
2 participants