I’ve turned on per-pixel geo-coding as seen in the following figure:
And when I do so, and then reproject images with GPT, large portions are cut off. The following figure shows a small sliver between two scenes on the right, and the lower portion of the two scenes on the left.
If I uncheck all of the per-pixel geocoding checkboxes and run the same GPT code, everything stitches together just fine. In the following figure I only show the right two, but the left two scenes are non-cropped, and appear similar to those shown here: Snappy or GPT? advanced BandMaths
Are these slivers also visible in the lat/lon bands of the source product?
Can you tell me the name of the product where you have found this?
Yes all bands appear cropped.
I can recreate this in all OLCI EFR products. For example, using the following S3A EFR products:
And the following command (on each unzipped folder)
gpt S3_proc.xml -Ssource=/path/to/xfdumanifest.xml -PtargetFolder=./tmp/
S3_proc.xml is attached.
S3_proc.xml (8.6 KB)
Indeed this is a bug. It can happen that the boundary is not correctly computed when using the pixel-based geo-coding. This is now fixed for the upcoming SNAP release.
Great news! Thank you. I look forward to PREVIEW 6.
I just wanted to verify Snap version 6 available since 15 Jan resolves per pixel geolocation issues? I have a note from 7 Dec, 2017 “PREVIEW-7 solves border issue when using PP geolocation.”
Yes, this is fixed in the release.