Geolocation inaccuracy

[aluhamaa]

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>

[ghajduch]

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

[aluhamaa]

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

[aluhamaa]

@marpet Is there a way to get confirmation somewhere if this problem is considered as a bug that gets attention by someone? From the issue reporting page I read that forum is the place to describe problems, and then they are taken to the issue tracker, but I cannot find it in the issue tracker yet Sentinel-1 Toolbox - Issues - JIRA

Best regards
Andres

[marpet]

Hi aluhamaa,

yes, the procedure you are describing is correct.
Except the issue [SITBX-921] Range-Doppler Terrain Correction raster size and coordinates inconsistency - JIRA (atlassian.net) which is referenced in the other thread you have mentioned it is not yet considered as an issue in JIRA.

Sorry, I’m not a SAR expert, so I do not fully understand what you have wrote before.
It seems it is not yet clear if the issue is with SNAP or with the DEM data, right?
Does the shift in geolocation vary or is the shift constant all over the scene?

@jun_lu @lveci can you check what causes the issue and create a ticket for it?
Thanks

[aluhamaa]

Hi @marpet
Thanks for quick feedback. From what I understand, the problem is more likely in SNAP.
The easiest way to illustrate the problem is that I get different location for surface object, depending on the size of data that I process. If I process only one burst (1/9’th of data), the surface seems more close to map than when I process the whole subswath.

Best
Andres