Possible portability issues in GeoPackage Raster Driver

[Augustus]

GDAL GeoPackage Raster driver is using specific algorithm to generate tile_row and tile_column fields in GeoPackage Raster Tiles Table. These fields are used to uniquely identify the tile_data that should be Written or Read.

GeoPackage Specification puts no restriction on how the tile_column or tile_data is being calculated for each tile. GDAL uses Block Offset and a Shift factor to write these fields. This creates a portability issue as other vendors might use a different strategy to write these fields.

For instance, ESRI's raster2gpkg: ​https://github.com/Esri/raster2gpkg uses a linear algorithm to write the tile_row and tile_column fields.

[Jukka Rahkonen]

Isn't there bug in the GPKG standard if such thing is not defined? However, I do not quite understand your description. In the standard I can see:

tile_column INTEGER 0 to gpkg_tile_matrix matrix_width – 1

tile_row INTEGER 0 to gpkg_tile_matrix matrix_height - 1

Could you add an example where GDAL and ESRI are generating different tile_column and tile_row values for the same tile?

[Augustus]

GPKG file created using gdal_translate with GoogleMapsCompatible Tiling Scheme

[Augustus]

Source Image. This should be scaled to 6600 rows and columns and then add to the GeoPackage

[Augustus]

This is how I generated the test files.

gdal_translate -of GTIFF -tr 0.179 0.179 byte.tif byte6600.tiff
gdal_translate -of GPKG byte6600.tif byte6600AGOL.gpkg -co TILING_SCHEME=GoogleMapsCompatible

The specification constraints the tile_column to be between 0 <= tile_column < matrix_width for every zoom level. Similarly for row as well

As you can see the in the byte6600AGOL.gpkg for zoom_level 19 value of tile column lies as: 90384 <= tile_column <=90815. The values chosen are specific to gdal implementation as per my understanding. This could cause some consistency issues with drivers from other vendors.

ESRI starts <tile_column, tile_row> as 0,0 for every zoom level. This creates some portability issues. Also, seems the Specification lacks which algorithm we should prefer for numbering rows and columns.

Meanwhile, I would try to generate some ESRI GeoPackages

[Even Rouault]

I strongly believe that GDAL behaviour is fine and conformant to the standard.

When you use -co TILING_SCHEME=GoogleMapsCompatible, the effect is generally that the top level tile will not be at (0,0), so as to conform to the global tiling scheme of Google Maps. If you display both byte.tif and byte6600AGOL.gpkg in QGIS, you'll see that they overlap perfectly.

If you want ESRI-like behaviour, don't add -co TILING_SCHEME=GoogleMapsCompatible and then the top left tile will be at (0,0). In that case, the tiling scheme chosen fits perfectly the georeferencing of the source raster.

In any case, the georeferencing is perfectly defined by the GPKG spec since (tile_column,tile_row) must be compared with the information of gpkg_tile_matrix & gpkg_tile_matrix_set.