Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase DEM buffer for Frames #128

Merged
merged 4 commits into from
Apr 18, 2023
Merged

Increase DEM buffer for Frames #128

merged 4 commits into from
Apr 18, 2023

Conversation

cmarshak
Copy link
Collaborator

@cmarshak cmarshak commented Apr 5, 2023

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:

  1. The latitude aligned frame – determines what to feed into ISCE2’s region of interest (in the xml)
  2. 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.

@cmarshak cmarshak requested review from sssangha and mgovorcin April 5, 2023 17:03
@cmarshak cmarshak merged commit 82d7233 into dev Apr 18, 2023
@cmarshak cmarshak deleted the increase-dem-buffer branch April 18, 2023 22:32
mgovorcin added a commit that referenced this pull request May 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants