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

Make line-pixel coordinates consistent #59

Open
corrado9999 opened this issue May 25, 2021 · 2 comments
Open

Make line-pixel coordinates consistent #59

corrado9999 opened this issue May 25, 2021 · 2 comments

Comments

@corrado9999
Copy link
Collaborator

rioxarray returns fractional line-pixel coordinates (0.5, 1.5, ...), probably under the assumption that values are referred to the centre of the pixel. On the other hand, the calibration dataset (and others) directly uses the line-pixel coordinates reported in the XML, which are referred to integer positions.

Sentinel TIFFs actually report the PixelIsArea flag, thus, according to the standard, the "first" coordinate refers to the UL corner of the UL pixel. Thus, this could be an issue of rioxarray, that does not correctly apply such piece of information (incriminated code here).

However, I believe we should all agree in advance that we want such behaviour. In particular, I do not know the CF conventions interpret coordinates and, as such, how e.g. the extent of the image would be interpreted.

@corrado9999
Copy link
Collaborator Author

My fault, I found this issue some time ago and I worked around it, but when I updated my working copy I forgot to update my test code. However I think two things still holds:

  1. rioxarray is not correctly handling tiff information, I am opening an issue there
  2. is there some way to propagate such information into the CF conventions, or shall we manage this in some special way?

@alexamici
Copy link
Member

Note that the CF Conventions 1.9 state:

If bounds are not provided, an application might reasonably assume the gridpoints to be at the centers of the cells, but we do not require that in this standard.

We need to double check that this is the case for all our variables.

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

No branches or pull requests

2 participants