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
-
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