geographical area of geotiff file does not have the correct number of columns

[rrabin]

Hello!
I am using the beta release of geo2grid from July 18th 2022 (geo2grid-swbundle-20220718-201315).
When executing the following command:

"geo2grid.sh -r abi_l1b -w binary -p C13 -g my_latlon --grid-configs /apollo/awg_imagery/rabin/CSPP/geo2grid_v_1_0_2/grid_configs/grid_example.conf --no-enhance -f $file2"
where file2=OR_ABI-L1b-RadM1-M6C13 _G16_s20222562118251_e20222562118320_c20222562118360.nc
"my_latlon" is defined as follows in grid_configs as follows:
my_latlon, proj4, +proj=latlong +datum=WGS84 +ellps=WGS84 +no_def
s, None, None, 0.02, -0.02, None, None

The spatial coverage of the output file "GOES-16_ABI_RadM1_C13_20220914_015825_my_latlon.tif" appears to be too small in the expected number of columns. When displaying the tif file, the eastern portion of the image is cut off.
The log file shows:
"Number of columns: 742, Number of rows: 725
Area extent: (-80.0202, 34.9229, -65.1826, 49.429)"
Given this area extent and .02 deg/per column and row, the number of columns should be 1252 (not 742). The log file is attached.

When executing "add_coastlines.sh" with the same tif file as input:
add_coastlines.sh --add-coastlines --add-borders --borders-resolution=h --add-grid --grid-D 1.0 1.0 GOES-16_ABI_RadM1_C13_20220914_015825_my_latlon.tif

The output png file, "GOES-16_ABI_RadM1_C13_2
0220913_211825_my_latlon.png" appears to have the correct number of columns. Unlike the input tif file, the png image includes the entire expected area (extending to -65 deg longitude). See attached figures.

file.png (475.44 KiB) Viewed 21886 times

image.tif (352.68 KiB) Viewed 21886 times

image.tif (352.68 KiB) Viewed 21886 times

Any help diagnosing the problem would be appreciated.

Thanks! -Bob

[kathys]

Hi Bob,

We are not able to view or download the tif files that you reference (2 image.tif files). Can you make separate names for the files and place them somewhere that we can access them? For instance on the center /pub/incoming site?

Thank you,

Kathy

[rrabin]

Hi Kathy,

I just posted image.tif on ftp.ssec.wisc.edu/pub/incoming

Thanks! -Bob

[davidh]

Hi,

When opening the geotiff with image magick (`display image.tif`) it looks as expected. See attached screenshot. I'm on an Ubuntu system and when I use another image viewer called gwenview I do get weird artifacts on the right half of the image. From my experience this is because gwenview doesn't properly support tiled geotiffs. What image viewer are you using?

You could test this tiling hypothesis out by providing `--no-tiled` to Geo2Grid which should produce a striped (not tiled) geotiff and may behave better with your image viewer.

Also, about the size and extents, the size of the PNG produced by add_coastlines.sh is the same as the geotiff (742 columns by 725 rows). Doing the calculation with the extents listed in your log this seems correct to me:

Code: Select all

In [1]: extents = (-80.0202, 34.9229, -65.1826, 49.429)

In [2]: extents[2] - extents[0]
Out[2]: 14.837600000000009

In [3]: (extents[2] - extents[0]) / 0.02
Out[3]: 741.8800000000005

Good luck.

Dave

[rrabin]

Hi Dave,

Thank you for addressing my post.

I am a bit puzzled about the image plot of image.tif. It looks different when I plot it on my Ubuntu machine. I've attached a screenshot of the plot (with ImageMagick).

You are correct about the dimensions (725x742). I had made a simple error in my calculation from the longitude bounds.

Thanks! -Bob

Screenshot_image.png (305.17 KiB) Viewed 21856 times

[rrabin]

Dave,

I just plotted image.tif on the Linux computer "imaginator" with the display command.

The result is identical to that shown in my previous post. I'm not sure why these are different than your plot.

Thanks! -Bob

[davidh]

Bob,

I went hunting and surprisingly found the issue. First, the issue definitely seems to be due to the tiling of the data in the geotiff. That `--no-tiled` option should disable this and make more image viewers support the imagery, but will make much larger geotiffs as they won't compress as well (this is "tiled" versus "striped" TIFF images).

The main difference between my machine and your others is the version of imagemagick:

Code: Select all

$ display -version
Version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP(4.5)
Delegates (built-in): bzlib djvu fftw fontconfig freetype heic jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png tiff webp wmf x xml zlib

On imaginator:

Code: Select all

$ display -version
Version: ImageMagick 6.9.10-68 Q16 x86_64 2021-10-14 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP(3.1)
Delegates (built-in): bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms ltdl lzma openexr pangocairo png ps rsvg tiff wmf x xml zlib

So my machine has 6.9.11-60, imaginator has 6.9.10-68. I got curious so I actually downloaded the ImageMagick source code and it looks like this behavior was fixed in version 6.9.10-88 where support for 32-bit TIFF tiles was added. For my own future reference, this was fixed in this git commit:

https://github.com/ImageMagick/ImageMag ... 85640a4d84

Another option is to convert the tiled geotiffs to a striped geotiff after the fact by doing:

Code: Select all

gdal_translate -of GTIFF -co TILED=no input.tif output.tif

Sorry that this might not be the perfect answer you were hoping for, but at least we have an idea what happened.

Dave

[rrabin]

Hi Dave,

Thanks for digging into the problem and providing a couple ways to get the correct image!

Best regards,

-Bob