Processing masks in L2PS

[jo-spek]

Is it possible to use processing masks in L2PS in a similar way as in Higher Level modules?
I am processing quite large data quantities with L2PS (up to 1 terabyte per session) to create atmospherically corrected imagery of Germany. Unfortunately the fringes of Germany are often covered only by a Sentinel-2 tile of which upwards of 70 percent is outside of German borders (extreme example is Sylt of which a few hectares are only covered by a tile that further only covers Denmark and the North Sea). In L2PS I can only specify a tile allow-list for the GLANCE7 tiles, which I do use, but it doesn't solve the problem that I otherwise produce a lot of data "for the trash". Seeing that the L2PS parameter file also takes in an elevation model (I use SRTM for the lack of a better DEM available), is there a possible workaround? E.g. creating a DEM file that has elevation data for German territory but only NoData-values for anything outside the borders and would that result in less computational ressources / time squandered on processing?

It would be great if processing masks could be used in L2PS in the future. Regardless I love the awesome program you created!

[davidfrantz]

Hey @jo-spek,

there are a couple of strings in this question:

1. if you do not rely on your specific parameterization, we have a ready-to-go dataset for all of Germany here (provided you are an eligible CODE-DE/EOLab user): https://github.com/CODE-DE-EO-Lab/community_FORCE
2. there is a much better DEM available, which is the Copernicus DEM
3. you could use a custom tiling grid with smaller tiles, in which case you can get rid of more data with the tile allow list
4. the workaround with NA values in the DEM will technically work. However, there is one exception for ocean areas. If we have NA next to 0-values, FORCE will guess that the NA area is also the ocean, and will override the NA with 0. This is because DEMs are not available over the sea, and FORCE only produces data when a DEM is present (if you have specified a DEM that is).

Processing masks: this is a tricky request. I am asked this question quite frequently. From a technical standpoint, I am totally with you, and it makes a lot of sense. But nevertheless, I am still hesitant to fulfill that request because it will potentially have adverse effects on the resulting image quality. There are a couple of steps in the preprocessing that require spatial context and a larger area to effectively work, e.g. in the aerosol estimation... When we start to decrease the area, some things might deteriorate and will be hard for users to tell what happens... That said, it might be that this option will be implemented in the future (especially the cloud-community is asking for it to improve user-driven on-demand processing), but there will need to be a big at-your-own risk component involved. As this is not on top of my priority list, I do not have a timetable for a potential inclusion though.

I hope this answer still helps you a bit.
Cheers,
David