[PROJ] Is 16-bit quantization of values / (sub-)millimetric error in grids (sometimes) acceptable ?

[Even Rouault]

> This is less of a concern nowadays.

If that were only true... I've been bugged this week about an issue with 
reprojecting data in the US from NAD27 to WGS84 with one software package and 
having errors in the range 30 to 100 m. After digging, I found that this 
software didn't ship with the proj-datumgrid-1.8 base package and thus lacked 
the CONUS grid. The maintainer of the package is hesitating a bit to add an 
extra 6 MB to it...

> If the concern is the size of the compressed data on disk, perhaps it is
> worth being a little bit more ambitious.  How about representing the
> data as integers (let's say 32-bit unsigned, but maybe it would be good
> to allow for 64-bit and for signed) with an offset and scale?

I've tried that with 20,- 24- and 32-bit integers and scaling/offseting on 
EGM2008 and the resulting files are larger than using IEEE 32-bit float with 
horizontal floating-point predictor & DEFLATE. Only going down to 16-bit 
brings substential compression rate improvements. That's about all we can do 
if we stay with what libtiff currently supports and not invent another codec. 
A design constraint is that we should be able to open the grids with QGIS and 
that they display correctly out-of-the box (which is the case we the solutions 
I've investigated)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com