.geobox property not defined for single pixel arrays

[Kirill888]

Expected behaviour

xx = dc.load(.., resolution=(-10,10))
xx.nbar_red[:, :1,:1].geobox.resolution == (-10, 10)

Actual behaviour

Instead get (nan, nan)

Why

Resolution is computed from axis values, when there is only one axis value resolution can not be inferred as you need at least 2 axis values to compute "step"

datacube-core/datacube/utils/math.py

Line 105 in d0ec48c

res = (data[data.size - 1] - data[0]) / (data.size - 1.0)

In the code above resolution will be computed to be 0/0 which is nan.

[andrewdhicks]

I think @uchchwhash was working on a fix for this, you should check with him

[Kirill888]

@andrewdhicks thanks I'm aware, hence this issue, unfortunately proposed changes in this branch https://github.com/opendatacube/datacube-core/tree/virtual-product-reproject would break .geobox behaviour when decimating loaded arrays:

xx = dc.load(.., resolution=(-10,10))
xx.nbar_red[:, ::2,::2].geobox.resolution == (-20, 20)

instead it would return (-10, 10)

[Kirill888]

Might have to be addressed as part of #519

[petewa]

I couldn't find a clean and neat way to fix this as part of Bug squash 2019.

I attempted to persist the updated resolution (non-native xarray metadata) attribute but does not seem to be propagated through the xarray native operations.

I also attempted to use with xr.set_options(keep_attrs=True): without success.

One solution I found is to override xarray's slice operator within ODC codebase to update this information but is fragile.

[uchchwhash]

Just making a note that the NetCDF CF convention prescribes:

To represent cells we add the attribute bounds to the appropriate coordinate variable(s). The value of bounds is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable." A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable. The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices. Since a boundary variable is considered to be part of a coordinate variable’s metadata, it is not necessary to provide it with attributes such as long_name and units.

As clunky as it is, at least it is a convention. I did not like it when I first saw it, but now I am humbler.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.