Opened 8 weeks ago
Closed 6 weeks 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 |
Description
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 6 weeks ago by bphamhuu
- Resolution set to fixed
- Status changed from new to closed
Note: See
TracTickets for help on using
tickets.
it was fixed and using BigDecimal? in time format now, the change is BigDecimal? equals to [doubleValue - 0.0000000001, doubleValue + 0.0000000001]