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.
Hello Jianbao, what is the toolbox-version you are using?
I use both old STX1.1.1 and the beta 7 version of SNAP.
Both versions have same problems.
Could you provide the full name of the products
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:
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?
This should be fixed now available in the next release. Thanks
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.
Looking forward to your reply.
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.
I obtain the same problem when processing SLC data until multilooking and then try merging them. Is it a proper way to use the merge operator?
I am using SNAP 2.0.
I don’t think you should multilook before merging. The result may be inaccurate.
So when is it advisable to do it? Before the debursting?
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?)
Btw i did a quick try and if I merge just after the the split I get the following errors now:
metadata attribute ‘firstvalidpixel’ not found.
Any idea of the error?
Have you got the correct step order about merging all the subswaths at once? Thanks