I am trying to merge features extracted from Sentinel 1 using the Create Stack, but it is not working. There is an error saying:
[NodeID: Create Stack] Cannot invoke “org.esa.snap.core.datamodel.Band.getUnit()” because “mstBand“ is null
The fix for this issue should be available in the Microwave 13.0.2 update. Kindly update SNAP by selecting Help → Check for Updates :
Thanks for answering. Actually, my snap is the latest version with microwave toolbox at 13.0.2. It is curious bcause the Snap toolbox at 12 version, this process works smoothly. My problem ocurrs just in the 13 version.
Jira ticket SNAP-4139 created.
1 Like
Here is a workaround. Before you run the CreateStack operator, you can manually change the unit of both the master and slave bands to “intensity”. For example, you have two products (master and slave). The first band in the master product is Sigma0_IW1_VH with a unit of intensity. The slave band is coherence with a unit of “coherence”. Now you can change the unit of coherence band to “intensity” by right-clicking on the band name and select “Properties” and change the unit in the pop-up window. Basically you should make your feature bands have the same unit as the master band. Then you should be able to run CreateStack.
1 Like
I have a similar problem. My workflow with SNAP 12 worked without any issues to process S-1 IW SLC data to coregistered terrain-corrected C2 data. With SNAP 13, the coregistered terrain-corrected C2 dataset only includes the components C12_real and C12_imag. Before coregistering, the terrain-corrected C2 data is composed of:
C11 (Unit: intensity)
C12_real (Unit: real)
C12_imag (Unit: imaginary)
C22 (Unit: intensity)
I’ve seen that a ticket was created, but is there a workaround to deal with this?
Thanks
You can change the units of C12_real and C12_imag bands to intensity before coregistration, and change them back to their original units after coregistration.
Thank you, it worked. Best wishes
Quick question: is there an automatic way of doing this? I have dozens of files and doing it one by one is just very inefficient. Thanks!
I am not sure if you can do it automatically in SNAP. But you can try to change the unit in the “.dim” file automatically.
Hello, I am facing a similar issue. I am working with a time-series of Sentinel-1 SLC data and I would like to generate a co-registered time-series of C2 matrices. My current workflow is:
S-1 TOPS Split - Apply Orbit File - Calibration (complex output) - S-1 TOPS Deburst - Co-registration - Polarimetric Matrix Generation.
The problem is that, although I obtain the different C2 elements, their values do not appear correct. For example, if I compute the VV intensity as i_VV^2 + q_VV^2 using the bands in the co-registered product (before computing C2), I expect it to match C11. However, starting from the second acquisition, this is not the case.
Could you please advise on how to solve this issue? Is the Create Stack operator the only way to generate the co-registered C2 products after modifying the band units of C12_real and C12_imag?
Thank you so much for your help!
I don’t think the Polarimetric Matrix Generation operator can now handle stack product properly. Also for Sentinel-1 TOPS SLC product, I think you should use BackGeocoding operator for coregistration. You may want to try the workflow like the one shown below.
Thank you for your reply. Regarding the BackGeocoding operator, my understanding is that it should be applied to pairs of SLC products. In my case, this would mean performing operations such as:
Master1 → BackGeocoding ← Slave1
Master1 → BackGeocoding ← Slave2
Master1 → BackGeocoding ← Slave3
and so on. Is this correct?
I also tested an alternative approach. Starting from a stack product (after applying the co-registration operator) containing the complex bands (i_VV, q_VV, i_VH, q_VH) of each SLC product, I iteratively isolate one acquisition at a time by manually removing all the other dates (for example, for date2 I delete date1 and all the others). I then apply the Polarimetric Matrix Generation (C2) operator to each isolated acquisition and repeat the process for all the dates. This procedure appears to work correctly. However, I am unsure whether this is an appropriate method to follow. Thank you again!
I think BackGeocoding can handle multiple (>2) SLC products. For your alternative approach, if C2 is generated using bands from the same acquisition, it should be safe.