Snap2stamps package: a free tool to automate the SNAP-StaMPS Workflow

Abdel · January 21, 2020, 3:36pm

This problem happens when your splitted master image name contains “IW1”. I think it was the case for you ?

===========For less details, users can skip this part=========
For me, whene i splitted the master i named it : /home/abdel/INSAR/XXX/S1/master/S1A_IW_SLC__1SDV_20180416T145733_20180416T145800_021494_025070_1812_IW1.dim

This what will happen, i just figure the cause now :

On the project.conf file you will have something like this :

##################################
PROCESSING PARAMETERS
IW1=IW1
MASTER=/home/abdel/INSAR/XXX/S1/master/S1A_IW_SLC__1SDV_20180416T145733_20180416T145800_021494_025070_1812_IW1.dim
##################################

When you run splitting_slaves.py project.conf, this part of code :

Getting configuration variables from inputfile
try:
in_file = open(inputfile, ‘r’)
for line in in_file.readlines():
if “PROJECTFOLDER” in line:
PROJECT = line.split(’=’)[1].strip()
print PROJECT
if “IW1” in line:
IW = line.split(’=’)[1].strip()
print IW

Will read project.conf line by line and check if this line contain IW1 !!
But we have two lines that contain “IW1”

In the end the variable IW value will contain : “/home/abdel/INSAR/XXX/S1/master/S1A_IW_SLC__1SDV_20180416T145733_20180416T145800_021494_025070_1812_IW1.dim”
instead of “IW1”

This value will be passed to the graph slave_split_applyorbit.xml here :

<subswath>IWs</subswath>

By this line in splitting_slaves.py

filedata = filedata.replace(‘IWs’,IW)

And the graph that will be run for spliting the slaves splitgraph2run.xml will contain this line :

<subswath>/home/abdel/INSAR/XXX/S1/master/S1A_IW_SLC__1SDV_20180416T145733_20180416T145800_021494_025070_1812_IW1.dim</subswath>

instead of

<subswath>IW1</subswath>

Which is not accepted by the GPT and give you Error: [NodeId: TOPSAR-Split] -1

===========Solution==================
To to sum up :
Try to not use IW1 in the name of your splitted master (for the image file and project.conf)
Or change the parameter IW1’s name in project.conf to smothing like IWs and specially not IW because all sentinel-1 images contain this. And then change this also in splitting_slaves.py :

if “IWs” in line:
IW = line.split(’=’)[1].strip()
print IW

ABraun · January 21, 2020, 4:31pm

yes, exactly. Only the line IW1=IW2 (determining the sub-swath) can contain “IW1”, otherwise the script gets confused.

Abdel · January 21, 2020, 4:49pm

I think in the project.conf, “IW1=…” was used instead of “IW=…” just to avoid this confusing situation with any Sentinel-1 image that contains “IW” in the beginning : S1A_IW_SLC_1SDV_....

So we should notice this.

mdelgado · January 21, 2020, 11:25pm

Indeed it should be enough if in the next release I will change it in small letters iw1 instead of IW1.

Then the parser will not get confused anymore.

Abdel · January 22, 2020, 9:43am

@mdelgado

Does the next release include this point as mentioned in the package future works :

Add more sensor support. Specifically on STRIPMAP SAR datasets

Because in the context of a study, i had to adapte your scripts to include STRIPMAP mode and i am working also on other improvements : files managements, logfiles…

I can give a hand on this point if is not done yet !

ABraun · January 22, 2020, 9:47am

@Abdel Stripmap data is quite easy, because it doesn’t require Split, Deburst, ect…

You can prepare them with three steps:

Apply coregistration to all your products (1 master, multiple slaves)
Interferogram generation to calculate the interferograms of this stack
These two stacks can be used as input for the StaMPS export in SNAP

Abdel · January 22, 2020, 10:11am

You are right we can do that without scripting it is quite simple.
But for me, i avoid using a single Stack for all image because it’s very slow compared to multiple Stacks of images paires. This loads the RAM maybe ?

Anyway this still easy with or without scripting compared to TOPS mode.

mdelgado · January 22, 2020, 10:11am

Indeed it is foreseen.

All feedback is welcome. The workflow is clear, but any comments and suggestions for logging or other is more than welcome

falahfakhri · January 22, 2020, 11:57am

Hi Jose,
The snap2snap has been downloaded and unzip in linux, the python 27 is existed, first thing I have confused, how to run it from everywhere without to navigating to the folder of the py.scripts, and secondly I got the following error.

mdelgado · January 22, 2020, 12:28pm

can you share the content of the project.conf file?

falahfakhri · January 23, 2020, 7:02am

