And I’m using the ASTER GDEM v3, mosaicked into a single DEM using gdal. I’m using it as an external DEM, since any attempt to use the tiles I’ve downloaded to the auxdata/dem directory haven’t been successful. The DEM has spatial reference of wgs84 lat/lon, so there shouldn’t be any issue with using a projected coordinate system.
After applying the orbit file and calibrating the image, I get the following error message when trying to apply terrain correction: ‘The specified region, if not null, must intersect with the image’s bounds’. I haven’t attempted to specify a region in the tool dialogue, so I’m not sure where this is coming from.
Below is a screenshot showing the outline of the scene in question (1) and the DEM (2), showing that the two products do overlap.
Instead of manually mosaicing the ASTER DEM and entering it as an external DEM, you could also place the original files in the DEM folder of SNAP and select ASTER from the drop-down menu as described here: Iceland Aster DEM Coregistration Auxdata. Maybe then SNAP processes the data as needed.
I did this, including unzipping the tiles, changing the filenames to reflect that this is ASTER GDEM v3 instead of v2, and still no luck. Running SNAP on Linux, I can get it to run without the same error that pops on Windows, using the exact same DEM file, but it only returns a fully NAN image as a result.
If I just run the SAR simulation step (no correction), I get an image that looks as expected:
So maybe there’s an issue in the co-registration step that follows the simulation step (in addition to the error that prevents it from running any of the steps in Windows)?
Apparently the answer here was not to check “Test whether GCPs are on land”, as this was apparently leaving me with no GCPs for the co-registration. I managed to get a passably terrain-coded SAR image after this fix. Still no idea why this won’t work in Windows, though.
and show us the content of the window which opens afterwards?
