GDAL writer georeferencing bug

Microwave Toolbox Problem Reports
#1

Hi, Using GPT with either graph or write to a geotiff with driver ‘GDAL-GTiff-writer’ results in a proper geotiff with wrong georeferencing: here the results of gdalinfo:

gdalinfo S1A_IW_GRDH_1SDV_171110T174348_TC4.tif
Driver: GTiff/GeoTIFF
Files: S1A_IW_GRDH_1SDV_171110T174348_TC4.tif
Size is 55340, 21215
Coordinate System is:
GEOGCRS[“WGS 84”,
DATUM[“World Geodetic System 1984”,
ELLIPSOID[“WGS 84”,6378137,298.257223563,
LENGTHUNIT[“metre”,1]]],
PRIMEM[“Greenwich”,0,
ANGLEUNIT[“degree”,0.0174532925199433]],
CS[ellipsoidal,2],
AXIS[“geodetic latitude (Lat)”,north,
ORDER[1],
ANGLEUNIT[“degree”,0.0174532925199433]],
AXIS[“geodetic longitude (Lon)”,east,
ORDER[2],
ANGLEUNIT[“degree”,0.0174532925199433]],
USAGE[
SCOPE[“unknown”],
AREA[“World”],
BBOX[-90,-180,90,180]],
ID[“EPSG”,4326]]
Data axis to CRS axis mapping: 2,1
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0,21215.0)
Upper Right (55340.0, 0.0)
Lower Right (55340.0,21215.0)
Center (27670.0,10607.5)
Band 1 Block=55340x1 Type=Float32, ColorInterp=Gray
Band 2 Block=55340x1 Type=Float32, ColorInterp=Undefined

NOTE, the corner coordinates were not transferred/mapped properly.

After scanning the forum, I came across this for the S2tbx:

I wonder if this is the same problem for the S1tbx? If so, will there be a fix there as well? Also interested in using gdaloptions for compression and nodata etc…

Thanks so much

1 Like
#2

I seem to have a similar issue. The conversion produces a viable GeoTIFF that seems to be well collocated in SNAP. However, I am using gdal and opencv to open, filter and write a new GeoTIFF. The filtered product should be inheriting the transformation and projection of the initial product saved from SNAP, but when I open it again, the projection parameters are quite messed up and it looks like the GDAL method does not correctly identify information in the initial metadata for correctly copying corner coordinates. Did you find any solution?

#3

No, I have not found a solution. I have used a workaround for now. I write the data out in native Beam-DIMAP, and then build a VRT (gdalBuildVRT) on the original .img files in the data folder. The drawback on doing it this way is the large data size as I would have preferred to have some compression on the files to save a bit of diskspace. Does anyone know of compression capabilities of BEAM-DIMAP, or possibilities of setting a nodatavalue for this format? Otherwise, I guess one can also build a geotiff with compression from the vrt , but this just adds an additional step in my pipeline so I have not done this (yet)…

1 Like
#4

My simple workaround idea was to try to overwrite the band in the original file. Not elegant, but should keep the tie points info in the metadata. It seems that only SNAP needs them.

For my current application I don’t necessarily need to have a geospatial reference as I am mostly looking at image statistics, but would be useful to have workaround after I pass this step.

#5

Hello,
These issues are fixed for SNAP 8 (the next release).

2 Likes