Two SAFEs on the same day and wrong data

Hello everyone,

I just found a data issue for the L2A S2 on ESA (

There might be two different SAFEs for a single day for a UTM tile. However, these two SAFEs would have the same filenames for jp2 images.

For example, for the tile 13UDQ on 2019/10/12, two SAFEs could be searched.

  • S2A_MSIL2A_20191012T180301_N0213_R041_T13UDQ_20191012T203816.SAFE
  • S2A_MSIL2A_20191012T180301_N0213_R041_T13UDQ_20191012T222636.SAFE

However, they have the same filenames for jp2 bands with the prefix of “T13UDQ_20191012T180301_*”, which is really confusing.

According to the thumbnail, the first SAFE should be wrong data, but it still has been release on the ESA. Do you have any ideas about this data issue?


for such cases it is best to contact the copernicus service directly.
Please use the email given on the front page.

This is rare but normal.
The tile on that day was where the data-take was split in two.
You get two products that cover the two corners of the tile
with an overlap in the middle:


If I haven’t misunderstood your question.


Hello @smile4lee

As noted by @gbrelstaff, the presence of two Tiles indicates the transition from one Datastrip to another, within a single Tile footprint. In the example below (over Australia from S2A Orbit 34219) the upper component comes from the VGS1 acquisition S2A_OPER_MSI_L1C_DS_VGS1_20220110T022746_S20220110T011116_N03.01 whereas the lower Tile is from VGS2 (S2A_OPER_MSI_L1C_DS_VGS2_20220110T023016_S20220110T011323_N03.01)

With regard to the data loss in the Tile, this is a routine occurrence. It is explained in the L1C Data Quality Report available from the Document Library (Sentinel-2 MSI Document Library - User Guides - Sentinel Online - Sentinel Online)


Jan Jackson
OPT-MPC S2 Technical Manager

1 Like

Hi @marpet @gbrelstaff @Jan , thank you all for your response!

As @Jan mentioned, I found the detailed description about this lost packs issue in the L1C Data Quality Report.

And there is also description in the MTD_DS.xml metadata for the DATASTRIP in L2A SAFE.


Although this issue is not considered as an anomaly, it does impact some kink of applications. I might just remove SAFEs in such cases.

Thank you!

1 Like

Hello @smile4lee

Good to know that you’ve found the DQRs. They’re designed to inform the User Community on the status of the L1C and L2A production.

I note what you say about these products and your view that they should be removed from the Catalogue. However, if the problem does not impact the general level of quality (i.e. the product is complete, and geolocation and band to band registration is OK) we leave them in the Catalogue, because they may contain data that can be used (sometimes a failed product is registered that has a single line of lost packets in one detector of one Band, and thus is a very, very, small impact in the complete product). This approach has been agreed with ESA and other colleagues, and has been in place since the beginning of the S2 Mission back in June 2015.

One additional piece of information that might help you is the Anomaly Database ( This provides information on Anomalies identified over the Mission lifetime, and - where the anomaly still exists - can be cross-referenced with the DQR.



Hi @Jan

Thank you for providing additional reference!

I found that the band values of the lost packets could be greater than 0, such as 1 or 5 in the bands of L2A BOA jp2 images .

We are about to use per-pixel median temporal composite (monthly or weekly), based on each UTM tile. These non-zero values are likely to be selected as the composite values, because we could not differenciate these lost-packet pixels with other normal observations if they have the same values. In such cases, the composite (with lost packet pixels) might impact further analysis. That’s why we are considering removing SAFEs where lost packets occur.


Hello @smile4lee

Maybe you can pre-select by checking for the FAILED tag in the XML metadata. I know there’s only so much automation can do; here at ARGANS, we have several projects that are intensely coded, but post-process assessment and validation still relies on the Mk1 eyeball.