I am evaluating utility of different DEM datasets for topographic correction in Sen2Cor.
Some time ago I noticed that the default for Sen2Cor CGIAR-CSI DEM does not ensure sufficient correction, especially for complex mountain environment, therefore I decided to investigate the problem in details.
I run Sen2Cor assuming:
flat surface (no correction)
using default CGIAR-CSI DEM (90m)
using SRTM arc 1 V3 (30m)
using high resolution DEM (10m)
using high resolution DEM (10m) filtered beforehand with mean filter, kernel 3x3
using high resolution DEM (10m) filtered beforehand with mean filter, kernel 5x5
using high resolution DEM (10m) filtered beforehand with mean filter, kernel 7x7
using high resolution DEM (10m) filtered beforehand with mean filter, kernel 9x9
using high resolution DEM (10m) filtered beforehand with mean filter, kernel 11x11
What I noticed (visual comparison) is that Sen2Cor under-corrects when run on CGIAR-CSI (2), but overcorrects when HR DEM is used. The effect of overcorrection decreases with and increase of the window of the mean filter. Apparently, visually the best results are achieved when SRTM 1 arc V1 at 30m resolution is used. I know that Sen2Cor converts a given DEM to 20m resolution )I have no idea which algorithm is used for this process, any clues?!),
I am wondering whether Anyone had similar experience.
Please find below a comparison of all 9 scenes (8,4,3)(mid latitude, end of March conditions). I am aware that snow can give a false impression, but lee slopes are in this case snow-free, and after topographic correction they appear much brighter (please see figure sections 1 and 3-9)
Hello Ferdinand,
(sorry for answering from my other account, to post my question I accidentally logged with my GitHub account, and then was not able to delete the thread and post it with this account…)
You are right, that user manual does not explain it straightforwardly how to use other DEMs than SGIAR and Planet… but there are some publications which describe use of Sen2Cor with ASTER DEM or others. No idea how they implemented high resolution DEMs to Sen2Cor, but my ‘trick’ is rather simple. You just need to have your desired DEM clipped to the SGIAR-CSI tile(s) and named according to SGIAR-CSI naming convention (tiff format). Then in the GIPP.xml point your DEM_Directory to the folder comprising the DEM.
Unfortunately I am not able to identify how the DEM is processed in Sen2Cor, so right now it is a bit of a ‘black-box’… hence my question to the community.
This approach is not ideal, but I hope it will help you.
[I am running the latest stand alone Sen2Cor-2.4.0-win64. I did not test it with the previous Anaconda-based releases]
@erfea,
Hello erfea,
You had evaluated utility of different DEM datasets for topographic correction in Sen2cor.
Now I have two questions for you, and I earnestly hope that you can guide me.
The first one is that how to edit configuration files L2A_GIPP.xml? I had modified the file L2A_GIPP.xml, such as,
DEM_Directory>DEM
Cirrus_Correction>True
BRDF_Correction>1
But the results are without eliminating the topographic effects.
If we need get terrain data, such as slope,aspect, and a hill shadow map with Atcor3?
The sencond question is that how to prepare our high resolution DEM, which needconsider the factor 10000? Thank you! ?
My solution works for Sen2Cor-2.4.0-win64. I have not had time to test it for the latest release.
In my approach, I preprocessed my HR DEM to cgiar-cis tiles extend and saved them as tiffs, following the cgiar-cis naming convention. I simply took the srtm 1 arc datasets, mosaiced them into one image and subsequently created subsets for each cgiar-cis tile I needed. No rescalling was applied, input was in meters (integer). As a result I got the files with the same geographical extend as the default DEM tiles, but enhanced spatial resolution. You may use this repository http://dwtkns.com/srtm/ to grab your tiles and get naming convention right.
From what I understand, Sen2Cor uses LUT to associate geographical extend of your S2 scene with the DEM tile needed for its topographic correction. So this ‘trick’ feeds desired data into Sen2Cor without any further code modification. I believe there is much more elegant way to run topographic correction on HR DEM in Sen2Cor, but I am not a Python programmer (at least not yet).
What one needs to do is to next is to adjust the <DEM_Directory> parameter, to point to the directory where the HR DEM is stored
<DEM_Directory>C:/data/HR_DEM/srtm1arc/tiles</DEM_Directory>
Slope, aspect and hill shadow are calculated on the fly, and then deleted once the tile is processed, so from the user perspective nothing more than DEM tile is needed.
I hope it will help you! Please let me know how it goes!
P.S. you can use the Sen2Cor processing log to see which DEM has been used (if any) and understand where a problem occurs.
@erfea,
Hello erfea,
Thank you very much for your prompt reply.
My solution works for Sen2Cor-02.05.05-win64. I moscic many DEM(30m) files into one file with the same geographical extend as the default DEM(90m) tiles. But there is an error as follow(a picture):
sorry, Python is a bit outside my competences… but I will try my best:
are you able to run the correction with the default DEM? Because if not, then I would say that your GDAL is not correctly incorporated… although it should be coming with the stand alone version. From my previous experiences, if you have multiple GDAL installed (stand Alone, QGIS, Sen2Cor, sometimes there is confusion in the system paths. You may want to check it…
However, if the problem occurs only with your HR DEM, then please check data type, name and coordinates of your 30m DEM (which you most probably did already). From your description I assume the HR file should be just fine…
Fingers crossed!
@erfea,
Hello erfea,
Thank you for your kindly reply!
The SEN2COR can run normally with the default DEM. I also think the problem may be in the data type of the high resoluton DEM. I had mosaiced the HR DEM with ENVI softwarve, and the name, geotiff, and the coordinates are all same with defailt DEM.Thank you for your suggestion, and I will check data type further.
From what you write, your preprocessing approach is exactly the same as mine, software including.
So the problem is evidently dataset-related. The last thing which is coming to my mind is the size of the HR dataset is slightly smaller (1, 2 lines). You may wish to rerun subsetting, including layerstacking of your HR mosiac and desired DEM tile in the processing flow (inclusive). I came across this issue for few tiles featuring ocean/seas.
At this point nothing else is coming to my mind…
