Hi everyone,
I upgraded the blog-post with all command lines I used and how I get
the base TIF and the other formats from it.
Hope to see the parameters I used will explain the results we got.
I'm open to received recommendations to get better result.
Stay here for more information.
Regards,
Lucie
Lucie Nicolier
[email protected] <mailto:[email protected]>
+41 (0)79 276 67 76 <tel:+41792766776>
OPENGIS.ch Logo <http://www.opengis.ch>
Le 09.06.2020 à 14:01, Matthias Kuhn a écrit :
Thanks for the excellent questions Even
Lucie has done the analysis and has all the parameters. She is not in
the office these days. Once she is back I hope she can share the
parameters and potentially also add a couple of additional rows to
the table with improved parameters.
Sorry that I can't help more right now.
Matthias
On 6/9/20 1:56 PM, Even Rouault wrote:
Matthias,
thanks for the analysis. There are however a few unexpected results.
1) I'd expect gpkg pyramid_JPEG and COG_JPEG to have very similar
sizes, even COG_JPEG being potentially slightly smaller.
And I'd also expect COG_JPEG to be slighly faster (but with less
confidence that my statement about size)
Has by chance the source raster an alpha band ? In which case
gpkg_pyramid_JPEG would have dropped it, whereas COG_JPEG will
encode it as DEFLATE compressed mask, but still the difference is
surprising
Another explanation might be the block size. GPKG defaults to
256x256 tiles, whereas COG_JPEG to 512x512. Perhaps that affect
compression efficiency. And performance? (depends if your bench
maintains the GDAL raster opened between requests or not)
If you didn't specify quality settings, both COG_JPEG and GPKG JPEG
should use the same quality of 75%
2) For the same compression type, block sizes and number of
overviews, MBTiles (the report doesn't specify the compression
scheme for it) and GeoPacakge should also have similar sizes and
performance. They are really close brothers, with just a few systems
tables different.
Even
> Hi all,
>
> At OPENGIS.ch we have recently looked into different raster
formats. The
> results can be read here:
>
https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-fo
> r-qfield/
>
> Not that surprising, but one of the interesting findings was that webp
> is very efficient. Low filesize, reasonable rendering performance,
> support for transparency. In short, it has all the potential for being
> used as default transport format for WM(T)S.
>
> Looking at our server implementation, this format is not
supported. Did
> someone ever think about or even look into that?
>
> Regards
--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
