0

I am trying to process an elevation model in COG with GDAL using gdalwarp and gdal_translate, to change the height values from AHD (australian height datum aka sea level) to ellipsoid. The transformation works well using a geoid in the PROJ folder, however, the file size seem to double despite using the same lzw compression. Does anyone know why? What would the second file be carrying that the first one doesn't?

 gdalwarp -s_srs "+proj=utm +zone=55 +south +ellps=GRS80 +units=m +no_defs +geoidgrids=au_ga_AUSGeoid2020_20180201.tif" -t_srs "+proj=utm +zone=54 +south +ellps=GRS80 +units=m +no_defs" input.tif output1.tif

gdaladdo -r average output1.tif -ro


gdal_translate output1.tif output2.tif -co COMPRESS=LZW -co BIGTIFF=YES -stats -co TILED=YES -co COPY_SRC_OVERVIEWS=YES -a_srs epsg:7855

original file is 169mo

output2 file is 324mo

I also get a funny message I never seen before when copying the overviews:

Warning 1: General options of gdal_translate make the COPY_SRC_OVERVIEWS creation option ineffective as they hide the overviews in the last command.
Leo
  • 701
  • 3
  • 11
  • Why do you need -a_srs for the gdal_translate? – bugmenot123 Apr 22 '22 at 07:05
  • -a_srs is needed because otherwise the output from gdalwarp doesn't get projected properly. Can be interpreted as WGS84 + UTM, or it gets projected in Antarctica or Papua new guinea depending if it is UTM zone 54 or 55 – Leo Apr 22 '22 at 07:13
  • 1
    Does warping increase the image size in pixels as well? – user30184 Apr 22 '22 at 07:22
  • You could skip also creating an intermediate tif then build overviews on the final output tif. – user2856 Apr 22 '22 at 07:22
  • the image size does get affected a little bit from 1m cell to 0.999967. Fixed by adding -tr 1 1. The extent do get moved a little bit, fixed with -tap, but it adds an extra pixel row/column to the whole COG. – Leo Apr 22 '22 at 07:30
  • yes the virtual outputs and pipe is a nice idea https://gis.stackexchange.com/questions/89444/file-size-inflation-normal-with-gdalwarp/89549#89549 thanks. – Leo Apr 22 '22 at 07:30
  • I meant the size that gdalinfo reports like Size is 12000, 12000. Warping tends to rotate the image and make the bbox larger. – user30184 Apr 22 '22 at 07:43
  • in this case the warping doesn't affect the size no. 90008000 for the original. 90018001 for the output – Leo Apr 22 '22 at 07:47
  • 1
    You seem to create uncompressed overviews. Try to compress them as well with --config COMPRESS_OVERVIEW LZW. – user30184 Apr 22 '22 at 10:24

2 Answers2

1

Your original might have used different compression options such as a predictor.

Try this (if your values are floats, otherwise use PREDICTOR=2):

gdal_translate output1.tif output2.tif -co COMPRESS=LZW -co PREDICTOR=3 -co BIGTIFF=YES -stats -co TILED=YES -co COPY_SRC_OVERVIEWS=YES -a_srs epsg:7855

Also the overviews will add roughly 1/3 to the file size, maybe your original did not have any? I am not sure why you create them before the gdal_translate, I'd just do the gdaladdo last.

bugmenot123
  • 11,011
  • 3
  • 34
  • 69
  • The original was processed from 1km tiles via a virtual mosaic and txt file inputing all the tifs. The original has the same -co COMPRESS=LZW, I didn't use predictor. My values are floats. This did bring down the filesize to 218mo, but it is still way above the original. The original did have overviews. I do the overviews before to be able to embed them when using gdal_translate. – Leo Apr 22 '22 at 07:16
  • What is the benefit of running gdaladdo first and gdal_translate then and not in another order? – user30184 Apr 22 '22 at 10:29
  • I just prefer doing them last to make sure they really reference the final raster. User error happens easily. – bugmenot123 Apr 26 '22 at 07:34
0

Thanks to all your feedbacks. The culprit was simply precision and number of digits. gdal_translate doesn't seem to change decimals (i.e.: 2 digits stay as 2 digits) gdalwarp does bring more digits than the input, hence why even using the same compression the filesize can vary. (2digits as input -> 5digits in mosaics)

Leo
  • 701
  • 3
  • 11