Opened 6 months ago

Closed 5 months ago

#1501 closed defect (fixed)

Petascope_TimeUtil count offset using BigDecimal

Reported by: bphamhuu Owned by: bphamhuu
Priority: major Milestone: 9.4
Component: petascope Version: development
Keywords: Cc: dmisev, vmerticariu
Complexity: Medium


The problem is the CrsComputer? using TimeUtil? count subset and return Double when the axis domain Element is using BigDecimal?, then the calculation from them will be not correct if the resolution is not really fit number, such as: 0.01466666666666666666.

In this case, we need BigDecimal? from this TimeUtil?.countOffset to make them have same value and the CrsComputer? will be correct.

The coverage which show this problem is PM 10 (ECMWF) and using pixelIsPoint:true, here is the detail description

numericSubset.getLowerLimit().subtract(domMin) in CrsComputer which has difference .00000000000665 value when using pixelIsPoint:true.
The problem is because: TimeUtil.countOffset using double and CoverageMetadata using BigDecimal to calculate the axisLo:axisHi.         
so: domMin is: 151212.97916666666665.
and: numericSubset.getLowerLimit() is: 151212.97916666666.

If I change this method and all the parsedSubset<Double> to BigDecimal then can import without subset_correction:true.

domMin is calculated from TimeUtil.countOffset(origin) - resolution * 0.5 (with origin is: 2015-01-03T00:00:00+00:00) 

and TimeUtil.countOffset() return an integer value: 151213.0, 

then domMin is: 151212.97916666666665 and subset.lowerLimit is calculated from TimeUtil.countOffset(2015-01-02T23:30:00+00:00), this returns double value: 151212.97916666666.

Change History (1)

comment:1 Changed 5 months ago by bphamhuu

  • Resolution set to fixed
  • Status changed from new to closed

it was fixed and using BigDecimal? in time format now, the change is BigDecimal? equals to [doubleValue - 0.0000000001, doubleValue + 0.0000000001]

Note: See TracTickets for help on using tickets.