Accessing MRMS data through NCSS leads to NaNs for all values at certain times. This happens due to the computed offset being incorrect (in CoordsSet::addAdjustedTimeCoords), due to the fact that CalendarPeriod::subtract does not have the property subtract(a, b) = - subtract(b, a). This error was introduced by https://github.com/Unidata/netcdf-java/pull/1099, where I changed the rounding from (int) to Math.floor. Of course, we could fix this issue at the call site of subtract, but it seems less error prone to fix subtract itself. There are two ways to fix this-- go back to casting to int or use Math.round. In the MRMS data I was looking at, the offsets are 0.0, 1.99, 4.0, ... so it just makes more sense to me to round these to 0, 2, 4 rather than truncate to ints.
This change again messes up interval lengths when the reftime is after the start of the interval. This is fixed by the change in TimeCoordIntvDateValue::convertReferenceDate.
Description of Changes
Accessing MRMS data through NCSS leads to NaNs for all values at certain times. This happens due to the computed offset being incorrect (in
CoordsSet::addAdjustedTimeCoords
), due to the fact thatCalendarPeriod::subtract
does not have the propertysubtract(a, b) = - subtract(b, a)
. This error was introduced by https://github.com/Unidata/netcdf-java/pull/1099, where I changed the rounding from(int)
toMath.floor
. Of course, we could fix this issue at the call site ofsubtract
, but it seems less error prone to fixsubtract
itself. There are two ways to fix this-- go back to casting toint
or useMath.round
. In the MRMS data I was looking at, the offsets are0.0, 1.99, 4.0, ...
so it just makes more sense to me to round these to0, 2, 4
rather than truncate to ints.This change again messes up interval lengths when the reftime is after the start of the interval. This is fixed by the change in
TimeCoordIntvDateValue::convertReferenceDate
.