Since new SNAP update reprojection of large S3 files failes!

Dear Community,

Since the SNAP update from version 8.0.3 to version 8.0.4, the reprojection of certain S3 data no longer works!
This concerns the large archived files around 1.8 GByte, which extend as long strips once around the globe.

Here are two files, which cannot be reprojected with SNAP 8.0.4 but which could be reprojected with SNAP 8.0.3:

  • S3A_SL_2_LST____20190630T200047_20190630T214147_20190702T023435_6059_046_242______LN2_O_NT_003
  • S3B_SL_2_LST____20190630T192111_20190630T210210_20190702T014223_6059_027_099______LN2_O_NT_003

And this is the error message:
“Error: [NodeId: Reproject] The source product does not provide geo-information and cannot be reprojected”

Who else has observed this error?

@ the Developers of SNAP and the Community: What can we do other than waiting for an update that will bring back once working functionality?

Thank you for your help. Snap always has some (sometimes nasty) surprises in store.


Hi Carsten,

It is intended that those are rejected, because they do not provide correct data.
At least for the first one, the S3A, I checked the quicklook. The data is offline.
You can see this line in the data:
There geo information ad data does not correspond anymore.
This is the related issue:
[SIIITBX-364] S3 data containing gaps not correctly handled - JIRA (
Beside the discussion below the ticket, there was also a discussion with the S3MPC, (mentioned in the comments). It was decided to not support those product because they can be seen as corrupted. ESA will try to tackle this in the future.
In version 9 this will be fully rejected.

The second product is not available anymore at the Copernicus SciHub.

The data you got in previous versions was not correct.

Dear Marco,

thank you very much for this explanation. Please allow some further questions.

If I understand your post correctly, these archived data contain errors (data gaps and not corresponding geo-information) and are from now on regarded as “corrupt”?

Do you have any information on whether this data will be corrected by ESA (if possible) so that it can be read correctly by SNAP again?

Is there an official document or a working note or any kind of quotable information describing this problem and the decision to adapt SNAP 8.0.4 in such a way that the data are rejected by the software?

BTW: The data I used as an example were downloaded from the CREODIAS platform as the retrieval of archived S3 data from the Copernicus Open Access Hub is quite inconvenient especially when trying to set-up automatic processing chains (application for restoring them in the rolling archive and availability there for only a short and limited amount of time).

Thank you very much for your kind support and best regards,

Sorry, I have no information when it might be solved by ESA. And there is no official documentation on this. What I have written in the comments is the most “official”, I think.
But the processing of fixing this issue is at the very beginning at ESA. So, it might take some time.
Maybe @jbruniquel has some knowledge how ESA proceeds with this issue. Jerome, do you know something? This is about the issue SIIIMPC-4852.

Yes, Copernicus Hub can be sometimes inconvenient.

Dear Marco,

thanks a lot for this insight.

One last question - I promise :wink:

In your first reply, you were writing “The data you got in previous versions was not correct.”

What does this exactly mean - it was geometrically not correct, radiometrically not correct of both?

Thanks a lot and best regards,

The data was geometrically not correct. Radiometrically they are probably okay. At least if you only look at the radiances. The geometrical error got corrected when reprojecting the data, the geo-location of each pixel is considered and put at the right place. In the reprojected result the gap became visible.
But data processing starts before reprojecting. As long as you consider pixels separately the radiometric processing results are still okay. But if you have a window process this would give wrong results at the artefact line, because the pixels are considered as close by which are actually far away.
In addition not only the geolocation was wrong but als the time information was not correct. See
If this was used in calculations it gave also wrong results.
And maybe there are more issues with this data we haven’t noticed yet. Maybe the provided view and sun angles are not correct. We haven’t checked this. Maybe other things went wrong in the ground segment due to the data gap.

Thanks again for these interesting information!

Have a nice day and all the best from Jena,

Hi all.

Yes, Marco, this is related to the MPC ticket you have spotted. At this stage I have no indication when the correction will be made. I will let you know when there is a plan for this.

Kind regards, Jerome

1 Like