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

Sorry again. I run the package and faced the following warning about the DEM file for the coregistration and interferogram generation:

I checked those files and didn’t find them in the SNAP server. I checked and found that they are located on the sea. So, officially, there is not any DEM file in these locations. I checked the “elevation” band in ifg files and found it in the correct style.

Do you also think it is OK?

yes. if the DEM in the product looks alright, you can neglect this warning.

1 Like

Additionally, I would say that normally you should not get PS on the sea, so there will not be a wrong estimation.

So if you are looking for points on land, I would say that you can go ahead with the processing.

Do you agree?

1 Like

yes, there are always some few points which are accidently identified as stable over water, but with a low threshold allowing for random pixels in an area (density_rand) and a low standard deviation during the weeding (weed_standard_dev) only a sparse occurence over water should remain.

1 Like

Hello, Andy and mdelgado. It is so convenient to use python scripts to do all data preparation for stamps. I am new to SNAP. I followed the manual and your guidance here to process my Sentinel data. I used snap7.0 but still met the proplem that operator ‘SpectralDiversityOp’: unknown element ‘useSuppliedShifts’ when I did corregistration. Could you please tell me what I should do to provide “spectraldiversityop”?

we had discussed this error earlier

It is related to the ESD operator which is not needed when working with only one burst.

Thanks for your quick reply. My test area covers 3 bursts and I got the problem exactly as what Duan met before and they suggested us using SNAP6.0 or new version. I tried but still failed. Is there any other hint?

The problem indeed is that you were using SNAP 7. This latest version updated the tags employed on the parameters of the ESD Operator.

You should update those and the issue will be solved. I am planning to update it in a new release, but in the meanwhile I suggest you to follow the solutions posted in the forum, as suggested by @ABraun.

Let us know if you need further help.

I got it. Thank you so much!

1 Like

@mdelgado, @ABraun,

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

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

1 Like

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.

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.

@mdelgado

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

  1. 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 !

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

You can prepare them with three steps:

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

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.

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

1 Like

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.

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

this is the content of the project.conf