Unable to create RGB window for the coreg image, nor can I open image view for either ifg or coreg images. The SNAP - Error box reads, “java.lang.RuntimeException: Waiting thread received a null tile.”
and when you open both intensities separately?
Trying to open the coreg master intensity results in this error box, “A java.util.concurrent.ExecutionException exception has occurred,” for the slave intensity, “java.lang.NullPointerException” (this latter error message also results from trying to open the ifg intensity).
that means the coregistration was not successful. Which DEM is used during the coregistration?
SRTM 3Sec - that is the default, right?
yes, the default, but currently unavailable: SRTM ZIP-files are corrupted or not found
Please try switching to SRTM 1Sec HGT (AutoDownload) until the error is fixed.
1 Like
Hmm, ok. Do you know if that has been happening intermittently over the past couple of weeks? Or has it been continuous?
I wonder if the Stamp Export could be affected by the same issue (I processed the previous AOI last week).
actually, the stamps export should not be affected, because the DEM data is already part of the interferograms. But if the DEM was not written correctly at the interferogram creation step, it will not be exported.
This has happened a couple of days ago when the link to the SRTM 3Sec data had changed. It will be fixed with the next SNAP update, but so long, SRTM 1Sec is the only option.
Ok, and by ‘will not be exported’, do you mean that neither the snap2stamps script nor the SNAP GUI will begin the export process? Or will they just run indefinitely?
It’s strange because the coreg and ifg images for the first AOI (processed using snap2stamps) seem correct (I just can’t seem to export them).
Can the snap2stamps scripts be modified to use SRTM 1Sec?
I’ve just tried both SRTM 1Sec HGT and Grid in TOPS+ESD Coregistration, and neither seems to work (I get the same “java.lang.NullPointerException” error).
I really don’t know, sorry. I can only report this:
What happens if you run the export for one pair and the corresponding interferogram?
Have you managed to correctly modify the coregistration xml to use the SRTM 1Sec instead?
Is it coreg_ifg2run, coreg_ifg_computation, or coreg_ifg_computation_subset that I would need to edit? Although currently I already see SRTM 1Sec in all of these (the following image is from coreg_ifg2run.xml):
If that is already entered, it should make use of the correct one, no need to change then.
Sorry to say this, but snap2stamps is a user-provided tool and ESA takes no warranty that it works under any circumstances. I can’t think of a reason why it fails in this case.
Have you tried to coregister an image pair with BackGeocoding in the GUI for a test?
I understand of course!
I’m currently downgrading from Ubuntu 20.04 to 18.04 (should’ve done already…), as I realize there are issues peculiar to the former.
I’ll see whether that resolves anything.
Following a downgrade from Ubuntu 20.04 to 18.04 LTS, upgrading RAM to 32 gb, and using SNAP v6, snap2stamps has been fully executed.
After running mt_prep_snap, however, I received an initial message after the opener, “matlab: permission denied,” and then the process continued- it’s still underway, but amplitude estimates have now been produced for all 114 images, as have their interferograms. Does that message indicate the results will be erroneous?
No actual error messages have appeared yet (3/9 patches processed). I went ahead and changed the matlab installation folder contents’ permissions to read/write, hopefully that doesn’t mess something up!
Good luck then! It’s good to plot the intermediate results every now and then to check if the data look alright
This only means that you do not have matlab in the environmental variables which can be found from mt_prep_snap and a starting file will not be created.
However, this can be created within MATLAB while running stamps itself.
Ok- and could any resulting files have been affected?
Also, on a slightly unrelated matter, does the application of TRAIN to snap2stamps PSI make much difference, since only the master APS is estimated (data set of 114 images, including master)?
no.
TRAIN cannot be applied to snap2stamps.
TRAIN is applied together with StaMPS processing, not to snap2stamps. Please do not mixed terms,
TRAIN does not estimate only APS for the master image. I believe you are confused.
Please read TRAIN manual and tutorial so that you will see that TRAIN estimates APS for each of the images, and the different options for it.
Ok, yes- I seem to have misread this post
There seems to be an issue with this link, however
http://gmt.soest.hawaii.edu/gmt/gmt_download.html
Is there any other way to access that software?
can you try to get GMT5SAR?
I think they moved time ago the website.
I have found using google this repo, but not sure is the official one, you better check it: