I think S1Tooblox is a nice tool for processing S1A radar data. Thanks the developers!
I found there are big data gaps between sub-swathes after using S1-TOPS-merge operation sometime. The recent Chili-quake case is absolutely suffered from this issue. Please see the intensity image in db mode. This is not the only case I have, but not every InSAR processing has this problem. I didn’t found any options to overcome this problem in the processing chain. Does anyone know how to correct it? Of course, we can do the processing sub-swath by sub-swath and mosaic them after then, but it is inaccurate for keeping consistency phase across them.
Thanks!
Hi, lveci,
The products are just those from the Chili earthquake few days ago, someone else published their results on InSARAP.org.
Descending pass data on track 156:
S1A_IW_SLC__1SSV_20150824T100312_20150824T100339_007403_00A2FE_A7E8.zip
S1A_IW_SLC__1SSV_20150824T100337_20150824T100404_007403_00A2FE_C3A8.zip
S1A_IW_SLC__1SSV_20150917T100312_20150917T100339_007753_00AC77_F0AA,zip
S1A_IW_SLC__1SSV_20150917T100337_20150917T100405_007753_00AC77_9048,zip
Also another question:
The i and q data are used in SNAP as complex, which are float 64 data, rather than float 32 data as other products. The data size would be huge when several slices are processed together (as this is very normal in case of large earthquakes). In order to save space and time, we prefer single/float complex data in the processing, which is far less than the float 64 data. So what’s the point for using this very high precision data type?
When I convert i+q data into complex (also the same when using phase+intensity data), it seems that the phase are not wrapped anymore (though SNAP GUI shows -pi ~pi phase values). I don’t know what is the problem in the conversion. Is there something special in the definition of i and q?
Recently, I also notice the black margin or border noise of the Sentinel-1A GRD data. Do you know what is the cause for these invalid data? It seems these values are not only zero but can reach 100 (magnitude) or more.
I’d also like to know more about the black borders and how to mask them out.
According to the SNAP 2.0 help on the ‘S-1 GRD Border Noise Removal’, this operator is based on the algorithm described in the following document:
Masking "No-value" Pixels on GRD Products generated by the Sentinel-1 ESA IPF, Reference MPC-0243, Issue 1.0, Date 2015, June 25.
But I have not been able to find this document, either in the ESA’s Sentinel-1 Document Library or googling for it.
Someone in this forum wrote some time ago that the operator was based on one of nuno’s notes. Now that @nuno.miranda follows the forum, maybe he can point out to it?
Incidentally, does the name of the operator describe accurately what it does? How is noise related to the black borders? According to SNAP help, the borders are the result of azimuth and range compression and time changes in the sampling window start time.
multilooking? after the merge.
There’s a lot of book keeping going on when handling bursts so you don’t
want processing that could affect times, dimensions or resolution that
could introduce errors. After the bursts have been dealt with then it
should be like any other product.
Ok I got your point. The idea is to split and merge are operations meant only to manage the bursts. Fine. As matter of fact I was using them also in order to save some memory up the the amplitude geocoding. Then in better to marge at the geocoding level (maybe using the mosaiking tool?)
Thanks
Btw i did a quick try and if I merge just after the the split I get the following errors now:
️:muscle:
