Questions about 2 weird observations on Copernicus and the Google Cloud

Dear STEP community,

I am regularly using the Copernicus Scihub and the Google Cloud repository (for the data I am interested in: https://console.cloud.google.com/storage/browser/gcp-public-data-sentinel-2/tiles/37/N/BA) to identify and download my Sentinel-2 data of interest (focusing on tile 37N BA). I however detected two things that I cannot explain and I am asking for your knowledge on it.

1- I am using cloud cover as a way to choose what data to download in the Copernicus Scihub. I however realized that the same product in L1C or in L2A don’t have the same cloud cover (sometimes one is 50% as L1C and 10% in L2A). Of course this leads to strange things as I first listed the data I needed using L2A and then I had to shift to L1C and I realized that some of the data I listed were missing. Which one should I trust? (Actually as there are no L2A data on the scihub before 2019, so I relied on the L1C cloud cover but now I am wondering if I should trust that and thinking about downloading everything and calculating cloud cover myself).

2- I learned mainly using this website (https://blogs.fu-berlin.de/reseda/sentinel-2/) stating that the frequency of Sentinel 2 data is 5 days (10 days for 2 satellites with a 5-days offset). This fits what I observe in Copernicus (e.g., for S2A, in the zone I am interested in Oct 2018 there is Oct 1st, Oct 11th, Oct 21st… However, on the google cloud there are some other dates included (for the same example: Oct 4th, Oct 14th, Oct 24th…). What are those?

Many thanks for your help. Please don’t hesitate to tell me if my questions are not clear enough.

Best regards,

Hi drozenrechels

Can you give an example where L1C and L2A have big estimated cloud cover differences? In any case to properly assess if cloud effects your selected zone look at high resolution using the EO Browser. https://apps.sentinel-hub.com/eo-browser
There you can flip through a range of dates and judge by eye.

The reason why some locations get visited more frequently than the nominal 5 day minimum is because the acquisition swaths overlap - places in the overlaps are visited every 2 or 3 days.

1 Like

Dear gbrelstaff,

Many thanks for your answer.

It is a bit hard for me to do it by eye, as I am working on a big range of time (2 years). This is why I aim at using an objective, automatic and repeatable method. (my other opportunity is to download all data and calculate it myself). One example I can give is April 28th, 2020 (37N BA). On the scihib.copernicus.eu, for L1C, I have a 31% cloud cover, for L2A it is 17%. As 20% was my limit this changes a lot for me. (I didn’t find my big 10% - 50% difference, the website is slow and I gave up).

I don’t understand the acquisition swaths thing. Does that mean the satellite visited a place nearby and also took a picture of the band again? Why then is it only on the Google Cloud and not on Copernicus? I had a look at the Google Earth animation that are given for the swaps and I don’t get the overlap. 37N BA only seems to be sampled once every 5 days looking at that and the swaps next to it barely overlap. Also, on the Google Cloud, the data that are in the middle of the 5 days are also 37N BA. Do you have any figure, reference or something in order that I can get it please (everything I find only states about the 5 days…)?

Many thanks for your precious help,
Best,

Interesting find… why don’t you get in touch with the GEE support (follow from here) and the official Sentinel support. and ask that same question?

This doesn’t exclude that some member from the community is able to give a reply to the question. This forum is for the SNAP and related Toolboxes not the Sentinel data generation and distribution for which the official channel above exists, nor the any cloud/data hosting service which usually have their own service support channels.

Hi @drozenrechels

I have retrieved the DS metadata for L1C and L2A for T37NBA from S2B on the 4th of March (orbit 20853):
For the L1C: <CLOUDY_PIXEL_PERCENTAGE>19.303</CLOUDY_PIXEL_PERCENTAGE>
For the L2A: <Cloud_Coverage_Assessment>23.978126</Cloud_Coverage_Assessment>

…whilst there is a variance between the two values, I would expect it: the L2A is a BOA product, and thus achieves a better level of discrimination of the source of an individual pixels reflectance when compared to the TOA L1C. https://sentinel.esa.int/web/sentinel/technical-guides/sentinel-2-msi/level-2a/algorithm .

I would always use the L2A over the L1C in instances like this.

Cheers

Jan

S2 MPC Operations Manager.

Hi @Jan and @cristianoLopes

Thank you for the information. Indeed I first wanted to use L2A, my problem was that these data were not available before 2019. I guess my aim now is to download all L1C to process to L2A and calculate cloud cover myself!

@cristianoLopes indeed I miht not have asked the question at the right place, thank you for replying though

Best,
David

1 Like

Hi @drozenrechels

No worries. My “analysis” of Scihub identifies that the earliest L2A for T37NBA is S2B_MSIL2A_20181215T074319_N0211_R092_T37NBA_20181215T101456.SAFE - so from December 2018. 1 of 81 L2A products in the Catalogue. Finding the optimal search parameters for SciHub is not easy, I find. I tend to go to my default; which is making an AOI wholly within the Tle footprint, and only ascribing the product level.

Cheers

Jan

The acqusition plan KML:s should tell you what the S-2 constellation is acquiring over your site of interest:

1 Like

You could try to use Idepix on your L1C data and after L2 calculation merge both products (Idepix + L2). Idepix provides very good masks for clouds of all types.

1 Like

Dear all,

Thanks you for your answers.

@Jan, I also agree that the search in SciHub is not easy. I made the decision to download everything and do the cloud cover myself. Indeed, as you said, I don’t have access to L2A data before mid-dec 2018.

@mengdahl, thank you for the link. I had a look yesterday already, but I realise today taking more time I could use the archive. I donwloaded some of the dates that I found weird. Indeed they are just a tiny bit of the tile taken another day. I understand better @gbrelstaff now and I know I cannot use them.

@abruescas thanks for the tip. I’ll have a look to Idepix. I usually use some code in R to remove cloud cover based on the band classification, it helps me easily automatize the process. My problem was much more to infer cloud cover before downloading. As I will download everything now, I think the problem is solved.

@drozenrechels Here is an illustration of the swath overlap that I prepared for a report about the island of Sardinia.

Consider the lower right parts of tile 32TML - it gets imaged by two swaths: relative orbits 065 and 022 (lucky) while the upper left part only gets seen by one swath: relative orbit 065 (unlucky).
And 065 32TNK is one of those tiny bits you commented on.

Hope that helps
Gavin