[gdal-dev] gdaladdo does not "respect" GPKG tile matrix
Philippe Ghesquiere
philippe.ghesquiere at airbus.com
Mon Jan 8 02:57:11 PST 2024
Dear all,
A while ago, I opened a ticket which is still opened (
https://github.com/OSGeo/gdal/issues/3853). I recently bumped into this
bug with some new data, and I think I tracked the origin.
*1) Generate a test image :*
gdal_create -of GTIFF -co COMPRESS=LZW -a_srs epsg:4326 -a_ullr -180 90 180
-90 -burn 128 -outsize 2048 1024 worldwide.tif
*2) Convert to GPKG :*
gdal_translate -of GPKG -co TILING_SCHEME=InspireCRS84Quad worldwide.tif
worldwide_no_pyramid.gpkg
The GPKG tile matrix is as expected :
sqlite3 -header -column worldwide_no_pyramid.gpkg "SELECT rowid,* FROM
gpkg_tile_matrix ;"
rowid table_name zoom_level matrix_width matrix_height
tile_width tile_height pixel_x_size pixel_y_size
----- -------------------- ---------- ------------ -------------
---------- ----------- ------------ ------------
1 worldwide_no_pyramid 0 2 1 256
256 0.703125 0.703125
2 worldwide_no_pyramid 1 4 2 256
256 0.3515625 0.3515625
3 worldwide_no_pyramid 2 8 4 256
256 0.17578125 0.17578125
*3) Compute a default pyramid:*
cp worldwide_no_pyramid.gpkg worldwide_default_pyramid.gpkg
gdaladdo worldwide_default_pyramid.gpkg
The GPKG tile matrix is no longer the expected one (InspireCRS84Quad
InspireCRS84Quad) :
sqlite3 -header -column worldwide_default_pyramid.gpkg "SELECT rowid,*
FROM gpkg_tile_matrix ;"
rowid table_name zoom_level matrix_width matrix_height
tile_width tile_height pixel_x_size pixel_y_size
----- -------------------- ---------- ------------ -------------
---------- ----------- ------------ ------------
1 worldwide_no_pyramid 1 2 1 256
256 0.703125 0.703125
2 worldwide_no_pyramid 2 4 2 256
256 0.3515625 0.3515625
3 worldwide_no_pyramid 3 8 4 256
256 0.17578125 0.17578125
4 worldwide_no_pyramid 0 1 1 256
256 1.40625 1.40625
*4) Compute a manual pyramid:*
cp worldwide_no_pyramid.gpkg worldwide_manual_pyramid.gpkg
gdaladdo worldwide_manual_pyramid.gpkg 2 4
The GPKG tile matrix is still as expected (InspireCRS84Quad
InspireCRS84Quad) :
sqlite3 -header -column worldwide_manual_pyramid.gpkg "SELECT rowid,* FROM
gpkg_tile_matrix ;"
rowid table_name zoom_level matrix_width matrix_height
tile_width tile_height pixel_x_size pixel_y_size
----- -------------------- ---------- ------------ -------------
---------- ----------- ------------ ------------
1 worldwide_no_pyramid 0 2 1 256
256 0.703125 0.703125
2 worldwide_no_pyramid 1 4 2 256
256 0.3515625 0.3515625
3 worldwide_no_pyramid 2 8 4 256
256 0.17578125 0.17578125
*5) Compute a "Weird" pyramid:*
In this test, I generate too many levels in the pyramid on purpose :
cp worldwide_no_pyramid.gpkg worldwide_manual_weird_pyramid.gpkg
gdaladdo worldwide_manual_weird_pyramid.gpkg 2 4 8
The GPKG tile matrix is exactly the same as in
worldwide_default_pyramid.gpkg :
sqlite3 -header -column worldwide_manual_weird_pyramid.gpkg "SELECT
rowid,* FROM gpkg_tile_matrix ;"
rowid table_name zoom_level matrix_width matrix_height
tile_width tile_height pixel_x_size pixel_y_size
----- -------------------- ---------- ------------ -------------
---------- ----------- ------------ ------------
1 worldwide_no_pyramid 1 2 1 256
256 0.703125 0.703125
2 worldwide_no_pyramid 2 4 2 256
256 0.3515625 0.3515625
3 worldwide_no_pyramid 3 8 4 256
256 0.17578125 0.17578125
4 worldwide_no_pyramid 0 1 1 256
256 1.40625 1.40625
*6) Conclusion *
The default power-of-two factor list is computed in gdaladdo.cpp. At this
point, the algorithm is not aware of some GPKG limitations.
I found two workarounds :
- specify explicitly all zoom levels
- add minsize option. The minimum size has to be twice the tile_height /
tile_width : -minsize 512
Shouldn't we have a specific check for GPKG while computing the pyramid ?
For example by deriving the virtual method BuildOverviews() for GPKG ?
Philippe
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240108/8bde7d40/attachment-0001.htm>
More information about the gdal-dev
mailing list