Question concerning Terrain-Correction


While using SNAP’s Range Doppler Terrain Correction, I encountered a problem directly linked to this problem: Problem with complex Range Doppler Terrain Correction.

I have corrected a TerraSAR-X SLC data by choosing a pixel spacing of 3 meters. I thus obtain a pixel spacing in degrees of 2.6994… 10^-5 according to the conversion formula given in the SNAP help. From my experience with gpt, I know that this is the value used to do the terrain correction.

The metadata of the resulting product shows the values for pixel spacing in meters, and degrees are the ones I selected.

I then created a subset of this image of size 1000x1000.


By projecting it on Google Earth, we can see that the size in latitude is about 3000 meters as expected, but only about 2000 meters in longitude.

Therefore, the pixel spacing is not three by three but more like three by two. I understand that this is due to the use of pixel spacing in degrees, as the conversion that gives 3 meters for 2.6994… 10^-5 degrees is only true for latitude or longitude at the equator. For the longitude you have to do pixelSpacinginMeterCorrected=pixelSpacinginDegreePolarEarthRadiusPI/180cos(latitudepi/180). By applying this formula, I find 1.9812 meters, which is close to the value measured on Google Earth.

Would it be possible to modify the information in the metadata to display a corrected spacing? Also, how can I get square pixels of 3 meters by 3 meters?

Thank you in advance for your help,


Couldn’t it just be the reprojection to WGS84 which makes the x and y direction inconsistent?
What happens when you set UTM as output coordinate system and open the data in a GIS? I expect the result to be squared. Maybe I’m thinking too simple.

Dear Abraun,

You are right, I tried to do the same process selecting UTM as Map Projection and this time, my pixels were squared, 3 meters by 3 meters.

So everything works as expected, but maybe it would be worth adding the information somewhere that, depending on the selected Map projection, the final pixel spacing will be the one written in meter or degree. I think that intuitively one would use the pixel spacing in meters, and the default Map Projection is WGS84, so it does not work as intended. For example, I struggled to understand why the same 6-meters wide road was 2 pixels wide when going from north to south but 3 pixels wide when going from west to east.

Regardless of the Map Projection used, both Terrain-Corrected product metadata give 3m for range and azimuth spacing and 2.6949458523585646E-5 degrees for lat_pixel_res and lon_pixel_res. I would expect a different azimuth spacing using WGS84 and a different lon_pixel_res using UTM. I also think the use of the name “range_spacing” and “azimuth_spacing” can be confusing once the Terrain-Correction is realised and could be replaced by “latitude_spacing” and “longitude_spacing” if I make no mistake.

Thank you for your help,


Well, the unit of WGS84 (geographic coordinates) is degrees. And as these refer to the globe, their spacing in x direction differs depending on the latitude.

Sorry to ask - but why?
I agree about the terminology. But as you say: Azimuth and range spacing are technically different from latitude and longitude spacing, that’s why we need to define resampling technique.