[gdal-dev] GDAL GeoPackage Tiled Gridded Elevation test datasets

[Even Rouault]

Brian,

Thanks for your feedback.

> N45E006_uint16.gpkg?
> 
>   *   ?Missing column_name of "tile_data" in gpkg_extensions for the user
> data table entry

Fixed. Sample files regenerated with that ix and uploaded

> *   tile matrix specifies zoom levels 0 - 4, but
> elevations only exist for zoom 4 

Yes, by default gdal_translate populates the higher zoom level. Lower zoom levels may be 
optionnaly filled with gdaladdo. But I think you need to have the placeholder for the 
intermediate resolutions to satisfy the power-of-two factors (I'm not completely sure about 
that)

> *   images in tile row 14 and tile column
> 14 do not seem to contain elevations, file sizes are smaller as well (not
> sure if intentional)

Those tiles are partial due to 3601 = 14 * 256 + 17, but they are not empty:

even at even-i700:~/gdal/trunk/gdal$ gdallocationinfo N45E006_uint16.gpkg 3600 0
Report:
  Location: (3600P,0L)
  Band 1:
    Value: 3145

even at even-i700:~/gdal/trunk/gdal$ gdallocationinfo N45E006_uint16.gpkg 0 3600
Report:
  Location: (0P,3600L)
  Band 1:
    Value: 2391

> 
> Latitude: 45.0
> Longitude: 6.5
> NEAREST_NEIGHBOR: 2480.0
> BILINEAR: 2480.96875
> BICUBIC: 2480.7311287925113?

Hum, I get quite significant values:

$ gdallocationinfo N45E006_uint16.gpkg -wgs84 6.5 45
Report:
  Location: (1800P,3600L)
  Band 1:
    Value: 2296

which matches the original file:

$ gdallocationinfo N45E006.hgt -wgs84 6.5 45
Report:
  Location: (1800P,3600L)
  Band 1:
    Value: 2296

> 
> N49E002_int16.gpkg?
> 

> Latitude: 49.5
> Longitude: 2.5
> NEAREST_NEIGHBOR: 120.0
> BILINEAR: 120.46875
> BICUBIC: 120.59874286525883?

I get something closer:

$ gdallocationinfo N49E002_int16.gpkg -wgs84 2.5 49.5
Report:
  Location: (1800P,1800L)
  Band 1:
    Value: 119

> 
> 
> 
> N49E002_float32_png.gpkg

> *   gridded tiles for tile row 14 and tile column 14 have
> offsets of -32768 which is what is specified as the data_null value in the
> gridded coverage. This creates elevations of -32768.0.  Instead the data in
> the tiles should probably be -32768 if it is null.
Not completely sure to follow you on those last 2 sentences.

Those elevations at -32768 are indeed missing data due to the initial raster dimensions not 
being a multiple of the tile dimension.


> 
> N49E002_float32_tiff.gpkg
> 
>   LZW decompression is working but warning that the
> end of data was reached without an end of input code (257).  Not sure if
> this is an issue or not.

Hum, this is interesting. This is libtiff which is used to encode those tiles. Wondering if this is 
not this bug that may be hit:
http://bugzilla.maptools.org/show_bug.cgi?id=1982


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170217/c3ec09c3/attachment.html>