Sentinel-2 projection shift/error

@Jan

Hi Jan,

Thanks a lot for your response!

The L1C Tile number for the images:

Img. 1: S2A_OPER_MSI_L1C_TL_SGS__20151223T111941_A002621_T34SFH_N02.01
Img. 2: S2A_OPER_MSI_L1C_TL_SGS__20151206T113048_A002378_T34SFG_N02.00

I am sorry but i don’t know which one is incorrect. :slight_smile:

Hello @sclerc @Olivier @Jan and others ,

i noticed another error. Please see how the RGB image below is disorted

Looking at the individual bands 3 one can see that lines along the path of acquisition are shifted to either side of the image.

I indicated two straight roads where the shift (in direction of the arrow) is evident. If you download the images and flick back and forth you will notice cleary that the (scan) lines are disorted.
Band 04


Band 03

The example is from S2A_OPER_PRD_MSIL1C_PDMC_20160404T084411_R079_V20160403T095406_20160403T095406 Granule T33UXP but others are also affected

1 Like

Dear Unnic,

Yes, the anomaly impacts the products for the whole orbit 4080 and also the 2 next orbits, i.e. 4081 and 4082, respectively in terms of relative orbits 79, 80 and 81. In the first case, one observes a geolocation error + a multispectral misregistration. For the 2 others, only a multispectral misregistration was observed so far.

Investigation in progress.
I had in mind that the associated products should have been made unavailable in SciHub.

Thanks and regards
Olivier

2 Likes

Any estimates if or when corrected images will be available? Does one need to expect such errors in the coming acquisitions of this relative orbits as well?

@unnic

Hi

As highlighted by Olivier, this was a short term, transitory anomaly. We believe it has no link to the Relative Orbit(s). We do not know when these Orbits will be reprocessed.

Cheers

Jan Jackson

S2 MPC Operations Manager

I noticed a similar shift on S2A_OPER_MSI_L1C_TL_MTI__20160413T153307_A000720_T31TGL_B04 (and other bands int the same scene), about 970 m to the NNE.

Another image, like the more recent S2A_OPER_MSI_L1C_TL_SGS__20160205T174515_A003251_T31TGL_B04, is correctly georeferenced (sorry, being new, I cannot insert more than 1 image).

Can you check the acquisition time for the granule? The timestamp in S2A_OPER_MSI_L1C_TL_MTI__20160413T153307_A000720_T31TGL_B04 is production time, but there are no 31TGL granules acquired on 13 April (but on 5, 15, 25 and 8, 18 April).

Thanks for looking at that.
The full name is
S2A_OPER_PRD_MSIL1C_PDMC_20160414T041739_R008_V20150812T104021_20150812T104021.SAFE
so it sould be 2015-08-12 (sorry for omitting this information)

Strange. There are actually 2 versions of this granule. Easiest to check on AWS:

http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/31/T/GL/2015/8/12/

You will see there is a 0 and 1 directory. The 0 directory has a version that is offset more or less as in your picture. The 1 directory has a version that is correctly located.

Both are reprocessed versions of early phase imagery of August 2015. 0 was processed on S2A_OPER_MSI_L1C_TL_MTI__20160413T153307_A000720_T31TGL_N02.01 and 1 on S2A_OPER_MSI_L1C_TL_EPA__20160514T023519_A000720_T31TGL_N02.02, so at different ground stations and about 1 month apart (see respective metadata.xml). N02.02 suggest the second was processed with a newer processor.

1 Like

Thanks for this information (I didn’t know this AWS server). I downloaded the image on 2016-04-22, therefore before this new version appeared. I’ll get this reprocessed image.

Thanks again for this fast answer !

Olivier,

Was this problem ever resolved? I just checked the 33UXP tile and it seems still shifted, both between bands and in absolute position.

Guido

Dear Guido,

As previously written, the anomaly impacting R079_V20160403T095406_20160403T095406 (T33UXP) and more generally the whole orbit A4080, R079, is still under investigation. Note that another orbit is impacted by a similar behaviour that is A3218, R075.

The associated products should have been removed from SciHub.

Regards
Olivier

Dear bnnd,

Do you observe the same shift in both versions of the same product reprocessed with 2 versions of the instrument processing facility?

Thank you for having spotted that.
Regards
Olivier

Sorry, I did not pay attention to your comment:“Another image, like the more recent
S2A_OPER_MSI_L1C_TL_SGS__20160205T174515_A003251_T31TGL_B04, is
correctly georeferenced (sorry, being new, I cannot insert more than 1
image).”

It means that there is still an older version of the same product available somewhere, should be removed to my opinion… From where did you get them? SciHub? Another portal?

Please let me know.
Thanks and regards
Olivier

Hi

Acquisition 2015-08-12

Acquisition 2016-02-05
S2A_OPER_PRD_MSIL1C_PDMC_20160210T111540_R108_V20160205T103556_20160205T103556.SAFE downloaded from scihub (on 2016-05-11) was correctly georeferenced.

Cordially

Dear bnnd,
Thanks a lot for these elements.
Regards,
Olivier

Dear Rea,

Sorry to reply so late to your post.

I can see that the products you wanted to mosaic were not from the same relative orbit (50 and 93), which means that the geometric conditions are not similar.
Moreover, a slight yaw drift existed within the swath that as been corrected end of May.

You can find a list of known anomalies in the Data Quality Report with the following link:
https://sentinels.copernicus.eu/web/sentinel/missions/sentinel-2/data-quality-report

Regards,
Olivier

1 Like

Hi

If it helps to someone: tile 33SVC from 2016-04-03 affected by the shift. I guess included in orbit A4080, R079 as Olivier explains.
Single version, not fixed version:
http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/33/S/VC/2016/4/3/

The shift is light enough to align images and use the overlap between tiles to avoid the problem.

Thanks to provide this data and resources to use it.

Thanks and regards,
Tomàs A.

2 posts were split to a new topic: Polygons do not match Alos-2 image

A post was merged into an existing topic: Polygons do not match Alos-2 image