The error in fact could be due to any issue with the place from where SNAP tries to retrieve the SRTM DEM, which seems to be hosted by step.esa.int
Can any of you @marpet, @lveci confirm that the repository is still valid?
Thanks!
1 Like
@ABraun Thank you for your nice suggestion.
@mdelgado Exactly but I run the package for two study areas. I didn’t have this warning in first one but in the second study area, where is in Indonesia, I faced this message. So, I was worried about the coverage of SRTMGL1 over this area 
Dear Braun,
I checked your suggestion and found the elevation band in the correct style but when I finished the time-series processing by stamps, I got my results as follows:
They are strange especially in the upper half of the image. Do you think it happened due to that warning about the DEM and anything for coregistration?
@mdelgado Could you please look above figures and let me know your comments?
how does the coregistered image look like in snap?
Unfortunately, I have to delete all ifg and coreg files because of my storage capacity limitation in my user at RSS cloudtoolbox. I must download the dataset again and follow the progress.
1 Like
Wondering if the problem could have been in the master image.
Please check step by step the intermediate products before proceeding
1 Like
Which problem do you think maybe happen in the master image?
It could had happened during the master split, just for guessing. It must be something happening to each pair, hence it could be either master or Dem related
@mdelgado I checked the availability of two tiles of SRTM which cover my study area through these links:
http://step.esa.int/auxdata/dem/SRTMGL1/S10E110.SRTMGL1.hgt.zip
http://step.esa.int/auxdata/dem/SRTMGL1/S10E111.SRTMGL1.hgt.zip
Unfortunately, I couldn’t find them through these links. So, I think my issue in the results will be related to the lack of DEM files. How can I follow this issue? Should I change the used DEM to another one in the snap2stamps package? @marpet @lveci
You can download them and put them in the target folder specified in the snap configuration files for auxiliary data.
That should work
@mdelgado Sorry, I said I couldn’t find them in these links. It means they are not available to use in processing.
Did you give this point about other DEMs?
I know what you said, but you can check the availability of these tiles on other sources.
I do not know by heart from where but probably USGS or other official sites may offer the srtm Dem 1arc, or you can choose other Dem where may have the tiles over your site
I am processing a time-series of S1 images over my study area using the snap2stamps. When I got the results for one slave-master pair, I checked the generated ifg and found a strange situation there. You can see the interferogram:
I chose two bursts from each of two images, which must be assembled to cover my study area. I checked the topography and found it OK:
Could you please guide me in this situation? As you can see, the package show a successful progress for this pair:
Could you show the coregistered stack master slave?
The package shows the successful operational steps but not the integrity of the content. That is on the user to check that master, slaves and other products are fine after each of the steps.
I hope this helps
Merry Christmas
I checked the state of that slave after the splitting step and found it strange as follows:
Left side: Master, right side: Slave
As you can see in world view panel, it seems that the splitting didn’t work and all bursts have been selected to assemble together
Could you please tell me how I can determine the accurate boundary in “project.conf” file?
Thank you. Same to you 
On the current scripts slaves are splitted using only subswath so after split looks fine to me as the master area is covered in the slave, right?
Can you check the master slave stack saved in the coreg folder?
Aha, you mean that the code will not do any bursts selection in this time? Just assemble one subswath of two images?
You can see, I confused about what happened
Right side: Master, Left side: Slave
Probably due to memory settings.
Which configuration had you used?
