Sentinel-2 projection shift/error

Hello everyone,

this is most likely off-topic because it doesn’t concern the toolbox but I just want to raise awareness that some S2 data has a shift in the geographic projection. See the images below for clarification, the first one with correct projection and a recent one (20160403) with the projection error, polygon for reference.



it is also discussed here:


Dear @unnic,

Thanks for informing us.
These kind of information should be reported to the Copernicus Help desk (see

Your right Julien, this needs to be reported to the Copernicus Help Desk. But it is good that @unnic reported it here too.
Otherwise we wouldn’t know about it.

I’ve sent it to the help desk this morning.

Yes, the problem is that the help-desk sometimes takes several days to answer relatively simple questions and sometimes refers back to the STEP forum! So, stuff can become circular.

I just noticed that the GIS forum on which the original post was put does some kind of moderation, changing your comments. I don’t like that. So, better to use this forum.

Apparently, all granules in the scene from which the 33UXP granule is coming are shifted (at least the one in UTM zone 33).

Hello to all,

The anomaly has been identified and is currently under investigation.

Sébastien CLERC
S2MPC Technical Manager


Dear all,

First of all, thanks a lot for having reported the issue.
Note that the anomaly seems only impacting absolute orbit 4080 (i.e. products generated from data acquired on 3 April between 9 and 11 am).
Investigation in progress.

Best regards,
S2MPC ESL Coordinator

Hello everyone,
i have got two images that i would like to mosaic but the shift is really obvious. The products are the following ones:

The spatial reference is the same (WGS 84 UTM ZONE 34).

Any idea?


Hi Rea

Do you have the L1C Tile number (found in the GRANULE filename) for this image?

Thanks in advance


S2 MPC Operations Manager


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


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?



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.


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
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:

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 !


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