I have run a number of tests with both ascending and descending S1 data. I am using slice assembly prior to terrain correction to avoid the gap between individual terrain corrected scenes from a single data take. The slice assembled terrain corrected products are shifted one pixel north from individual terrain corrected products. I am using a single SRTM 1 degree DEM.
SNAP/S1TBX 5.0.5
Both Windows and CentOS
Recent tests have been with cell: n10w073, and scenes:
S1B_IW_GRDH_1SSV_20170214T104025_20170214T104050_004295_007747_EB3C.zip
S1B_IW_GRDH_1SSV_20170214T104050_20170214T104115_004295_007747_5D03.zip
S1A_IW_GRDH_1SDV_20170203T225833_20170203T225902_015126_018BC0_F883.zip
S1A_IW_GRDH_1SDV_20170203T225902_20170203T225927_015126_018BC0_4131.zip
Related question: I have to do slice assembly over my area, since the scene split is now suddenly about halfway my area(S1A only relative orbit 37 over central Netherlands since May 19). If I save the assembly in BEAM-DIMAP format and then try to use it to generate coherence, SNAP complains with:
SEVERE: org.esa.s1tbx.io.SARReader: org.esa.s1tbx.io.sentinel1.Sentinel1ProductReader
[input=/home/username/S1A_IW_SLC__1SDV_20170525T054933_20170525T055025_016734_01BCB0_F803_Asm.dim]:
annotation folder is missing in product
What is the recommended format which maintains annotation?
@s0sh0rt
I have terrain corrected a number of products (individual and assembled) and I have not noticed the shift you refer to, although I could have easily overlooked it.
Now I have TCed product F883 in your list, individually and after assembling it with 4131. The TCed images are certainly not identical (due to, I assume, resampling effects), but I cannot identify a shift in any direction between the images. Can you provide screenshots or coordinates of points that appear shifted?
@glemoine
I also do coherence after slice assembly, using BEAM-DIMAP format throughout, and I don’t get that error.
Is this on gpt and/or GUI?
If I read the error correctly, it is being thrown by ‘Sentinel1ProductReader’, but that’s strange because the .dim product is not a Sentinel-1 product, and AFAIK it does not have an annotation folder, unlike the Sentinel-1 SAFE products. It’s as if the wrong reader is being called.
thanks for the reply. The error is thrown by gpt. I think the error is because I have
SENTINEL-1
in the graph, which I recycled from .zip only input. I threw away the assembled file (16 Gb), but will redo next week.
in the meantime, I replaced the read of a .zip to a subgraph that assembles from 2 .zip inputs in my single-slice only TOPSAR coherence script. This all runs fine, but only creates the coherence for one of the slice inputs, so not what I want.
Looks like my email reply did not post: Thank you for the testing and followup. The shift is uniform over the entire TC image. The only effective method to observe the shift is to toggle quickly between the two TC images at large zoom, because of the resampling differences. I don’t believe that screenshots or coordinates will help. One thought I had was that the individual images may be retrieving precise orbit data, and the assembled image may not. Thanks for looking at this issue. I will continue to look for a set of images and coordinate that clearly illustrates the shift. But I can only visualize by toggling the images.
I now believe that the shift is not observable in SNAP. I use PCI Geomatic’s Geomatica display software: Focus and their free viewer. Freeview: can be obtained here: http://dl.pcigeomatics.com/2014/freeview/GeomaticaFreeView2014Windows64SoftwareInstall.exe
I have run into this discrepancy several times and found that PCI was correct. Both ENVI and IMAGINE required corrections.
ARGH! The PCI viewer is not correctly displaying the two images. I have verified there is no shift in SNAP, ENVI, and other viewers. After GDAL conversion of the ENVI format TC files to TIFF, the PCI viewers also do not show a shift. This appears to be a problem with PCI’s interpretation of the geocoding in ENVI headers.
I had all kinds of problems until I eventually managed to get my system to reliably run coherence analysis to single-slice S1 products or to assembled slices on GPT. Most of the issues were memory-related (I have 24GB RAM) and were solved (touch wood) by checking the ‘Use FileCache in readers to conserve memory’ check box in ‘Options’ menu item ->‘S1TBX’ tab, in SNAP GUI.
The most common issue was that at least one of the three sub-swaths in the assembled products had information from one of the input .zip only.