Opened 8 years ago

Closed 8 years ago

#6636 closed defect (invalid)

Possible portability issues in GeoPackage Raster Driver

Reported by: Augustus Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords: GeoPackage


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: uses a linear algorithm to write the tile_row and tile_column fields.

Attachments (2)

byte6600AGOL.gpkg (481.0 KB ) - added by Augustus 8 years ago.
GPKG file created using gdal_translate with GoogleMapsCompatible Tiling Scheme
byte.tif (736 bytes ) - added by Augustus 8 years ago.
Source Image. This should be scaled to 6600 rows and columns and then add to the GeoPackage

Download all attachments as: .zip

Change History (5)

comment:1 by Jukka Rahkonen, 8 years ago

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?

by Augustus, 8 years ago

Attachment: byte6600AGOL.gpkg added

GPKG file created using gdal_translate with GoogleMapsCompatible Tiling Scheme

by Augustus, 8 years ago

Attachment: byte.tif added

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

comment:2 by Augustus, 8 years ago

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. Other vendors can choose their own range as well. Also, seems the Specification lacks which algorithm we should prefer for numbering rows and columns.

Meanwhile, I would try to generate some ESRI GeoPackages

Last edited 8 years ago by Augustus (previous) (diff)

comment:3 by Even Rouault, 8 years ago

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.