Problem with geometric correction old S2A images

Dear all,

I’m processing two Sentinel-2A images (after sen2cor processing):

S2A_USER_MTD_SAFL2A_PDMC_20160303T104233_R060_V20160303T020744_20160303T020744

and

S2A_USER_MTD_SAFL2A_PDMC_20160810T132827_R060_V20160810T015702_20160810T020648

When I’m visualizing both RGB images, I see a difference of localisation over mainly elevated areas (not all). My questions are:

is it due to differences in geometric corrections?

is it possible to reprocess old data with the same processing baseline for example (between 02.01 and 02.04)? or something else?

thank in advance,

Johann

Hello

Do you have Absolute Orbit numbers for the products you are looking at?

Thanks in advance

Jan

Jackson

S2 MPC Operations Manager

Hello,

Here are all the informations about products I’m looking for:

20160810

Hello,

Here are all the informations about products I’m looking for:

20160810

Orbit number (start): 5920
Pass direction: DESCENDING
Processing baseline: 02.04
Processing level: Level-1C
Product type: S2MSI1C
Radiometric quality: PASSED
Relative orbit (start): 60

20160303

Orbit number (start): 3632
Pass direction: DESCENDING
Processing baseline: 02.01
Processing level: Level-1C
Product type: S2MSI1C
Radiometric quality: PASSED
Relative orbit (start): 60

Thanks in advance for your help,

Johann

@champenois-joh

Hi Johann,

Thanks for the details.

I would note that I have checked the L1C for geolocation (I used 50HLJ over Western Australia because it’s nice and flat), and I can confirm that there are no issues with geolocation in either L1C.

We shall investigate further and get back to you. In the meantime, if you have a particular AOI or Tile Number, that would help our investigation.

Cheers

Jan

S2 MPC Operations Manager

Thanks,

Here is the granule identifier for one of my images :

S2A_USER_MSI_L2A_TL_SGS__20160810T071128_A005920_T52SFB_N02.04

The area is the Kumamoto city in Japan.

Cheers,

Johann

1 Like

Hi,

Is it possible to have access to geocoded but whitout orthirectifiction?

Thanks

Johann

Level1B is geocoded in forms of tie-point grids but not orthorectified as L1C.
https://sentinel.esa.int/web/sentinel/user-guides/sentinel-2-msi/processing-levels/level-1

I don’t know if there is access to it.

Data on AmazonWebService is already orthorectified
http://www.mdpi.com/2072-4292/8/11/938/pdf

Hello

Level-1B data is not available to Users.

Cheers

Jan

S2 MPC Operations Manager

Hello,

I check the 2016/05/22 image for the same granule (T52SFB) and there is no difference with the 2016/03/03 image.

Is there any significant change in processing between 2016/05/22 and 2016/08/10 ?

What about the processing baseline ?

It exists a clear offset (North-South mainly) visible, for example, at LAT 32°41’56"N and LON 130°36’35"E.

Cheers

Johann

Hello Johann,

Have you also raised this issue via the Copernicus Helpdesk? If you have - we’re dealing with it via that route as well…

Cheers

Jan

Thanks Jan,

Before create a topic here, I send an email to EOSupport@copernicus.esa.int which transferred me to the STEP Forum

How I can raise this issue to the Copernicus Helpdesk?

Cheers,

Johann

Hi Johann,

In sending the email to the EOSupport@copernicus.esa.int, you triggered an investigation on our side. I shall post this here, and also to the Helpdesk, so you’ll get the answer twice!

Expert assessment of the L1C products showed some differences in geolocation between the 03/03/2016 (N02.01) and 10/08/2016 (N02.04) products, with discrepancy on some parts of the image being around 15 metres in the North-South direction for the 10m RGB Bands (B04, B03, B02), while in other areas of the image the difference is not visible. These geolocation differences are not only visible on mountainous areas but also on flat areas.

The geolocation differences between the 02.01 and 02.04 processing baselines may be due to an issue in the yaw steering compensation, as the errors seems to be dependent on the pixel position across the swath.

It is therefore recommended that a common processing baseline (such as the current 02.04) be used for multitemporal studies.

Cheers

Jan

Hi Jan,

If I understand your previous post, I just have to wait answer ? Or I have to contact the Helpdesk by myself?

Cheers,

Johann

Hi Johann,

No. The answer I gave in my previous post is the answer you will recieve through official channels - i.e. via the Helpdesk.

Cheers

Jan

Hi Jan,

How I can ask to reprocess only one granule (03/03/2016) with the 2.04 processing baseline?

If I resume, there is no issue to it problem, just waiting for some news.

Cheers,

Johann

Hi everyone,

Is that possible to reprocess only one granule (03/03/2016) with the 2.04 processing baseline?

Cheers,

Johann

Hello Johann,

I’m afraid that bespoke reprocessing of single Granules is not possible.
The Datatake of the product you have issues with will be included in the Reprocessing currently being undertaken, but I cannot confirm exactly when the March 2016 products will be done. I believe I can say with some certainty that it won’t be this year.

Sorry.

Cheers

Jan