Geolocation inaccuracy

Hi

We recently discovered that for some cases, the coastline location in products processed from different RON’s can be significantly different, approximately 60 m in North-South direction. Only when processing data from SLC, using GRD directly looks good.

When looking further, it turned out that the location error is dependent on the size of the processed area: it is bigger when processing the whole sub-swath, but very small or non existent when processing a single burst. In our initial case, both RON’s cover the coastline on the end of swath (burst 8 and 9), so they both have errors on the opposite directions and single product error is not 60m, but half of it.
I have tried SNAP8 and SNAP9, SRTM and Copernicus DEM’s and while the choice of DEM changes the outcome, it is not related to particular location issue.

I have tried to keep the processing as simple as possible. To reproduce the problem, just process the following graph with $burstStart, $burstEnd value choices of 1,9 and 9,9 with input file “S1A_IW_SLC__1SDV_20220430T160451_20220430T160518_043005_052272_1CB6.SAFE.zip” and visualize parts of coastline.

Possibly related topic Range-Doppler Terrain Correction raster size and coordinates inconsistency

In the following screenshots, the brown measurement line is geographically in the same position, data is from two different RON’s, showing the maximum relative difference.


Best regards
Andres Luhamaa

<graph id="Graph">
  <version>1.0</version>
  <node id="TOPSAR-Split">
    <operator>TOPSAR-Split</operator>
    <sources>
     <sourceProduct>$sourceProducts</sourceProduct>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <subswath>IW3</subswath>
      <selectedPolarisations>VH</selectedPolarisations>
      <firstBurstIndex>$burstStart</firstBurstIndex>
      <lastBurstIndex>$burstEnd</lastBurstIndex>
      <wktAoi/>
    </parameters>
  </node>
  <node id="TOPSAR-Deburst">
    <operator>TOPSAR-Deburst</operator>
    <sources>
      <sourceProduct refid="TOPSAR-Split"/>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <selectedPolarisations/>
    </parameters>
  </node>
  <node id="Terrain-Correction">
    <operator>Terrain-Correction</operator>
    <sources>
      <sourceProduct refid="TOPSAR-Deburst"/>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <sourceBands>Intensity_IW3_VH</sourceBands>
      <demName>SRTM 3Sec</demName>
      <externalDEMFile/>
      <externalDEMNoDataValue>0.0</externalDEMNoDataValue>
      <externalDEMApplyEGM>true</externalDEMApplyEGM>
      <demResamplingMethod>BILINEAR_INTERPOLATION</demResamplingMethod>
      <imgResamplingMethod>BILINEAR_INTERPOLATION</imgResamplingMethod>
      <pixelSpacingInMeter>13.84</pixelSpacingInMeter>
      <pixelSpacingInDegree>1.2432683532214177E-4</pixelSpacingInDegree>
      <mapProjection>GEOGCS[&quot;WGS84(DD)&quot;, 
  DATUM[&quot;WGS84&quot;, 
    SPHEROID[&quot;WGS84&quot;, 6378137.0, 298.257223563]], 
  PRIMEM[&quot;Greenwich&quot;, 0.0], 
  UNIT[&quot;degree&quot;, 0.017453292519943295], 
  AXIS[&quot;Geodetic longitude&quot;, EAST], 
  AXIS[&quot;Geodetic latitude&quot;, NORTH]]</mapProjection>
      <alignToStandardGrid>true</alignToStandardGrid>
      <standardGridOriginX>0.0</standardGridOriginX>
      <standardGridOriginY>0.0</standardGridOriginY>
      <nodataValueAtSea>false</nodataValueAtSea>
      <saveDEM>false</saveDEM>
      <saveLatLon>false</saveLatLon>
      <saveIncidenceAngleFromEllipsoid>false</saveIncidenceAngleFromEllipsoid>
      <saveLocalIncidenceAngle>false</saveLocalIncidenceAngle>
      <saveProjectedLocalIncidenceAngle>false</saveProjectedLocalIncidenceAngle>
      <saveSelectedSourceBand>true</saveSelectedSourceBand>
      <saveLayoverShadowMask>false</saveLayoverShadowMask>
      <applyRadiometricNormalization>false</applyRadiometricNormalization>
      <saveSigmaNought>false</saveSigmaNought>
      <saveGammaNought>false</saveGammaNought>
      <saveBetaNought>false</saveBetaNought>
      <incidenceAngleForSigma0>Use projected local incidence angle from DEM</incidenceAngleForSigma0>
      <incidenceAngleForGamma0>Use projected local incidence angle from DEM</incidenceAngleForGamma0>
      <auxFile>Latest Auxiliary File</auxFile>
      <externalAuxFile/>
    </parameters>
  </node>
  <node id="Write">
    <operator>Write</operator>
    <sources>
      <sourceProduct refid="Terrain-Correction"/>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <file>$outfile</file>
      <formatName>GeoTIFF</formatName>
    </parameters>
  </node>
</graph>

1 Like

Hi,
I am always a bit confused about the applicability of DEM on coastline.
On the sea side the height should be close to the geoid (neglecting tide, which should be limited in your case), while on land there may be large variation of terrain height, that are captured by the DEM.
SNAP may probably (this is an hypothesis) interpolate/extrapolate the DEM specified as input with different results depending on the extent of the area under analysis, then using different terrain height on the coastline.

Having a shift in different direction for products in different relative orbit number, makes me think about improper values of terrain height used on the coastline, then inducing shifts more or less on opposite geographic direction for ascending and descending tracks.

One way to test this hypothesis could be to process your data using a geoid model as a DEM.
For instance
https://www.usna.edu/Users/oceano/pguth/md_help/html/egm96.htm

Hi

Thanks for thinking along. DEM was our first suspect, and using different DEM’s create a different final image indeed, but the differences are in the east-west, not north-south, direction.

This particular peninsula is quite shallow and is chosen just because it illustrates the problem visually very well, but the same issue is clearly visible also 50km south from the coast.

I might of course try to test to use the geoid model as DEM, but even if it proves the hypothesis, I will not have the capacity to fix SNAP itself.

Best
Andres