Dear all,
M. Foumelis and me had presented our work at IGARSS2018 to get automatic Single master Sentinel-1 DInSAR interferogram stacks with SNAP compatible with StaMPS PSI.
We have created a package with python scripts and xml graphs to do the job. This free package is available at : https://zenodo.org/record/1308687
Enjoy!
Fantastic news - kudos to you and Michael for sharing this with the community!
edit: I pinned the topic for the next two weeks for better visibility
Thanks a lot! Excellent work!
I have a few questions - how can I use an external DEM? ASTER for example. What format and size is needed in this case?
Hi Stoorm!
You can use external DEM by using the tag in the coreg_ifg_computation.xml (or coreg_ifg_computation_subset.xml) named <externalDEMFile/> in the TopoPhaseRemoval and Back-Geocoding operators.
for using it you need to change :
<externalDEMFile/> by
<externalDEMFile>EXTERNALDEM_with_FULLPATH</externalDEMFile>
SNAP needs the external DEM to be a single GeoTIFF file.
In future releases of the snap2stamps it will be just as easy as introducing this in the configuration file project.conf, but for the moment you should do it manually as mentioned before.
I hope this helps!
Thank you! I was able to use your tool. It is really faster and more convenient than SNAP! Please tell me what files (version?) you are recommend to use for the data preparation in StaMPS used? I mean - mt_prep_gamma and ps_load_initial_gamma.m.
My advice is to use external DEM. Don’t forget to replace the name of the SRTM on something else like GTOPO or ASTER.
Vitaliy
best regards
Hi Stoorm,
I am glad that you can use the snap2stamps package and you find it useful! Please do not forget that it uses SNAP for doing the job, that package is only a wrapper to automate the processing.
For the mt_prep_gamma, you need to modify the existing script, maybe make a backup and modify the lines:
calamp calamp.in $width $WORKDIR/calamp.out s 1 $maskfile
mt_extract_cands 1 1 1 1 s 1 $maskfile
by
calamp calamp.in $width $WORKDIR/calamp.out f 1 $maskfile
mt_extract_cands 1 1 1 1 f 1 $maskfile
s changes into f , because the SNAP gamma format is float complex and not single complex.
Regarding the ps_load_initial_gamma I do not remember to had modified it. So it should work as it is. Let me know if this is not the case and I will share my mt_prep_gamma and ps_load scripts.
Regarding DEMs, indeed the use of a more accurate and updated DEM is better, but it becomes more important when working with higher resolution SAR (X-band stripmap for example). Indeed there are many DEMs that could be used, ie: SRTM DEM (3 or 1 arc second), ALOS DEM, TanDEM-X, etc , but always in GeoTIFF for being used using SNAP.
Enjoy the snap2stamps scripts!!
Thank you for providing these wrappers! Should make the preparation a lot easier.
I currently receive an error message at the spliting_slaves.py
Error: [NodeId: TOPSAR-Split] [latGrid] is null
I double-checked the AOI BBOX DEFINITION parameters, they seem alright and match the given IW.
LONMIN=91.34
LATMIN=22.32
LONMAX=91.46
LATMAX=22.43
Any idea what could go wrong here?
Hi ABraun,
Please note that the AOI BBOX definition it only used during the coregistration-interferogram computation on those scripts.
For the splitting, the IW is the parameter to consider during the splitting step. Was it defined in the project.conf file?
In addition,could you post the final xml which the scripts run? It might be called something like splitgraph2run.xml that should be found in the PROJECT/graphs/ folder.
With that info it should be easier to identify the issue.
Please let me know it this helped.
Thank you very much. You were right. Instead of
IW1=IW3
I had
IW1=3
Now it proceeds as expected.
Thanks @ABraun!
I am glad it works now.
Let me know if you find something that should be fixed!
Any feedback is welcome so we can include more functionality in the near future.
Cheers
Thank you!
How exactly do I enter the MASTER= information and does it have to be included in the slaves folder?
Hi @ABraun,
in the project.conf, the paramter MASTER must contain full path to the splitted and orbit corrected (preferibly with precise orbit information) master image in dim format, and it is suggested to put it in a separate folder (otherwise in the coreg-ifg step it will try to process it),
It could be for example:
MASTER=/home/pi/Desktop/PROJECT/master/S1A_IW_SLC__1SDV_20150405T175350_20150405T175417_005352_006C9E_0FE9_Orb.dim
The processing of TOPSAR-Split (with the minimum bursts of a single subwath covering your AOI) and ApplyOrbit should be done by now using SNAP GUI (so you can identify your AOI visually)
Indeed a sample of a full test could be included in the SNAP2StaMPS_User_Manual to put everything clearer.
I hope this helps.
thank you very much.
Two more suggestions:
To make it clearer it would be nice to number the scripts, e.g. like this
Another handy thing would be an overwrite-flag in the project.conf.
I just added one more scene to the original data and the scripts keep going through all of the data again.
Thanks @ABraun,
I have taken note of the suggestions.
For the moment you can just move the slaves which were processed already in the past, but for sure I will include a check for future release.
I hope that the scripts are handy and it helps doing the processing of inteferogram stacks easier!
Cheers
that is fine.
One very minor thing: I found that the print command in the coregistration script says “prep baseline” instead of (?) “perp baseline”.
Hi @ABraun,
Where is that? Do you think it could be the SNAP logging?
I have not found any line on my python script with the printing of the perpendicular baseline information as it is calculated within SNAP directly. If you have found it, could you please refer to which line?
Can you confirm that? Thanks!
Thanks again for checking the scripts and reporting about their functionalities!!
All comments to improve the scripts are welcome!
The most important is that the snap2stamps package is useful for the community as it is its only reason of existence.
Please let me know when you will manage to run them all (and if they work or not properly on your system) and which is your impression about them, so we keep improving them.
Cheers,
I’ve fixed this typo. Found it two times in the CreateStack operator
