Dear Snap team,
I am batch processing a considerable amount of scenes for entire Ethiopia using gpt of SNAP 5.0 on Ubuntu 16.04 (40 CPUs 160GB of RAM). Single swaths can make up to 7 frames. In my routine, I am importing the single frames, apply the precise orbit file and remove thermal noise to them in the first place. Subsequently, I am using the swath assembly to get a single image per swath and acquisition date. This runs fine for most o the swaths, with some exceptions.
What happens is that the swath assembly creates the Latitude and Longitude grids incorrectly. Values decrease from up to down (i.e. descending orbit), but over the center of the last scene increase again (See image 1 & 2 at the bottom).
Latitude of tie point grid as shown in SNAP
Longitude grid as shown in SNAP
The scene data itself is actually fine, and subsequent steps such as calibration and terrain flattening just work as they should. However, it affects the Terrain Correction, applied at the end of the processing chain, and outputs only a small fraction of the actual swath (see Image 3). My guess is that TC uses the corner coordinates of the image. Since the values re-increase, the image is cropped, corresponding to the increased lat/long values at the lower end of the tie-point grids.
Output of a 7 frame swath after TC.
The nasty thing is that this issue does not even throw out an error message, neither during the swath assembly, nor in the following processing steps. So I give you the list of scenes in order to be able to reproduce the issue. If you are keen, I can also give you a list of files from other swaths where this issue happened.
Some things I already tried:
The problem of the Lat/Long grid appears over the last scene (S1A_IW_GRDH_1SDV_20170604T030213_20170604T030240_016878_01C12B_4107), so I processed the scene itself with success including a proper Lat/Long grid without this issue. So the issue is not in the scene metadata itself.
If I take the other 6 scenes and follow my routine it also works fine, and a proper Lat/Lon grid is present in the tie-grid points folder. However, I do not think that it is connected to the magical number of 7. I processed the same swath from another acquisition dates with success.
I hope this issue can get solved soon, since I am relying on this in a operational environment.
Thanks in advance