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
netCDF3 only knows signed bytes, but there's a convention of adding an attribute _Unsigned=True to the variable to be able to store unsigned bytes non the less. This convention is handled at this place by xarray.
OPeNDAP only knows unsigned bytes, but there's a hack which is used by the thredds server and the netCDF-c library of adding an attribute _Unsigned=False to the variable to be able to store signed bytes non the less. This hack is not handled by xarray, but maybe should be handled symmetrically at the same place (i.e. if .kind == "u" and unsigned == False).
As descibed in the "hack", netCDF-c handles this internally, but pydap doesn't. This is why the engine="netcdf4" variant returns (correctly according to the hack) negative values and the engine="pydap" variant doesn't. However, as xarray returns a warning at exactly the location referenced above, I think that this is the place where it should be fixed.
If you agree, I could prepare a PR to implement the fix.
netCDF3 doesn't know unsigned while OPeNDAP doesn't know signed (bytes).
Depending on which backend source is used, the original data is stored
with the wrong signedness and needs to be decoded based on the _Unsigned
attribute. While the netCDF3 variant is already implemented, this commit
adds the symmetric case covering OPeNDAP.
closespydata#4954
netCDF3 only knows signed bytes, but there's a convention of adding an attribute
_Unsigned=True
to the variable to be able to store unsigned bytes non the less. This convention is handled at this place by xarray.OPeNDAP only knows unsigned bytes, but there's a hack which is used by the thredds server and the netCDF-c library of adding an attribute
_Unsigned=False
to the variable to be able to store signed bytes non the less. This hack is not handled by xarray, but maybe should be handled symmetrically at the same place (i.e.if .kind == "u" and unsigned == False
).As descibed in the "hack", netCDF-c handles this internally, but pydap doesn't. This is why the
engine="netcdf4"
variant returns (correctly according to the hack) negative values and theengine="pydap"
variant doesn't. However, asxarray
returns a warning at exactly the location referenced above, I think that this is the place where it should be fixed.If you agree, I could prepare a PR to implement the fix.
The text was updated successfully, but these errors were encountered: