these are very good suggestions, thank you. I hoped that this can be resolved within a small update and is fixed within the next days, but depending on the response of the developers we might take more action to guide users which struggle. A temporary FAQ entry is a good idea!
I created a FAQ entry here: A process related to digital elevation models is taking forever to finish
Did I miss a crucial point?
Excellent FAQ entry. Hopefully it will reduce the stream of forum posts on the topic as well as reaching some who won’t post for various reasons like lack of confidence when writing in English.
Thank you for your support.
Hi
I did the same methods, but the changes are not saved.
Can you help?
thank you
Hi
I tried both, but it still didn’t work.
can you please specify what exactly did not work? Were you able to change the file? Have you tried SRTM 1Sec instead? What happens?
If SNAP somehow tracks which DEM’s have been requested separately from the actual files on disk then treating the files as an external DEM might be required. If there is no tracking, there might be an issue with ownership and permissions of files transferred from another system.
just wanted to highlight that the latest update fixes this problem.
Please still make sure that no incomplete files are left in the aux directory.
Hi Andreas,
I was trying to reproduce the RUS Copernicus webinar on SNAP2StaMPS – Data preparation for StaMPS PSI processing with SNAP.
I was able to follow all of the steps of SNAP2StaMPS workflow except the last one, which is StaMPS export. I have tried to run the scripts using both SNAP version 8 and 6 but got the same result.
Searching the forum, I though it was an issue with the SRTM dem. So, following your recommendations, I changed snap.auxdata.properties, and emptied SRTM 3Sec folder. But that does not work either.
Could you please have a look at it suggest what am I missing here?
I am attaching the python script, graph, configuration files for your reference. Note that I was using the High Performance Computing (HPC) facility of University of Newcastle, Australia. I have access to 6 CPUs and 46GB of RAM.
Thanks in advance for your support.
Best regards,
Palash
StaMPS_export_issue_PB_20210204.zip (14.0 KB)
Dear Palash,
I am currently facing the same problem and we discussed this in another topic.
For some it seemed to work to update the SRTM source as described here: Problem in the last part of snap to stamps
But this doesn’t solve the problem for all.
Still, I recommend installing the latest update
We have created a ticket for this here and let you know once it has been resolved: https://senbox.atlassian.net/jira/software/c/projects/SITBX/issues/SITBX-834
Does the module update 8.0.3 from yesterday not fix this issue?
strangely, it doesn’t.
It works for Range Doppler Terrain Correction, for example, but the StaMPS export still gets stuck in a loop.
Even when SRTM 3Sec data are deleted from the aux folder, they will not be re-downloaded by the StaMPS export after installing the update.
Thanks for your prompt response, Andreas.
I re-installed SNAP 8.0 and updated that to 8.0.3. After that I was able to perform the export.
1 Like
Hi Marcus,
Yes, the issue has been resolved with the udate.
1 Like
Thank you for the response. I will try re-installing as well.
Edit: I can confirm that the problem with the StaMPS export is solved after re-installing SNAP 8 (including the removal of user configuration data) and installing all updates.
1 Like
Thank you ABraun when i use the * at the end of the path it works in Sanp 6.0. But i look at snap 8 the snap.auxdata.properties file * dosent consists at the end of the path so it dosent work stamps export.py.
this path is working for all snap version DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/*
1 Like
Hello everyone,
I’m facing an issue during the export step of snap2stamps. As you can see in the image below, the export takes really a lot of time, from 40 min to several hours for each file (for comparison, the coregistration took 5/7 min each) while usually with the same computing resources emploied, it takes a few minutes. Furthermore, despite the export is marked as “succesfully completed”, there are several “severe” and a “warning” whose meaning is not clear to me. I fear that the exports will be somoheow “corrupted”.
I’m running this step with SNAP 7.0, I also tried with SNAP 8.0.6 but in this case the folder INSAR_… was incomplete. In fact, using SNAP 8.0 the entire “dem” folder and the .diff and .base files for each export within the “diff0” folder were missing.
I also tried changing manually the line 27 with the string proposed but the problem persists.
Does anyone have an idea about this issue or how to solve it?
Thank you in advance!