this is the content of the project.conf

mdelgado · January 23, 2020, 9:33am

Had you installed the pathlib python package as in the manual?

falahfakhri · January 23, 2020, 9:34am

Thanks for your response, Yes I did, and has been installed successfully.

mdelgado · January 23, 2020, 9:35am

Then it sounds like a permission issue. Please ensure the scripts can read and write in the destination folder

For successive steps you should also define the gpt path and the master image (splitted and applied orbit)

wharfbanger · February 1, 2020, 9:19pm

Hello snap2stamps community,

I have been using this snap2stamps with success to map volcanic areas and need some advice on data quality. I have noticed that smaller stacks have less temporal decorrelation (higher PS density), and this makes sense. I am wondering if there is a general rule for minimum stack size (e.g. 8 images)? Also, I have been kriging the exported PS maps, and am wondering if anyone has experience doing this? Is it wise to filter the PS results (e.g. remove PS below a certain r2 value), or perhaps the kriging process smooths the data and this is unnecessary? Any thoughts are appreciated

mdelgado · February 1, 2020, 10:19pm

Hi @wharfbanger,

I am glad the snap2stamps package makes life easier! It was developed for that purpose

1)Regarding the stack, I agree that smaller stacks provide higher PS density, but remember than minimum PS analysis with minimum quality requires at least 20 interferograms (I personally suggest >25)
2) Kriging is an interpolation method, so clean and quality points will provide better interpolated maps. noisy points will provide worse. This is my personal opinion, please correct me if I am wrong.

I hope this helps.
Best

wharfbanger · February 2, 2020, 1:27am

Thank you for the fast reply. I have been experimenting with different stack sizes (44, 21, 11 and 7 interferograms), for the same area. The time period is after 2017, so the stacks have 12-day repeats, with very few gaps.

The study area contains a powerful groundwater well (geothermal well) that has caused subsidence, and this is clearly visible in all results - even the 7 stack! Another factor for me is the short but intense dry season in my study area, which eliminates vegetation foliage for a period of about 4 months every year. By selecting shorter stacks that cover only the dry season I think I am avoiding de-correlation from vegetation growth in the wet season. So, it seems that PSInSAR works very well, even for the smaller stacks. Can I ask where your minimum of 20 comes from?

I have been encouraged to use the smaller stacks because the PS density is so much greater.
My logic is this: for the small stacks I have very high PS density (I understand individual PS accuracy is very low). Kriging smooths the inaccuracy by averaging 16 – 20 PS in the search radius. Perhaps this is better than having a larger stack with very low PS density? I have been checking data quality by calculating r2 and p-values for each PS time series, and these provide “quality checking” layers. I don’t know how familiar you are with kriging, but it may be worth mentioning that the variograms for all datasets are beautiful (even the 7 stack), which suggest to me the spatial trends in PS are real.

Snap2Stamps has allowed me to experiment with many different stack sizes and time periods. I think it is a fantastic tool.

mdelgado · February 2, 2020, 4:30pm

I am afraid you will be measuring seasonal effects and not long term displacements using only 7 x12 (84 days < 3months).
the minimum of 20 images come from many studies, when you check literature on PS analysis, as some of the phase noise is estimated, the mathematic approach provides good accuracy once reaching a relevant number which allows to estimates.

I am just wondering if you could use those 7 images per year and put them together, then you may have over 28 images (only covering the dry season). What about this?

I hope this helps
Best

wharfbanger · February 2, 2020, 8:11pm

Thanks Jose! I will try the longer dry season stack as you suggest as I had not thought of that. However, I still think my results are conclusive, even for the short stacks. I have uploaded a spreadsheet for you to see my results, and perhaps this will convince you that the short stacks are working 8-). The spreadsheet contains time series with plots for 3 stacks (7, 11 and 21 interferograms). The time series are for PS nearby to the powerful geothermal well (see yellow squares on maps in spreadsheet) and all show a clear and strong subsidence signal (about 40 - 60 mm per year).

Geothermal well time series for different stack sizes.xlsx (2.9 MB)

Also, I do have access to the literature and I have had a good look as you suggested. I have found a few papers where the “20 minimum stack size” is mentioned, but never properly explained. Do you have a good reference? It seems that if you have a strong and smooth subsidence signal (like a geothermal well causing subsidence), then this may be an exception to the “20 stack rule”? Do you agree?

mdelgado · February 2, 2020, 9:32pm

I hope you understand that 20 images is a good practice.

Che k in the literature many of the papers doing PSI, and then see how many images they normally use.

It may be the case using few due to data restrictions/ constraints or availability. But this is not the case for sentinel1