I am using geoserver v2.12.2 with the JVM system property to have geoserver
unpack NetCDF data with respect to the scale_factor/add_offset attributes: 
Geoserver seems to be doing the unpacking fine, but when I configure my
coverage.xml to re-pack the data into a smaller datatype (such as byte) the
formula used treats the datatype as unsigned and when the NetCDF file is
read by external software the values are interpreted incorrectly since
NetCDF convention defines the packed data types (Byte, Short, Int) as signed
integers.  Given this convention, I am curious if there is a reason this
algorithm was selected that I'm overlooking or if this is a bug in the
software.  I would recommend that the formula be updated to use the "signed"
one below until "ubyte, ushort, and uint" data types are supported by
geoserver for packing.    

For reference, the formulas are defined in DataPacking.java 

There is more information at the link below, but these seem to be the two
recommended options for data packing while reserving space for missing data.
The first is for signed packed values and the second is for unsigned packed
values which is the one that geoserver is using.  

In either the signed or unsigned case, an alternate formula may be used for
the add_offset and scale_factor packing parameters that reserves a packed
value for a special value, such as an indicator of missing data. For
example, to reserve the minimum packed value (-2^n\ -\ 1^) for use as a
special value in the case of signed packed values:

> scale_factor =(dataMax - dataMin) / (2^n^ - 2)

> add_offset = (dataMax + dataMin) / 2

If the packed values are unsigned, then the analogous formula that reserves
0 as the packed form of a special value would be:

> scale_factor =(dataMax - dataMin) / (2^n^ - 2)

> add_offset = dataMin - scale_factor

Thanks for any help or information I might be overlooking! 
- Mrc0113

Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-Dev-f3819232.html

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list

Reply via email to