[gdal-dev] GPKG nodata isn't applied in all tiles
Roarke Gaskill
roarke.gaskill at weather.com
Thu Sep 28 13:38:54 PDT 2017
Evan,
Thank you for the insight and fix.
Roarke
On Thu, Sep 28, 2017 at 2:17 PM, Even Rouault <even.rouault at spatialys.com>
wrote:
> On jeudi 28 septembre 2017 09:08:00 CEST Roarke Gaskill wrote:
>
> > Hi,
>
> >
>
> > It seems the nodata value is not being used as "fill" completely around
>
> > tiled images.
>
> >
>
> > To reproduce:
>
> >
>
> > http://download.osgeo.org/geotiff/samples/spot/chicago/SP27GTIF.TIF
>
> >
>
> > gdal_translate -ot Float32 -of GPKG -co
>
> > "TILING_SCHEME=GoogleMapsCompatible" SP27GTIF.TIF chi1.gpkg
>
> > gdal_translate -a_nodata "-nan" -ot Float32 -of GPKG -co
>
> > "TILING_SCHEME=GoogleMapsCompatible" SP27GTIF.TIF chi2.gpkg
>
> >
>
> > gdal_translate -of GTIFF -oo "USE_TILE_EXTENT=YES" chi1.gpkg chi1.tif
>
> > gdal_translate -of GTIFF -oo "USE_TILE_EXTENT=YES" chi2.gpkg chi2.tif
>
> >
>
> > Notice that chi1.tif has 0 values all the way around the image. As I
> would
>
> > expect because a nodata value was not applied when creating the gpkg.
>
> > Howeverm in chi2.tif it appears the nodata value of nan was applied on
> the
>
> > left and top of the image but not on the right and bottom. Though on the
>
> > right it does appear to have applied some nodata values but not
> completely
>
> > to the right edge of the image.
>
>
>
> Roark,
>
>
>
> there are 2 issues:
>
>
>
> * NaN isn't a supported value for GeoPackage (just added a warning in that
> case). This due to the value being stored in the Real data_null column of
> the gpkg_2d_gridded_coverage_ancillary SQLite3 table, but SQLite3 doesn't
> support NaN values. They are stored like a SQL NULL value, so on reading
> GDAL (or other software) will not able to realize that there was a nodata
> value stored. That said, that should affect only the read side
>
>
>
> * there was indeed an implementation issue with non-zero nodata value on
> edge tiles when using a TILING_SCHEME, which I've fixed in trunk.
>
>
>
> So on writing this will work properly now, but when reading it back, the
> right bottom most tile which isn't serialized, but intersects the window of
> interest, will be read back with the default value of 0 instead of the
> expected NaN.
>
>
>
> So I'd recommend you use a different value than NaN (like -1e10)
>
>
>
> Also note that Float32 uses the implementation of the GeoPackage elevation
> extension at the time GDAL 2.2 was released. And this extension has finally
> be reworked, so interoperability with other software and potential future
> GDAL versions that might implement the final version of the extension is
> not guaranteed.
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
--
*Roarke **Gaskill *|Senior Software Engineer
*e:* roarke.gaskill at weather.com
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170928/b3e30161/attachment.html>
More information about the gdal-dev
mailing list