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

Thanks ABraun! I looked at that thread and it seems I should stay on SNAP 6 so I can run splitting_slaves and coreg_ifg_topsar. I just need to figure out how to manually download orbit files for use with stamps_export. Does this sound right?

actually, the orbit files are applied in the first script (splitting_slaves.py) while the export partially struggles with inavailable DEMs. But this can be solved by this hint here or also this one: Using StampsExport with an external dem

Dear Wharfbanger,
Please follow below steps (After updating to SNAP8.0.3).

SNAP FAQs - SNAP - SNAP Wiki (atlassian.net)

If that SRTM link won’t work, insert below one.

Thanks. I have now updated to SNAP 8.0.3 and changed line 27 in snap.auxdata.properties
to:

DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

Still stamps_export is stuck…

I’m out of ideas then, sorry.

Try this link, it is working from me.

A quick update. I now have a work-around to complete snap2stamps by running splitting_slaves.py, coreg_ifg_topsar.py under Windows 10, python 2.7, SNAP 8.03.

I then switch to Ubuntu 16.04 for stamps_export.py and mt_prep_snap and StaMPS to complete my processing.

I would like to be able to run everything in Ubuntu 16.04 as was doing previously, but coreg_ifg_topsar.py fails with the following message:

I tried installing libgfortran3, libgfortran4 and libgfortran5, but this did not solve the issue. Is anyone running coreg_ifg_topsar.py successfully in Linux? If so, what is your Linux version? Python version? SNAP version? Anything else I might be missing?

Dear ABraun,

I have almost the same problem, but in my situation the manual coregistration works well. So, I think the problem is in the file coreg_ifg_topsar.py.



What happens is that the master and the slaves splitting works well " I must admit that it worked well after I changed the pathlib to pathlib2 in the three files: slaves_prep.py, splitting_slaves.py, coreg_ifg_topsar.py".

But when I execute the command for the coregestration (python2 coreg_ifg_topsar.py project.conf), it takes only about 2 seconds for each pair of photos and of course the the ifg and coreg folders remain empty.

What should I do please, knowing that I am using Ubunto and Snap 8?

With all my respects this is not possible.
The issue may be on your configuration or SNAP, as snap2stamps scripts are simple wrappers, which when used as mentioned in the user manual should work.

Things that had changed in the meanwhile are orbits and dem repositories, which can be handled in several different ways.

  1. you update SNAP
  2. you feed the .snap/auxdata folders with the needed aux data (Orbits, dem…)

In the future… snap2stamps will be compatible with last SNAP version, so will help users to overcome that kind of issues

2 Likes

Dear Mdelgado,

Thank you for your kind help.
I mean by the problem could be in the coreg_ifg_topsar.py that I maybe should update the version of the file.
I attached a photo of my configuration, could you please tell me if there is any thing wrong?, knowing that I used the project.conf to split the slaves and the process went well.
How could I update Snap (I have read that Snap 6 has no problems but I do not know if the 6 version is Ok with Ubunto) and could you explain a little bit more the second point about aux data?. Thank you.

Dear all,

I’m new to field of SAR-processing, especially the snap/stamps-workflow. I’ currently stuck with the preprocessing-part, more specific: at the coregistration and interferogram step (coreg_ifg_topsar.py).

I get and error that [NodeId: Enhanced-Spectral-Diversity] Operator ‘SpectralDiversityOp’: Unknown element ‘useSuppliedRangeShifts’. (I changed the parameter suppliedshifts in the coreg_ifg_computation and core_ifg_computation_subset xml).
I’m not using any external dem for my current work.
along you find my project.conf aswell as a screenshot of the error in my comand prompt.
My guess is either a change in folder structure is needed or a change in the xmls.
I’m thankful for every help.

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

2 Likes

You are not using SNAP v6, so you need to update the parameters of the ESD operator as explain by @ABraun

1 Like

Dear Mdelgado,
I’m using SNAP2StaMPS python wrappers for the last 4 months onwards. Code is very nice to process a long set of data. But while running StaMPS_export.py step, if in between power shadown happen or it is stopped due to some other reasons. Again I want to rerun the step it is running from starting onwards. So if it possible please arrange the continuity from where it stopped.

Thank you.

Well, with the current scripts available your best option is to moved the files (*dim should be enough) that had been already exported from the COREG and IFG folders. Later launch the stamps_export.py and it should work.

Let me know.

#####################################################################

/mnt/e/Talala_zip/ifg/20190414_20180218_IW2.dim
[28] Exporting pair: master-slave pair 20190414_20180218_IW2.dim

[’/usr/local/snap/bin/gpt’, ‘/mnt/e/Talala_zip/graphs/export2run.xml’, ‘-c’, ‘100G’, ‘-q’, ‘40’]
SNAP STDOUT:INFO: org.esa.snap.python.gpf.PyOperatorSpi: Python operator ‘py_sambuca_snap_op’ registered (Python module: ‘sambuca_snap_op’, class: ‘sambuca_snap_op’, root: ‘/root/.snap/system/modules/org-esa-sen2coral-sen2coral-inversion.jar’)
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: GDAL 2.2.3 found on system. JNI driver will be used.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Installed GDAL 2.2.3 set to be used by SNAP.
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Installed GDAL 2.2.3 set to be used by SNAP.
Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
first_line_time metadata value is null
last_line_time metadata value is null
…10%…20%…30%…40%…50%…60%…70%…80%…90% done.

[28] Finished process in 3131.3216691 seconds.
Stamps export of 20190414_20180218_IW2.dim successfully completed.

#####################################################################

/mnt/e/Talala_zip/ifg/20190414_20180302_IW2.dim
[29] Exporting pair: master-slave pair 20190414_20180302_IW2.dim

[’/usr/local/snap/bin/gpt’, ‘/mnt/e/Talala_zip/graphs/export2run.xml’, ‘-c’, ‘100G’, ‘-q’, ‘40’]
SNAP STDOUT:INFO: org.esa.snap.python.gpf.PyOperatorSpi: Python operator ‘py_sambuca_snap_op’ registered (Python module: ‘sambuca_snap_op’, class: ‘sambuca_snap_op’, root: ‘/root/.snap/system/modules/org-esa-sen2coral-sen2coral-inversion.jar’)
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: GDAL 2.2.3 found on system. JNI driver will be used.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Installed GDAL 2.2.3 set to be used by SNAP.
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Installed GDAL 2.2.3 set to be used by SNAP.
Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
first_line_time metadata value is null
last_line_time metadata value is null
…10%…20%…30%…40%…50%…60%…70%…80%…90% done.

[29] Finished process in 3116.62091494 seconds.
Stamps export of 20190414_20180302_IW2.dim successfully completed.


Dear Mdelgado,
**The above processing stopped after finishing the 29th step , If I rerun, It should start from the 30th step onwards. **
I didn’t get your point. please explain clearly.

This option is not implemented in this version release of snap2stamps.
Your option in here right now is to remove the first 29 slaves from the COREG and IFG folders which had been processed.

There you will find the files called 20190414_20180302_IW2.dim and *.data . You may move this in a backup folder.

By doing that the snap2stamps does not will find them to process again, and hence the processing will start on the remaining processed IFG/COREG pairs

2 Likes

Thank you so much.

Hi @mdelgado Thank you very much for your contribution. I am a beginner and I have a problem, I hope you can help …
When I run slaves_prep.py I get the following error.
File “slaves_prep.py”, line 33

  • print P*
    Download snap2stamps from the sites you recommended and i am using python 3.8.5

I’m using python2 the snap2stamps code working good.