Please test the SBAS_snap2stamps

this indicates the process is still running?


The java error message does not say much about the reason of the error.

no the process ends with the error I reported in the image.
regarding the error I asked for help in the link you sent me

@ABraun @Linya-Peng @dongyusen
maybe the problem is because in the xml file there is no ESD operator, when I open it on snap nothing is written?
I ask to better understand the process

this is because the GUI does no longer match the fields in the XML, but currently, only these changes are required.

For XML is ok, already same as @ABraun mention.

I using SNAP 7 and python 2.7 and no problem at all, except the DEM process after December 2020.

I don’t know where the wrong for this case, but I suggest between AOI AREA nad AOI clip, please check again.

You can check AOI AREA and AOI clip area in snap desktop, and please make AOI clip area less than AOI AREA.

In SBAS_snap2stamps for cropping area need 2 steps than in snap2stamp only 1 step, maybe @dongyusen has any explanation about this?

I will dobule check codes and xml files in this week with snap8 and python3.8,


Support of SNAP 8 would be highly appreciated :+1:

i using snap 8.0 and python 2.7 and i have the error mentioned above. i tried your advice but i have the same error, ihave the same coordinates in THE CLIP AOI and i change the AOI LONG E LAT MORE EXTENDED.
I don’t belive that is the problem of python version @ABraun

I have never said that :slight_smile:

thank you for this note. How exactly should a missing pair be added to the sbas_add file? I’m not quite sure about the formatting.

Edit: Nevermind, I found it out. It should look like this


Simply a combination of both dates. Once these are added, I updated the baseline in the config file and ran both scripts again, sbas_topsar_coreg and sbas_topsar_ifg. Or is this too much to manually add connections?

Script works well so far, thank you @dongyusen

No, your step is right @ABraun.

But you should pay attention to time baselines in sbas_topsar_ifg, you may have to change them to longer according to the maximum time difference of the interferogram pairs you add. If you don’t change, it could be that the interferogram pair you added will not be processed in sbas_topsar_ifg.

Hi ABraun!
May I ask which SNAP version and python version did you use to run the script? I still couldn’t form ifg after successfully finishing coregistration, only coreg pairs of supermaster and slave could form ifg successfully. I don’t know whether it is a version problem or I did something wrong :worried:

SNAP 8.0.3 Python 3.8

the error during the interferogram computation is caused by the Land Sea Mask operator which tries to download SRTM 3Sec data as well. Updating SNAP and deleting incomplete zip files should help, otherwise you can remove the Land Sea Mask operator from the XML (sbas_topsar_1iw-seamask.xml, “Read” should directly feed into “Inteferogram”)

I removed the Land Sea Mask operator, but the error still existed. However, when I modified the NCOLS and NROWS from <Raster_Dimensions> in .dim file, and made their values same as <BAND_RASTER_WIDTH> and <BAND_RASTER_HEIGHT>, then the ifg can formed. I can’t understand why this problem took place, and whether the ifg results were right :thinking:,Do you have any idea?

Thank you in advance~

are you sure? It is important to not only delete it in the XML but then use Read as input in the next step. This allowed me to proceed with this step.

About the NCOLS and NROWS - this is what worked for me:

  1. TOPS Split
  2. TOPS Deburst
  3. Subset to the area of interest (noting down the pixel extents [1])
  4. Range Doppler Terrain Correction
  5. Draw Rectangle around the area of interest (larger than the subset)
  6. WKT from Geometry (note down geographic coordinates [2])
  7. Enter [1] under CROP
  8. Enter [2] under AOI

Yes, I also used “Read” as input in next step. But for the AOI in the configure file, I just got the geographic coordinate from Google Earth, while for the Clip Area in the configure file, I just got the CropSx , CropSy, CropWx , CropWy from the Split results (Maybe this is where the error came from?)

By the way, CropSx , CropSy mean the start( Left up) pixel of the subset, and CropWx , CropWy mean the width and height of the subset, is that right?

Thank you for your patience! :smiley:

yes. I used the numbers from the subset tool, but in the end it shouldn’t matter how these were retrieved as long as there are no logical errors. Let’s wait for a fix of the StaMPS export so we can proceed.

OK~Thank you again for your patience! :grinning:

Hi ABraun! Sorry to disturbe~
I found that my Split Results didn’t share a same footprint

If 2 images are not in the same extent(for example one is bigger than another), and we didn’t subset before interferogram, will error occur?