You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
rioxarray is not correctly handling tiff information, I am opening an issue there
is there some way to propagate such information into the CF conventions, or shall we manage this in some special way?
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.
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.
The text was updated successfully, but these errors were encountered: