GeoPackage raster mosaic tile indices are mapped to the wrong co-ordinates

[tbarsballe]

When reading a GeoPackage raster mosaic using GDAL (via QGIS 2.14.8), it appears that the y-axis tile indices are read in the wrong order.

I am using a GeoPackage raster mosaic generated using GeoServer WMS, with the GeoPackage output format (GeoServer version 2.11, latest nightly build). GeoServer is able to read and display this GeoPackage without issues.

Examining the GeoPackage with an SQLite viewer, for zoom level 1 I see the (0,0) tile is at -180,-90 (bottom-left) and the (3,1) tile is at 180,90 (top-right), which seems correct (and leads me to believe this is indeed a GDAL bug rather than a GeoServer bug).

However, when trying to view this GeoPackage using QGIS, the bottom-left tile ends up top-left, and the top-right tile ends up bottom-right.

[tbarsballe]

Output at zoom level 0 (correct)

[tbarsballe]

Output at zoom level 1 (error)

[tbarsballe]

Output at zoom level 2 (error)

[Even Rouault]

I think I reported a long time ago that GeoServer doesn't generate GeoPackage correctly. In GeoPackage tile (0, 0) is the top-left tile, like in WMTS. Which is unlike MBTiles

See ​http://www.geopackage.org/spec/#tile_matrix """ The tile coordinate (0,0) always refers to the tile in the upper left corner of the tile matrix at any zoom level, regardless of the actual availability of that tile. """

GDAL / QGIS can correctly read tiles from other implementations referenced at ​http://www.geopackage.org/#sampledata like ​https://portal.opengeospatial.org/files/?artifact_id=73648

[tbarsballe]

Thank you for the response; I was initially unable to find where in the GeoPackage spec the upper left tile was defined, but I see it in the document you linked. I will migrate this to the GeoTools bug tracker.

[tbarsballe]

Migrated to the GeoTools bug tracker: ​https://osgeo-org.atlassian.net/browse/GEOT-5714