/ by zero error and SARSim-Terrain-Correction error during graph building with TerraSAR-X data

Microwave Toolbox Problem Reports
#1

Halo Members,
I am working with with RapidEye and TSX images therefore need for one coordinate system. My SNAP processing chain has the steps:“Read - SAR-Simulation - GCP-Selection - SARSim-Terrain-Correction - LinearTodB - Write” I am however facing some challenges.

  1. Upon using the predefined CRS (EPSG:4326-WGS 84), I get the “/ by zero” error. I do not get this error when using SNAP’s default coordinate system. I have tried unchecking the zero values tab on the image properties of the loaded images, but this does not seem to work
  2. When trying to write the output file, I get the error “SARSim-Terrain-Correction: please select output band for terrain corrected image”. On going back to the SARSim-Terrain-Correction tab, the “Apply radiometric normalization” tab is inactive

I would appreciate your contributions towards this step

Kuria

“/by zero error” occurs in Terrain-correction(EPSG:4326)
#2

Hi there,
this doesn’t solve the problem but also occurs with ALOS PALSAR data and the Range-Doppler Terrain Correction. You might also have noticed the irrational pixel spacing numbers which are way too high.
Happens independent from reference system and input processing so it might be a bug. I just tried it in NEST (ALOS Deskewing and then Terrain Correction) and it worked.

#3

I’m coming across the exact same error in SNAP5. In my case, I have a TerraSAR-X image that I’m trying to Terrain-correct using a LiDAR DTM of that same area (South-West England).

Similarly to the question asked, I’ve switched from the default projection to EPSG:4326 during the terrain-correction, because I have reprojected myLiDAR DTM to this projection. And I reprojected my LiDAR DTM to EPSG:4326 in QGIS, when I’ve noticed that GDAL didn’t recognize the projection of a stack I created by a coregistration of a LiDAR DSM with terrain-corrected TerraSAR-X images.

Is it a known bug, or am I just doing something wrong in my graph.xml (4.2 KB) ?

#4

I’m also seeing the “/ by zero” exception, when I try to run the Ellipsoid-Correction-RD operator using gpt.
How do I debug this?

#5

Are there any options in the gpt mode for this tool?

#6

I was able to get around this by specifying the full WKT string for the projection.

Normally I would just specify -PmapProjection=EPSG:3413 and it works, but for some reason I consistently get a “/ by zero” error when I try it with EPSG:4326.
However, it works if I specify the mapProjection string as:

GEOGCS[“WGS84(DD)”,
DATUM[“WGS84”,
SPHEROID[“WGS84”, 6378137.0, 298.257223563]],
PRIMEM[“Greenwich”, 0.0],
UNIT[“degree”, 0.017453292519943295],
AXIS[“Geodetic longitude”, EAST],
AXIS[“Geodetic latitude”, NORTH]]

I would have thought the two should do the same thing?