Problem in the last part of snap to stamps

Do you mean that this proposed link has been failed too? http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

no this should work. But any invalid file in the directory should be deleted after you have modified the aux file.

this link doesn’t work for me…so how can I force the stamps_export step to use srtm1 instead of srtm3?

you cannot open it in a web browser, but if you replace the line by
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

SNAP will find the data and download it.

This is not possible without coding it on your own.

I did it as you mentioned in your previous recommendations! but in ubuntu18.04 it works well and everything is ok…but in ubunu20.04 with the same data and same version of snap, the last part of analyses(stamps_export) doesn’t work.

have you also checked for invalid files?

I do all of recommendation steps, but it still remains at 4th step of snap2stamps without any error and any progress!!

Hi again dear ABraun… can we download the dem from any site such as http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/ and put it in the dem folder of the auxiliary file?

It will take some time, You want to check whether it is running or not. For that just open working directory, then open INSAR_20170627 folder and it will contain Four folder (manily diff0 will contain each and every InSAR file like master_slave.diff)

i don’t want to check its running progress. I tried all suggested solutions but none of them work for me…so I downloaded dem of my study region then run stamps_export.py…it worked but I am not sure this solution is logical or not…

@ABraun @marpet

The main question still remains, why the StaMPS export module tries to download the dem again, even if the elevation band is already present in the inteferogram stack imported ?

Has this been changed in SNAP 8 or planned to change in SNAP 9?

For what I have seen even the StaMPS export tries to get the SRTM 3Sec anyway, despite the DEM employed during the TopoPhase Removal of the Interferogram operation.

If at least it would consider using the same DEM employed in the topophase removal, there would be no problem. However, currently the operator looks for a hardcoded DEM, i.e the SRTM 3Sec on a non-available server, which makes it never end.

This is probably a question @lveci can answer better.

Hello,

I’m encountering the same problem as you have (except I’m running all of this on my PC). Did you find the solution in the end?

1 Like

have you seen the suggestions by traktor made in this topic? Using StampsExport with an external dem - #22 by traktor
I deleted your other topic, please don’t cross-post over multiple topics.

Hello, thank you very much for your prompt response.

I’ve followed the method described by traktor where I:

  1. downloaded the updated file (StampsExportOp.class),
  2. unzipped ‘org-esa-s1tbx-s1tbx-op-insar.jar’,
  3. replaced the old file with the new one

I then ran the ‘python stamps_export.py project.conf’ in the windows terminal. The problem still persists. I then thought maybe I should re-open snap for the changes to be implemented. However, I get this error message as it opens up :

“Warning - could not install some modules: S1TBX Sentinel-1 Tools - The module named org.esa.s1tbx.s1tbx.op.insar was needed and not found. S1TBX SAR Processing - The module named org.esa.s1tbx.s1tbx.op.insar was needed and not found. S1TBX SAR Processing UI - The module named org.esa.s1tbx.s1tbx.op.insar was needed and not found. S1TBX InSAR Tools UI - The module named org.esa.s1tbx.s1tbx.op.insar was needed and not found. S1TBX IO Orbit Ephemeris UI - The module named org.esa.s1tbx.s1tbx.op.insar was needed and not found. Sentinel-1 Toolbox Kit Module - The module named org.esa.s1tbx.s1tbx.op.insar was needed and not found. 4 further modules could not be installed due to the above problems.”

I don’t really know what went wrong.

Sorry to hear that. I have never tried it myself but others reported that this solved it in their cases.

Hello,

I tried running it again this morning and I’m getting this error message.

Slightly different from what happened last night, but still not working. Does this narrow down the issue a bit more?

also, was the ‘DEM.srtm3GeoTiffDEM_HTTP’ supposed to be set to
http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/’ or
http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/’ because mine is set to the latter even though I’m using the updated version of Snap.