Snap2stamps error

please have a look here:

1 Like

Hi, Abraun! Thank you for the quick reply. I will try the solutions stated on this separate topic.

Thank you again! :slight_smile:

yes, feel free to report.
I am still not entirely sure if this also applies when the inteferogram was calculated before the location of SRTM 3Sec changed. But I experienced the same error and do not have another explanation (neither do the developers at the moment)

Thanks @ABraun!
Still… it sounds funny that the SNAP operator StaMPSexport is not taking the dem band directly and convert its format, but it tries somehow to get access to the dem again.

Is it that? Or am I still missing anything else?

can this be seen by developers so that they can update the operator for more efficient and logical processing?

that’s what I wonder, yes. Doesn’t make sense, but I talked to the developers and using SRTM 1Sec or changing the SRTM 3Sec path is what they suggested.

Anyhow, this will be fixed when the new location of SRTM 3Sec is implemented, but still strange.

1 Like

hi i got the same problem but in version 8 updated today.


I saw that the file had to be modified:

but mine was updated today and I sensed that nothing had to be modified, because it was not the same as the indications previously offered.

So, some solution @ryeramirez @ABraun

if you have processed the interferograms with SRTM 1Sec, there should be no problem at all, because the download only affected SRTM 3Sec.

So the export still stops with SRTM 1Sec?

How do I know with which of the options the images were processed?

I did not modify any files, nor instructions.

In my ignorance, I think it used SRTM 1Sec, since if there are self-discharge problems, it is logical to think that it directly downloads SRTM 1Sec

In that case I would say yes, despite using SRTM 1Sec, snap2stamps stopped.

In this case SRTM 1Sec was used (line 69 of this file)

Very strange indeed, your screenshot also indicates that SRTM 1Sec was used. So the problem with the export is not related to the changed availabiltiy of SRTM 3Sec. You did nothing wrong, don’t worry - we just haven’t found the reason for the error in general.

Can you try with the SNAP GUI exporting a single pair using the StaMPS export operator?
Can you tell us if this works?

Hi, @nachin6789!

I did solve the problem following the work around solution proposed by @ABraun.

You can find it here at the last message: SRTM ZIP-files are corrupted or not found

Thank you @ABraun as always.

1 Like

thank you for reporting. May I ask which of the two solutions worked for you? And what version of SNAP did you use?

I used this solution.

Change it from
DEM.srtm3GeoTiffDEM_HTTP = http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/
to
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

I am using SNAP 7.

thank you for reporting - good to know.
Did you re-compute the interferograms based on the new SRTM 3Sec source or has changing the source already solve the export from being stuck?


I think it works halfway, I generate 4 exports to test, it seems that everything is going well but the dem folder, I think it needs to generate the projected_dem.rslc file

In any case, if snap2tamps is executed, only 1 of all images is generated (that is, it seems that it is only capable of creating 1 image and then stops iterating with the rest of the images)

Hi, @ABraun!

Since I am doing the processing per batch (i.e. per 10-20 images), which is in my experience a lot faster compared to processing the whole dataset in one run given the current resources I have, I didn’t do any interferogram re-computation for the batches I have processed before experiencing the problem.

And to trace any source of error when doing StaMPS analysis after processing all batches, I have separated the diff0 and rslc folders created thereafter (after doing the solution proposed). I will merge all all soon.

I hope this won’t create another issue during the StaMPS analysis.

Thank you.

1 Like

This surely helps us, thank you!

Hi, @ABraun

Just an update.

After combining all preprocessed data before and after implementing the solution proposed, the StaMPS processing was successful.

Thank you.

1 Like

Sounds good, thank you!

Dear Sir,
I recently updated SNAP Latest version for SNAP2StaMPS processing. My server having these below specifications. Processing 52 interferograms creation it took around 3 days time. Please suggest what setup i wanna change in my Windows 10 server.

system_specifications