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.
Improve this question
9
  • Why do you need -a_srs for the gdal_translate?
    – bugmenot123
    Commented Apr 22, 2022 at 7: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
    Commented Apr 22, 2022 at 7:13
  • 1
    Does warping increase the image size in pixels as well?
    – user30184
    Commented Apr 22, 2022 at 7:22
  • You could skip also creating an intermediate tif then build overviews on the final output tif.
    – user2856
    Commented Apr 22, 2022 at 7:22
  • 1
    You seem to create uncompressed overviews. Try to compress them as well with --config COMPRESS_OVERVIEW LZW.
    – user30184
    Commented Apr 22, 2022 at 10:24

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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
    Commented Apr 22, 2022 at 7:16
  • What is the benefit of running gdaladdo first and gdal_translate then and not in another order?
    – user30184
    Commented Apr 22, 2022 at 10:29
  • I just prefer doing them last to make sure they really reference the final raster. User error happens easily.
    – bugmenot123
    Commented Apr 26, 2022 at 7: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)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.