we are trying to conduct an atmospheric correction on sentinel images (Level 1C product) using Sen2cor plugin installed in the SNAP software, to obtain level-2A product at 10m- spatial resolution.
First, we apply the atmo correction without using a DEM (“DEM is not present, flat surface assumed”). No visual artefact appears in level-2A product outputs (see left figure).
Secondly, we apply the atmo correction with using a DEM (SRTM as the default DEM, selected in the L2A_GIPP.xml file). The level-2A products contain visible strips that look likes artefacts. We guess they are due to DTM spatial resolution as it look likes contours lines (see right figure).
Then, we used our own 30m ASTER DEM data, but the results still contain strips …
Consequently we have several questions:
I saw some post saying that using SRTM data can lead to artefact. Do you already obtain similar problem than us?
And do you think it can be due to the spatial resolution of the SRTM data (90 m) (just to be sure that we’re looking in the good direction to find technical solution?)
If “yes”, Which spatial resolution of DEM is suitable for sentinel atmospheric corrections to avoid such strips?
I guess that’s a classical issue encountered with slope correction, on which we also stumbled a few years ago with MACCS. It was easy to solve once we understood what was happening. If the DTM is expressed in meters and coded in integers (I guess it’s the case), then, because the numbers are rounded, a low linear slope looks as a staircase. At each stair, the slope is increased and the slope correction is different, resulting in what you see, with iso-altitude lines appearing in uniform regions.
The solution consists in providing a DTM interpolated in real numbers. As I already told that to Sen2cor developers, I have heard the problem was corrected, but I don’t know if it is already available in the current version, and I don’t know how it is handled.
We have modified the encoding of our DEM (now our DEM is coded in float, not integer), but the same problem remains. We obtain strips in the Level-2A data.
We do not know how to make sure that Sen2Cor generates a slope calculation in float.
Yes indeed, it is a current limitation of Sen2Cor v2.3.0 on areas with gentle slopes.
For information in Sen2Cor the slope computation is performed using the gdaldem routine.
These slopes artefacts will be corrected in next version 2.4.0 to be released this spring.
