According to Sen2-Agri_SUM (Software User Manual) demmaccs.py can be run wtith –prev-l2a-tiles and –prev-products-paths arguments which allow to refine results by using already corrected scenes during atmospheric correction procedure.
I managed to run a script from a command line without these parameters and produced a single scene output but wasn’t able to successfully execute the procedure with the usage of already existing L2A products. The user manual example doesn’t include –prev-l2a[…] arguments.
I tried to add three existing L2A products to the command with products and paths separated by spaces but running the full command returned “too few arguments” error:
I think the –prev-l2a-tiles flag expects only the tile identifier, in your case 33UXT. The two flags need to be the same length, so for –prev-l2a-products-paths you only need to specify the temporally previous product with the same tile/orbit combination.
Here are some excepts from an e-mail conversation I had on this topic with Laurentiu, which might help:
To run NOMINAL mode, do I just feed the path of the closest previous file in time to the --prev-l2a-products-paths flag in demmacs.py? E.g. if I have a timeseries A - B - C, and I want to process B, I’m assuming the previous product should be A, even though C might be temporally closer?
MACCS passes information from A to B, then to C, so to process B you need A.
The “previous tile” should be the previous combination of (tile ID, orbit ID) to avoid some artifacts.
So when you say the previous “tile” is a combination of tileID and orbitID, it should be sufficient to filter all available processed products for that and then take the closest file prior to the one which is being processed, regardless i it’s S2A or S2B, right?
Yes, as far as I know. It’s what the system currently does, at least.
How would I handle files with the OPER convention? Assuming there are multiple tiles within an OPER file, do I need to identify a OPER file with the same tiles for NOMINAL mode?
Yes. The script has two list arguments, --prev-l2a-tiles and --prev-l2a-products-paths. They need to be the same length. The first one is a list of previous tile IDs and the second one is a list of paths to the older products containing them. If a tile in the current product is missing from those lists, it will be processed in the INIT mode.
Note that the script processes all tiles in a directory, and has no filtering by tile ID functionality, which makes it a bit harder to run in parallel. You’ll probably want to make some symlinks instead.
To sum it up, when you process the “new” tiled products (in contrast to the “old” OPER ones) you can just pass the tile ID to –prev-l2a-tiles and the respective path of the product with the same tile and orbit ID to –prev-l2a-products-paths.
If you look at the logs generated by the automatic maccs processing, that’s exactly what happens.
Thanks a lot for your answer, it helped me to start the process but I also had to switch input and output positions with –prev-l2a-tiles and –prev-l2a-products-paths parameters in the command to be run.
From logs found in maccs product folders it seems that only a single already processed tile is used during the atmospheric correction procedure. Am I understand it correctly? How to select the best previous date from a list of available tiles?
And to clarify this topic - should I select a scene with a smallest time difference in regard to the scene I want to process without taking e.g. cloud coverage into account?
For example:
available scene - 10.04 (20% cloud coverage)
available scene - 25.04 (70% cloud coverage)
scene to be processed - 01.05
Wouldn’t it be better to use 10.04 scene as –prev-l2a-tiles argument? Do we know the logic of MACCS processor regarding already processed scenes?
Thanks again for your valuable input!
As far as I know, the logic behind selecting a previous acquisition is to get multi-temporal information for cloud detection (and maybe other variables for the atmospheric correction). This is why you should select the previous acquisition of the same geometry, irrespective of cloud coverage.
If your aim is to replicate the behavior of the Sen2Agri-system, just with manual execution of the L2 processing, this is the approach you should take.
If you want to improve or discuss the method behind it, or the way Sen2Agri uses the MACCS processor, you should take it up with the devs of either MACCS or Sen2Agri.
I, for my part, just replicate what Sen2Agri does, and honestly I’m not sure doing it differently would have a great impact anyways.
Ok, great, thx for the explanation! My goal is precisely to manually replicate some of the Sen2-agri system procedures outside of the installed system and have it prepared as a ‘backup’ solution because after testing Sen2-agri for some time already I don’t feel the system (v.1.8.3) behaves stable and operational in my environment.