When reprojecting S3 data which contains gaps in the data due to instrument calibration the result can be wrong. If the tie-point geo-coding are used with then the gaps are filled with values of the nearest pixels. When using the pixel-based GeoCoding then the gaps are visible, but still a small border of a few pixels has duplicated pixels. The attached image shows the issues.
In the implementation of the pixel-based GeoCoding is already an EPS considered and if the distance of the found pixel is more than the EPS value the pixel is not considered. That's why the gap can be seen. Maybe the EPS value is too big. This could be the reason there are still duplicated values.
Also, the whole scene (in both cases), does not provide geo-location information.
Example product is: S3B_OL_1_ERR____20201222T085839_20201222T094243_20201223T120700_2644_047_107______LN1_O_NT_002.zip
It is on the BC data server at: related\snap\s3-gap-issues
We have implemented the recommeded solution - (S3MPC and Steffen Dransfeld) - to detect the gaps in the data and - if present - reject opening such a product.
All data containing a scan-line time difference that is 50 % higher than the nominal will be rejected.
stephen.plummer 30 June 2021 at 12:54
What was the solution found and implemented to declare resolved?
stephen.plummer 3 March 2021 at 10:38
OK
Marco Peters 3 March 2021 at 10:28
Only what I have already said, that it is okay to skip those products, because those gaps will not occur offen. For the time inconsistency issue we have opened a new ticket.
stephen.plummer 3 March 2021 at 10:20
Ok have you received any feedback yet (I can follow up with Steffen if necessary)
When reprojecting S3 data which contains gaps in the data due to instrument calibration the result can be wrong.
If the tie-point geo-coding are used with then the gaps are filled with values of the nearest pixels.
When using the pixel-based GeoCoding then the gaps are visible, but still a small border of a few pixels has duplicated pixels.
The attached image shows the issues.
In the implementation of the pixel-based GeoCoding is already an EPS considered and if the distance of the found pixel is more than the EPS value the pixel is not considered. That's why the gap can be seen. Maybe the EPS value is too big. This could be the reason there are still duplicated values.
Also, the whole scene (in both cases), does not provide geo-location information.
Example product is: S3B_OL_1_ERR____20201222T085839_20201222T094243_20201223T120700_2644_047_107______LN1_O_NT_002.zip
It is on the BC data server at: related\snap\s3-gap-issues