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

Have you tried this?

1 Like

Thanks Suri! I can now complete all snap2stamps except stamps_export.

stamps_export does not complete, it just stops at this point:

I am currently running Ubuntu 18.04, SNAP 6.0, Python 2.7.17 Any suggestions?

Please update SNAP latest version 8.0.3

This version does no longer work. Problem in the last part of snap to stamps

Thanks @ABraun but upgrading to SNAP 8.0 did not fix the problem last time, and has not fixed things this time. stamps_export.py still does not run and now that I upgraded to SNAP 8.0 things are worse because splitting_slaves.py does not run.

So now I am back to where I started this thread:

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

## TOPSAR Splitting and Apply Orbit

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

[1] Folder: 20190517
/media/wharfbanger/Data1/Project/StaMPS_Export/slaves/20190517
[’/media/wharfbanger/Data1/Project/StaMPS_Export/slaves/20190517/S1A_IW_SLC__1SDV_20190517T172929_20190517T172959_027270_03132F_D83E.zip’]
FILE(s) : /media/wharfbanger/Data1/Project/StaMPS_Export/slaves/20190517/S1A_IW_SLC__1SDV_20190517T172929_20190517T172959_027270_03132F_D83E.zip
[’/home/wharfbanger/snap/bin/gpt’, ‘/media/wharfbanger/Data1/Project/StaMPS_Export/graphs/splitgraph2run.xml’, ‘-c’, ‘8G’, ‘-q’, ‘8’]
SNAP STDOUT:INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
Executing processing graph
INFO: org.esa.s1tbx.commons.io.ImageIOFile: Using FileCacheImageInputStream
INFO: org.esa.s1tbx.commons.io.ImageIOFile: Using FileCacheImageInputStream
INFO: org.esa.s1tbx.commons.io.ImageIOFile: Using FileCacheImageInputStream
INFO: org.esa.s1tbx.commons.io.ImageIOFile: Using FileCacheImageInputStream
INFO: org.esa.s1tbx.commons.io.ImageIOFile: Using FileCacheImageInputStream
INFO: org.hsqldb.persist.Logger: dataFileCache open start
Exception calling QC Rest API: Connect to qc.sentinel1.eo.esa.int:443 [qc.sentinel1.eo.esa.int/131.176.235.71] failed: Connection timed out (Connection timed out)
WARNING: org.esa.s1tbx.sar.gpf.orbits.ApplyOrbitFileOp: Connect to qc.sentinel1.eo.esa.int:443 [qc.sentinel1.eo.esa.int/131.176.235.71] failed: Connection timed out (Connection timed out)
Exception calling QC Rest API: Connect to qc.sentinel1.eo.esa.int:443 [qc.sentinel1.eo.esa.int/131.176.235.71] failed: Connection timed out (Connection timed out)
Connect to qc.sentinel1.eo.esa.int:443 [qc.sentinel1.eo.esa.int/131.176.235.71] failed: Connection timed out (Connection timed out) due to Connection timed out (Connection timed out)
** done.**

Error: [NodeId: Apply-Orbit-File] Connect to qc.sentinel1.eo.esa.int:443 [qc.sentinel1.eo.esa.int/131.176.235.71] failed: Connection timed out (Connection timed out) due to Connection timed out (Connection timed out)

[1] Finished process in 276.049514055 seconds.

I am now running Ubuntu 18.04, SNAP 8.0, Python 2.7.17 Any suggestions?

I see, sorry. Sometimes all the different issues become confusing and hard to overlook.
The orbit problem is related to this: Orbit file timeout (March 2021)
It is fixed for the GUI but retrieval of orbits from GPT or snappy is still not working in all cases. Hopefully, an update will solve it.

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.