I am having trouble with a specific graph integrating a slice assembly of 2 sentinel-1 along track SLC products (I checked and they are indeed adjacent slices), followed by splitting, debursting, merging, polarimetric matrix (C2) generation and finally a multi-looking, terrain correction, subsetting and a writing.
I am facing two problems, starting with the main one.
I am running the graph from command lines using the gpt utility, and no particular errors are displayed, at least no different than when I run the same graph with a single SLC product (without slice assembly).
However, the output is a polarimetric matrix of the first image that was fed into the productSet-Reader, and not the total assembled results of the two input products.
This basically seems like the slice assembly operation is short-circuited and obsolete. However the processing time does seem to be longer, which should be a good sign, but the output is no different.
I tried to put the the slice assembly operator at different stages in the graph (after apply-orbit and after topsar-merge). Putting it after TOPSAR-merge complexifies the graph significantly by having to create 2 separate reader branches each performing 2 split/deburst/merge branches, bringing it up to 4, or even 6 as I also perform the debursting on all three sub-swaths in certain cases. Besides the complexity issue, it did not work and a javaNullPointerException occurred.
This was the reply from @lveci in another thread, but the slice assembly did not seem to be to tolerated after the TOPSAR-merge (which was still before terrain correction and multilooking as suggested).
The second issue, which is non-major because I can get around it quite easily, is the fact that the wktAOI argument to the TOPSAR-split operator does not seem to work when i provide the wkt. And even if it did, how would the operator know which IW sub-swath to select if the AOI is overlapping between two sub-swaths? or does it automatically split and process both sub-swaths in such case? This issue is minor as as I pre-emptively process all sub-swaths without trying to figure out which ones I am interested in, and perform a subset using that same AOI before writing the output. A slight bit inefficient but still processes fast enough for my needs.
Thank you in advance for your help and keep up the good work!
Assembling the slices first like this could give you poor performance.
Try doing this in two graphs instead of one. Also, I don’t think you need the split, deburst, merge.
Try apply-orbit, deburst, slice-assembly
or if it’s more convenient to use the product-set-reader
Try slice-assembly, apply-orbit, deburst
and then in a separate graph do the matrix to terrain correction part.
Splitting the graph does not seem to solve the issue.
I think it is related to this problem, because I cannot perform slice assembly before performing the deburst operation on one hand.
On the other hand, the final output displayed does not show the slice-assembled result, but only one of the two slices, which is akin to the following issue:
Therefore, is there a fix to the problem?
This is the result I get by performing a gdal_merge or a SAR-Mosaic operation after applying the graph from my previous post to the separate slices (without assembling them).
If I include Slice Assembly and split the process into two graphs like @lveci suggested, the output only gives the bottom(or top depending on order of files provided to the ProductSet-Reader) half of the figure shown.
