Continuing the discussion from Sentinel-1A data preprocessing:
What is the recommended preprocessing chain, for performing radiometric and geometric terrain correction with the toolbox? In particular, which of these two alternatives is preferred:
Calibrate → Radiometric Terrain Flattening → SAR-Simulation Terrain Correction
-vs-
Calibrate → SAR-Simulation Terrain Correction (with Apply radiometric normalization)
?
The second pathway only produces Java null pointer exceptions. However, the first pathway seems inefficient because it computes the SAR-Simulation twice (once for the radiometric flattening, and again as a sub-stage of the geometric correction); these two simulations have quite different pixel-values; and only the second of these stages has the benefit of warping or cross-correlating (enhancing alignment between the SAR and DEM but not for radiosity).
I’m wondering how these tools are intended to best be used. It would be great if there was a tutorial somewhere for preparing batches of S-1A data for mosaicing, land cover mapping, etc. For example, are there any further steps recommended, other than Remove GRD Border Noise and Thermal Noise Removal?
I too am interested in pointers on what processing flow is recommended for terrain correction. Specifically, what does terrain flattening do? How does it differ from terrain correction? It seems that the two steps are complementary, but it is not clear that is the case.
There seem to be two options for orthorectification (geometric correction for terrain, so that the pixel corresponds to the observed place on a map). These are the range-doppler and SAR Simulation methods. (I’m ignoring any additional methods that may be available for optical imagery, as the algorithms for SAR differ in needing to adjust for the time lag between transmitting and receiving the signal.) Range-doppler simply does the trigonometry, relying on precise orbital vectors (and elevation model). The simulation method has an extra step of coregistering the real data to align with synthetic data (so it should give self-consistent results even if the orbital vectors are imprecise). For Sentinel 1A, the most accurate method is reported to be range-doppler.
The terrain flattening (radiometric-only correction for terrain, so that surfaces facing the satellite appear the same brightness as they would if they was sloping in another direction) works if it is applied before range doppler. It seems incompatible with the SAR simulation method (because the flattening eliminates precisely the same signal features that are needed for the cross-correlation, to adjust the alignment).
Using separate operators for radiometric and geometric corrections seems kind of inefficient (e.g. flattening inherently involves simulating SAR in some way as well). Instead, the geometric correction operators have options to simultaneously perform radiometric normalisations. (For the SAR Sim method there were bugs in SNAP 2.0.2 which seem to be resolved in the latest source code.) However, it looked to me as if flattening was giving a much better (and very different) result compared to the normalisation, presumably due to attempting to implement a more sophisticated algorithm from the literature.
4 Likes
If using an external DEM (or DSM), another crucial step is to subset the DEM beforehand. Greatly increases CPU utilisation, reduces IO and memory consumption, and speeds up the entire process. (Ideally internal caching and chunking ought to make this step superfluous, but in the meantime it is something important for users to be aware of.)
2 Likes
@benjimin, this was very useful answers !
Do you have any reference to support the superiority of the RD-TC over the SARsim? Furthermore, is it recommended to apply a Terrain flattening before use?
In other threads it has been mentioned that SARsim should perform better self-consistent time-series alignment thanks to the correlation with the DEM. You mentioned that SARsim might limit orbits imprecisions. What’s your input on that point? If it has an important impact, is there any automatic way to register a time-series on SNAP after RD-TC?
Thanking you in advance for your inputs !
Yes, Bayanuddin and Sambodo reported finding Range-Doppler preferable to SARSimTC, for Sentinel 1. (But it does seem plausible that SARSimTC could be more self-consistent over time, and especially if not downloading precise orbital data. Which threads were you referring to?)
However, it looked to me as if flattening was giving a much better (and
very different) result compared to the normalisation, presumably due to
attempting to implement a more sophisticated algorithm from the
literature.
Do you have any topics or paper supporting this one as well? If yes, I’ll change my processing chain and reprocess my 120 images… But this will last more than a week so I would like to be sure that Terrain Flattening is better than normalization.
I was referring to this and this threads but after re-reading seems that it’s not that much reliable.
Have you tried different methods on a single scene (with significant terrain) for your own comparison? I’ll be very interested to hear what you find. Also, have you read Small’s paper (cited in the Flattening operator documentation)?