Summary of InSARProc 2008 July 28-31, 2008 Stanford University

1. Summary ofInSARProc 2008July 28-31, 2008Stanford University Sponsored by NASA Howard Zebker, Eric Fielding, Paul Lundgren

2. Workshop Purpose and Approach • Assess capabilities of the international geophysical community to produce InSAR data products • Define needs and capabilities of next-generation processing systems • Set standards and structure for new InSAR processor development • Organized by a Steering Committee, who invited to attend, radar processing experts from around the world • Working meeting, much time set aside for technical comparison of products from a variety of processing packages available to the science community • Looking for better understanding of the strengths and weaknesses of current processing approaches and specific recommendations for future software development

3. Working sessions – code intercomparison • All participants ported codes to Stanford CEES computer center to facilitate comparison • Data sets analyzed: • data set 1 – ERS – Bay Area • data set 2 – Envisat • data set 3 – ALOS T473-Sichuan Earthquake (multi-frame, multi-swath) • data set 4 – ALOS full polarimetry, Hawaii • data set 5 – ALOS Amazon data pair • Products generated • radar coordinate products: amplitude, phase, correlation, phase with terrain correction, unwrapped phase • geocoded products: amplitude, phase, deformation, correlation • other products: e.g. masked phase, phase gradient, others as desired

4. Packages and methods assessed • DORIS – Andy Hooper and Rob Mellors • Stanford InSAR – Howard Zebker • SIOSAR – David Sandwell • GMTSAR – Rob Mellors • ROI_PAC – Eric Fielding and Paul Rosen • Stacking interferograms – Yuri Fialko • Persistent scattering – Piyush Agram • SBAS – Riccardo Lanari • Atmospheric effects – Matt Pritchard and Mark Simons • ScanSAR – Sean Buckley • Polarimetry – Howard Zebker

5. Sample ROI_PAC slide

6. Sample DORIS slide

7. Primary Recommendations • Precise and well-characterized products • Flexible and extensible modular code to encourage modification and improvement by the user community (open-source) • Comprehensive set of user documentation.

8. Secondary recommendations • The software should be portable, thus with a small and light footprint • The new codes should be open source in the sense that they should be available to anyone for inspection, use, modification, and redistribution • The code should be thoroughly tested, debugged, pass benchmarks, and verified • Results should be readily reproducible and repeatable • The package should follow defined, standardized products with clear coordinates

9. Ongoing actions • Self-organize this InSARProc group for the short-term • Document what has happened at this workshop. Report delivered to NASA. • Discuss the possibility of a long-term life to this InSAR workshop, with the most likely choice be a second meeting a year from now. An interim meeting to assess changes to the existing ROI_PAC software may be warranted in six months time. • There is a possibility of working with UNAVCO to better coordinate with WInSAR. • For future meetings, there is a great benefit from collaboration between American and European developers. This was very helpful in this workshop. • Recommend NASA/NSF (and USGS, etc.) commitment to developing community code, in particular investigate the possibility of funding by NASA and/or NSF for processor development for InSAR and international satellites with specific attributes in the development, as discussed above. Also, recommend that ESA/ESF and European national space agencies such as ASI explore involvement in these activities. • Investigate the possibility of long-term computing support through CEES to facilitate ready comparison of new algorithms and products, or other formal benchmarking subgroup and facilities.