[gdal-dev] gdaladdo does not "respect" GPKG tile matrix
Even Rouault
even.rouault at spatialys.com
Mon Jan 8 04:07:49 PST 2024
Hi Philippe,
I no longer reproduce the below issues nor
https://github.com/OSGeo/gdal/issues/3853 with gdaladdo without explicit
level with GDAL master 3.9dev. This is due to improvement
https://github.com/OSGeo/gdal/commit/d178b03e3db that reuse existing
overview levels when they are declared by the dataset. Which is the case
for a GeoPackage created with a tiling_scheme and with unpopulated levels.
The only case now where the tiling scheme might no longer be respected
is if the user specifies an overview level beyond the base one, or some
"weird" factor like 3. But as it is the user that requests that, I don't
think we should do anything for that case.
Even
Le 08/01/2024 à 11:57, Philippe Ghesquiere via gdal-dev a écrit :
> 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.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240108/89411a94/attachment.htm>
More information about the gdal-dev
mailing list