In our frame workflow, I have a geojson that estimates the GUNW footprint intersecting our latitude aligned frames with bursts. This is then what we use to determine how much DEM to request (this is the only place the footprints are used). The GUNW will always beyond the latitude aligned frame extent because ISCE2 selects all bursts that intersect the specified region of interest. So again there are two geometries that we are utilizing:
The latitude aligned frame – determines what to feed into ISCE2’s region of interest (in the xml)
The estimated extent – determines how much DEM to request for geocoding
As expected, there are slight discrepancies between what I can estimate using the ESA burst map and what ISCE2 actually does when selecting bursts. My guess is that this is due to the precise position of bursts on the ground during an acquisition which slightly differs from the ESA burst map and/or geometric manipulations within the footprint estimate (such as geometric simplifications of the latitude aligned frame for easier storage/io) that underscore unexpected side-effects that are not needed for further review at this time.
That said, where this could be concerning (and this is the only place) is “are we requesting enough DEM for ISCE2 processing with our specified ROI?” and I want the answer to be an emphatic "no". Currently, I would say I think we could potentially be in a weird edge case. Specifically, the problem is that we could potentially have extra bursts included by ISCE2 and not enough DEM to geocode.
So, let's put this aside and increase the extent buffer to .4 which amounts to ~40 km (or 2 bursts) around the estimated extent and this will always ensure we have enough DEM (there will never be more than 1 burst discrepency from the estimated footprint). Note we further round to integer degrees so we are often requesting a lot, lot more. https://github.com/ACCESS-Cloud-Based-InSAR/DockerizedTopsApp/blob/dev/isce2_topsapp/localize_dem.py#L67-L70
Again, this change is to ensure that we ask for sufficient amount of DEM everywhere. This is to be extraordinarily cautious and to ensure we are not having weird edge cases.
In our frame workflow, I have a geojson that estimates the GUNW footprint intersecting our latitude aligned frames with bursts. This is then what we use to determine how much DEM to request (this is the only place the footprints are used). The GUNW will always beyond the latitude aligned frame extent because ISCE2 selects all bursts that intersect the specified region of interest. So again there are two geometries that we are utilizing:
As expected, there are slight discrepancies between what I can estimate using the ESA burst map and what ISCE2 actually does when selecting bursts. My guess is that this is due to the precise position of bursts on the ground during an acquisition which slightly differs from the ESA burst map and/or geometric manipulations within the footprint estimate (such as geometric simplifications of the latitude aligned frame for easier storage/io) that underscore unexpected side-effects that are not needed for further review at this time.
That said, where this could be concerning (and this is the only place) is “are we requesting enough DEM for ISCE2 processing with our specified ROI?” and I want the answer to be an emphatic "no". Currently, I would say I think we could potentially be in a weird edge case. Specifically, the problem is that we could potentially have extra bursts included by ISCE2 and not enough DEM to geocode.
So, let's put this aside and increase the extent buffer to .4 which amounts to ~40 km (or 2 bursts) around the estimated extent and this will always ensure we have enough DEM (there will never be more than 1 burst discrepency from the estimated footprint). Note we further round to integer degrees so we are often requesting a lot, lot more. https://github.com/ACCESS-Cloud-Based-InSAR/DockerizedTopsApp/blob/dev/isce2_topsapp/localize_dem.py#L67-L70
Again, this change is to ensure that we ask for sufficient amount of DEM everywhere. This is to be extraordinarily cautious and to ensure we are not having weird edge cases.