Close to Automated INSAR Imaging with Weather Correction

High-Level Project Summary

During this challenge, we achieved INSAR generation using Snappy with phase correction in consideration of weather. Starting from L1 data of Sentinel-1, we produce an interferogram using phase data of any 2 dates from the same location. This allows to monitor longer term changes than the pre-treated INSAR data, such as the glaciers melting. The weather model used to correct the phase of the interferogram is linked to a web-API to get data corresponding do the date & time of the acquisition. By scanning through the altitude map, we calculate the corresponding phase shift pixel by pixel and sum them to the final interferogram. The data is then saved to a "BEAM-DIMAP" file.

Detailed Project Description

We decided not to start from the given interferometry files, but from Single Look Complex (L1) data. These datas are selected because they provide the amplitude and phase at different times. At first, none of us had any idea how or which program to use to treat the data. We use the SNAP tool to treat the data in a pipeline which is described in the notebook. This pipeline is heavily inspired by Snappy. This tool was used to generate interferogram without atmosphere correction.


We then focused on understanding a climate model found by one of our members and getting weather data from a target location and time. To account for the different layers of the atmosphere, we needed an integration between the imaged point and the satellite location. The atmosphere model generates the index of refraction at different altitude which can be integrated to generate the optical path. The optical path difference is transcribed into phase difference for every pixel.

We also hase a phase difference map generated with the TRAIN package.


The two parts were combined together once we had an idea of how to generate an interferogram and evaluate the phase difference into a final interferogram using both atmosphere model.

Space Agency Data

During this project, we used different sentinel-1 datasets. We started to first look at INSAR data producend by Sentinel-1, which gave us the objective to reproduce (and automate) the image generation process. Most of our members have a background in physics, but none of us had worked with satellite data. Since we lacked the understanding of how the image are generated, we decided to tackle that challenge. So we switched to Sentinel-1 L1 data, accessed via the same platform.


We still wanted to tackle the main challenge, and needed to historic weather data. Data measured by the ERA5 satellite since 1951 is available via an API, so we built our weather model around (mostly chose) the data we could access from the satellite.

Hackathon Journey

Our main goal was to fulfill the challenge, but also to learn all we could about the imaging process, from the initial SAR to the interferometry aspect of image interpretation. Since most of the members in our team had a background in physics, we wanted to understand the what, the why and the how of the data.


We decided to use Single Look Complex (L1) data from Sentinel-1 in which contains seperated phase and amplitude. The phase correction could be applied to any acquisition independently.


We identified two open-source libraries (ISCE2 and SNAP) that could be helpful to crunch the data and split the team to find the one that could work . We reached a roadblock with ISCE2 because the Sentinel-1 data treatment toolbox for ISCE is not publicly available (licensed by Stanford). We then continued using snap, and kinda forced our way with Snappy since the goal is to deliver a notebook. Using the sparse and dispersed (but available!) documentation, we built a functional data treatment pipeline.


Meanwhile, we worked on an atmospheric model. In order to not repeat the same mistake with relying completely on packages, we identified one package (Tool for reducing atmosphere INSAR noise : TRAIN) and a parametric model by Doin. The parametric atmospheric model evaluates the refractive index which is used to evaluate the optical path of the signal by integrating from ground level to the satellite. Another set of data was necessary to generate the model result : more data crunching! We used the value from the ERA5 (1959 to present) available from the Copernicus Climate Change Service which produces meteorological data like humidity and temperature at different pressure level.

We also got the TRAIN package to work last minute with a linear tropospheric correction.


Once both pieces were independantly ready, we proceeded to try and fuse everything into a single code sheet. This final step was hectic; we hadn't thoroughly planned our time, the data types did not match and were kinda stuck, so we cut the initially planned video presentation to slides.


Through all this, we read tons of documentation. Weather models, manuals, articles, to try and further our understanding of the subject. We're certainly walking away from this project with a better understand of satellite imaging and quite happy of the point we reached during a single weekend.

References

  1. SNAP - ESA Sentinel Application Platform v2.0.2, http://step.esa.int
  2. 'Contains modified Copernicus Service information [2022] ' for Copernicus Service Information, https://search.asf.alaska.edu
  3. InSAR_Snappy, crisjosil, Accessed 2th October 2022.
  4. Muñoz Sabater, J., (2021) was downloaded from the Copernicus Climate Change Service (C3S) Climate Data Store, https://cds.climate.copernicus.eu
  5. Doin, M-P., et al. "Corrections of stratified tropospheric delays in SAR interferometry: Validation with global atmospheric models." Journal of Applied Geophysics 69.1 (2009): 35-50.
  6. Bekaert, D. P. S., et al. "Statistical comparison of InSAR tropospheric correction techniques." Remote Sensing of Environment 170 (2015): 40-47.
  7. TRAIN: Toolbox for Reducing Atmospheric InSar Noise , dbekaert, Accessed 2th October 2022.

Tags

#INSAR, #SAR, #Sentinel, #ERA5, #SNAP, #Software, #python, #Interferometry, #DataCrunching