Geometry with NaNs has different header after copy to PostGIS and back to GPKG

[wonder-sk]

The actual WKB stays the same, however there may be minor differences in the header of GPKG geometry encoding. With a particular geometry when the first point has Z=NaN, envelope's minz/maxz is stored as NaN from GDAL, but when going from PostGIS, libgpkg's routine to calculate envelope sets minz/maxz to zero. It's hard to say which one is correct and which one is wrong. Having a NaN thrown into this is probably undefined.

GPKG from GDAL:

R1AABTZRAAA03HAtLiMQQW+fCr43IxBBh9o2PZSXEEEFxrQ8nZcQQQAAAAAAAPh/AAAAAAAA+H8B6wMAAAEAAAAFAAAAlvWihTMjEEEFxrQ8nZcQQQAAAAAAAPh /b58KvjcjEEGvGr1umJcQQQAAAAAAAAAAOU25bTEjEEGH2jY9lJcQQQAAAAAAAAAANNxwLS4jEEEqynv/mJcQQQAAAAAAAAAAlvWihTMjEEEFxrQ8nZcQQQAAAAAAAPh/

GPKG from PostGIS:

R1AABTZRAAA03HAtLiMQQW+fCr43IxBBh9o2PZSXEEEFxrQ8nZcQQQAAAAAAAAAAAAAAAAAAAAAB6wMAAAEAAAAFAAAAlvWihTMjEEEFxrQ8nZcQQQAAAAAAAPh/b58KvjcjEEGvGr1umJcQQQAAAAAAAAAAOU25bTEjEEGH2jY9lJcQQQAAAAAAAAAANNxwLS4jEEEqynv/mJcQQQAAAAAAAAAAlvWihTMjEEEFxrQ8nZcQQQAAAAAAAPh/

Envelope calculation:

• GDAL strategy: use first point to init, then compare using 2nd, 3rd, ..., Nth point
• libgpkg strategy: init to some extreme numbers, then compare using 1st, 2nd, ..., Nth point

If first point has NaN coordinate, GDAL stores NaN but libgpkg sets 0.
If second point (or later) has NaN coordinate, GDAL stores 0 too.

Proposed solution: ignore headers of gpkg geometry encoding - only use WKB for comparison. (But for the time being we want to keep the headers in order to keep the format backwards compatible.) Alternatively we could modify libgpkg's implementation, but then we would need to port it upstream or keep our fork - and there still could be some more minor incompatibilities.

Workaround: set the Z value to a reasonable value instead of NaN