Offset tracking

[ABraun]

I would strongly disadvise of using terrain corrected products for the offset tracking, becuase these have already been resampled so the estimation of offsets after the fine coregistration can no longer be conducted reliably.

[qinghuise]

That is to say, we can’t use the GRD of GEE to calculate large-scale velocity to reduce a lot of time consumption. Maybe I should find another computing platform. Thank you very much.

[SUN-Ravenclaw]

@ABraun @qglaude I found a formula from the link below that it is possible to convert ground range displacement to slant range. I don’t know if this method is feasible, because most of the papers use 2 or more SAR data to solve 3D deformation.

Offset Tracking : SLC vs GRDH products

Ok thanks. I understand now. That was my hypothesis too. It would implies that to get the velocity in the ground range direction, it only requires the simple operation : Velocity_slv1_DDMMYYYY / sin(rad(incident_angle)) [SRGR] But when I do it, the velocity is significantly overestimated In conclusion I have two remarks : It is a bit strange to be able to use detected SLC image in azimuth / slant-range geometry even if it produces wrong results. I know that the tutorial uses GRD images…

[qglaude]

Careful that this “formula” has the hypothesis that the detected displacement is a priori purely horizontal

[SUN-Ravenclaw]

Okay, I get it.

[ABraun]

I agree. It might restore the slant geometry, but the pixel values are already changed.

[SUN-Ravenclaw]

Why does my tutor insist that the offsets tracking operator in SNAP is used to calculate the slant range and azimuth offsets instead of ground range and azimuth offsets. (He told me he asked the SNAP developers.)

[ABraun]

slant range data shows the pixel in their original form. After conversion to ground range, they are resampled to a new spatial resolution which can already suppress some of the information which is required to identify offsets at the sub-pixel level.

@qglaude can probably think of some more reasons why sticking to SLC makes sense.

[qglaude]

@ABraun

@qglaude can probably think of some more reasons why sticking to SLC makes sense.

It’s not mandatory, but I see two reasons for doing this:

1. Going from SLC to GRD reduces the speckle (see quotation here-below from Sentienl official website). Offset tracking becomes more like an “feature-tracking” than a “speckle tracking” operator. While results from SNAP offset tracking can produce very interesting results, it does not exploit the full potential of the determinist characteristics of the speckle in SAR image, so useful in speckle tracking studies. That’s a reason why offset tracking from SAR images always gives better results than optical images (Remote sensing of ice motion in Antarctica – A review).

Level-1 Ground Range Detected (GRD) products consist of focused SAR data that has been detected, multi-looked and projected to ground range using the Earth ellipsoid model WGS84. […] The resulting product has approximately square resolution pixels and square pixel spacing with reduced speckle at a cost of reduced spatial resolution.

2. GRDH products drastically reduce the range image resolution (by a factor of 4). Since the offset tracking’s precision is linearly dependent on the resolution, using GRD instead of SLC is 4 times less precise.

The flip side is the that it requires more “steps” in SNAP to perform offset-tracking using SLC data. Moreover, depending on your context, you may not need this, and a feature-tracking approach can be more than enough. Finally, the displacements from SLC data are computed in the range direction, requiring some care if we’re interested in horizontal displacements analysis.

Hope it clarifies.

Quentin

[kang]

Hi，first thank for your contributions in this forum that i learn a lot, i Just get started with sentinel1 data to estimate glacier velocity that i have some questions, could you help me, thank you.
1.is that SLC is better than GRD products in estimating velocity ,which has more information
2.if yes, could i preprocess SLC products,and then convert to GRD ,because i found a step forum using GRD products to estimate glacier velocity.
3. if not.could i use SLC products directly download from website data
thanks in advance,thanks again.

[Lemo]

Dear Eric,

is ISCE2 helpful in applying inSAR for the measurement of Sand Dune movement? if the answer is Yes, which mode is better to choose? often I hear that ISCE2 is for Geological events such as earthquakes and volcanoes. The last thing, is there a specific function or tool in ISCE2 for process (POT) as SNAP has?

[EJFielding]

The InSAR phase method is not useful for measuring sand dune movement because the sand motion makes the interferogram incoherent. Moving sand areas are noticeable on InSAR because of the complete loss of coherence.

The pixel offset tracking method can be used to track sand dune movement because it uses only the amplitude of the SAR or optical image. The ISCE2 package has an optional function called “dense offsets” that does pixel offset tracking and is included in most of the InSAR processing applications. ISCE2 is designed to start from SLC or raw SAR images, and it does the image co-registration first before performing the “dense offsets” step to get better results.

[Lemo]

…So to make sure!, in general, using InSAR to track Sand Dune Movement is not that significant way even if we use ISCE2?

[EJFielding]

You cannot use InSAR (phase) measurements for sand dune movement as the moving sand will be incoherent. Pixel offset tracking with SAR might work.

[dgt]

Hello, I’m doing SNAP software’s offset tracking to extract ice flow rate for timing analysis, I have enough ice flow rate products, I would like to know what is included in this ice flow rate product, can you elaborate on it. Below is an interface for the Ice Flow product.