Replies: 1 comment
-
For future reference and anyone who runs into a similar issue, this was resolved by changing the nodata value from nan to -32678 (the same nodata value used as SRTM DEMs). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello all!
I have been working with isce for a little while now and I created my own 5-meter resolution DEM by mosaicking Maxar/DigitalGlobe stereo optical data to test some SAR processing. I have converted the DEM format to match that of a isce-compatible ENVI DEM (I used gdalwarp to get dem.envi, dem.hdr, and dem.envi.aux.xml. Then I used gdal2isce_xml.py to get dem.envi.xml-- Please see gdalinfo in screenshot attached below).
The processing however, (which has worked smoothly with other DEMs at 10-meters (3DEP) and 30-meters (SRTM)), always gets stuck on step 1: unpack topographic reference. There is no error, it just keeps running for 24:00:00 hours until it times out, but always 'stops' at line 178: (See run_01 file below). I have tried to increase the number of tasks/nodes that the job runs on and increased the amount of memory allocated to the job but it is the same issue.
run_01_unpack_topo_reference_output_844587.txt
The DEM covers my boundary box input when I submit:
stackSentinel.py -s ./SLC/ -d ./DEM/dem.envi -a ./AuxDir/ -o ./orbits/ -b '18.900 20.250 -155.90 -154.900' -c 4 -z 1 -r 3 --param_ion ./ion_param.txt --num_connections_ion 3 --num_proc4topo 10
Has anyone run into a similar issue or know how to fix this?
Thank you so much!
Beta Was this translation helpful? Give feedback.
All reactions