search

ACCESS-Cloud-Based-InSAR / dem-stitcher

Download and merge DEM tiles
Apache License 2.0
41 stars 15 forks source link

Enforce square dimensions for DEM #12

Closed sssangha closed 2 years ago

sssangha commented 2 years ago

This PR enforces square dimensions for DEM pixels, which before were distorted along polar regions.

This had downstream consequences as Aleutian Island case study GUNW product layers have inconsistent dimensions vis-à-vis metadata layer. Namely, the former do not possess square pixels, with the latitudinal dimension being multiple times larger:

Data axis to CRS axis mapping: 2,1
Origin = (-169.004166666666663,54.004166666666670)
Pixel Size = (0.000416666666667,-0.000277777777778)

This behavior is not replicated over study areas further to the south (e.g. CA case study), which suggests this is related to/inherited from the DEM itself, which is distorted along the latitudinal axis towards the poles akin to the output product layer pixel dimensions for the Aleutian Island GUNWs.

I tracked down in the DEM stitcher where we may enforce square pixel dimensions to the DEM, which will impose square pixel dimensions downstream for GUNW product layers:

Data axis to CRS axis mapping: 2,1
Origin = (-169.004166666666663,54.004166666666670)
Pixel Size = (0.000277777777778,-0.000277777777778)

I had tested this bug-fix by using the DEM staging notebook (https://github.com/ACCESS-Cloud-Based-InSAR/dem-stitcher/blob/dev/notebooks/Staging_a_DEM_for_ISCE2.ipynb)

dbekaert commented 2 years ago

@sssangha can you add some images. Interested to see the level of distortion. The InSAR processing in ISCE2 is done also in WGS84. ISCE3 will have that fixed down the line to handle polar-based processing.

sssangha commented 2 years ago

Can confirm now in my latest patch that the updated DEM with square pixels overlaps with the original DEM: Screen Shot 2022-02-15 at 11 44 45 PM

@jhkennedy, please let me know if there is anything I should clarify. If not, please review and advise if ready for a merge.

jhkennedy commented 2 years ago

This looks fine to me as long as you're getting out a DEM that looks good.

sssangha commented 2 years ago

Note @jhkennedy @dbekaert, here is some confirmation this PR works as intended in enforcing square pixels for the products generated downstream.

Namely, here is the pixel size of the dataset over a high latitude target before integrating these changes: Pixel Size = (0.001250000000000,-0.000833333000000)

And here is the pixel size after: Pixel Size = (0.000833333000000,-0.000833333000000)

@gracebato I also did an end-to-end ARIA-tools run as a sanity check, and it was able to pass through the prep_aria.py ingest stage without a hitch note