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:
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 (atlassian.net)
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.
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,
Carsten
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.
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 https://senbox.atlassian.net/browse/SIIITBX-363.
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.
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.
