Quality Conrol Protocol for Level 1 Products · Quality Control Protocol for Level 1 Products ... 3 QUALITY CONTROL WORKING SCENARIOS ... [R6] CEOS SAR

Doc.: QCP Issue: 1.4 Date: 31.10.2006 Page: 1 of 50

Remote Sensing Technology Institute

Terrafirma Stage II - Quality Control Protocol -

Terrafirma

Quality Control Protocol for Level 1 Products

DLR-IMF – Remote Sensing Technology Institute

prepared:

N. Adam Date approved:

R. Capes Date released:

Ph. Bally Date




DOCUMENT CHANGE CONTROL

// ************************************************************* // Project : Terrafirma Stage II // CVS logging // Quality Control Protocol // for level 1 products // ------------------------------------------------------------- // File : $RCSfile: terrafirma_level1_quality_control__cvs.doc,v $ // ------------------------------------------------------------- // Version : $Revision: 1.4 $ // ------------------------------------------------------------- // Date : $Date: 2006/10/30 09:40:44 $ // ------------------------------------------------------------- // Author : Nico Adam // ------------------------------------------------------------- // Last modified by : $Author: nadam $ // ************************************************************* /* ************************************************************* * $Log: terrafirma_level1_quality_control__cvs.doc,v $ * Revision 1.4 2006/10/30 09:40:44 nadam * restructured entire document: * a) removed section on Theoretical Basis * b) removed section on Technical Concept and Algorithms * c) adapted introduction to reflect new document structure * d) initial support for EC Fast Track Services * * Revision 1.3 2006/10/17 17:40:27 nadam * incorporated hints of Ren Capes: * a) removed reference to PSIC4 * b) added flow chart visualisation of the QCP * c) fixed typos * * Revision 1.2 2006/07/24 12:34:27 nadam * initial setup of document structure * * Revision 1.1.1.1 2006/07/24 12:30:17 nadam * initial import into cvs * ******************************************************* */




TABLE OF CONTENTS

1 INTRODUCTION............................................................................................................................. 5 1.1 PURPOSE AND SCOPE................................................................................................................... 5 1.2 INTENDED READERSHIP ................................................................................................................. 5 1.3 GLOSSARY................................................................................................................................. 6 1.4 REFERENCES............................................................................................................................... 7 1.4.1 APPLICABLE DOCUMENTS....................................................................................................... 7 1.4.2 REFERENCE DOCUMENTS........................................................................................................ 7

1.5 DOCUMENT OVERVIEW ................................................................................................................ 9 1.6 USED TEXT STYLES .................................................................................................................... 10

2 INSAR SOFTWARE AND PRODUCTS OVERVIEW ................................................................................. 12

3 QUALITY CONTROL WORKING SCENARIOS....................................................................................... 13

4 DESCRIPTION OF THE QUALITY CONTROL PROTOCOL.......................................................................... 15 4.1 PROJECT OVERVIEW................................................................................................................... 16 4.2 DATA AVAILABILITY AND FEASIBILITY............................................................................................. 16 4.3 RELEVANT VERSION ................................................................................................................... 18 4.4 PROCESSING ............................................................................................................................ 19 4.4.1 MISSING LINES CHECK ON SLCS............................................................................................ 19 4.4.2 COREGISTRATION: SINGLE SCENE OUTLIER DETECTION ............................................................... 20 4.4.3 COREGISTRATION: SYSTEMATIC ERROR DETECTION.................................................................... 21 4.4.4 ORBIT TREND AND APS CHECK ............................................................................................. 28 4.4.5 COHERENCE IMAGES........................................................................................................... 31 4.4.6 SINGLE SCENE PHASE UNWRAPPING ....................................................................................... 31 4.4.7 SCENE CALIBRATION ........................................................................................................... 32 4.4.8 PS DETECTION ................................................................................................................... 34 4.4.9 DEM UPDATE UNWRAPPING TEST ......................................................................................... 36 4.4.10 DISPLACEMENT UNWRAPPING TEST..................................................................................... 37

4.5 VISUALISATIONS........................................................................................................................ 38 4.6 EXPECTED ACCURACY ............................................................................................................... 39 4.7 PRODUCT DELIVERY................................................................................................................... 41

5 APPENDIX ................................................................................................................................. 43 5.1 QUALITY CONTROL PROTOCOL EXAMPLE....................................................................................... 43 5.2 QUALITY CONTROL PROTOCOL TEMPLATE...................................................................................... 46







1 INTRODUCTION

The document in hand describes the Quality Control Protocol for the InSAR processing in the framework of the Terrafirma project.

1.1 PURPOSE AND SCOPE

This is the reference for the Quality Control Protocol (QCP) for the level 1 product which is generated in the course of the Terrafirma project by operational service providers (OSPs). This protocol is a customer-facing document, to satisfy customers of the quality of product they will receive, and to detail procedures to be followed and deliverables to ensure this. Following the protocol ensures that customers receive the highest quality product. The quality protocol has been developed for the generation of different kinds of interferometric RAW products. It is also the basis for the quality control of the EC Fast Track Services [R3]. Subject is to set up a common basis for the reliability of the ground motion product mainly on a technical level. Finally, the QCP provides an overarching and generic standard to track the quality of the interferometric data processing. In order to support different processing techniques and as much as possible different algorithmic approaches the test procedures are kept simple and generic. Besides, this helps to implement the test routines and to establish this protocol to be the regular working practice.

This QCP document is self-contained but is complemented by the other validation related project documents. I.e. it does not describe the theory of the various InSAR algorithms and their typical error sources and the resulting effects in the intermediate data and on the final interferometric data set. This information will be provided by the Service Validation Protocol C5 [R2] together with the technical concept and the algorithms to check the quality and to validate the processing chains. This is a consequence from the fact that the quality control and the processing chain validation will be based on similar routines and intermediate processing data.

This document provides the information on

• the intended readership of the document,

• Terrafirma’s level 1 products and the related processing chains,

• quality control working scenarios,

• a protocol to check the quality of the most important algorithms and the actual processing.

1.2 INTENDED READERSHIP

End users of the Terrafirma products (the OSP’s customers) get an insight into the processing techniques, their intermediate data and the quality related parameters. This document (complemented by [R2]) helps them to interpret the quality control protocol and its deliverables gaining understanding of the actual accuracy and reliability of the delivered final level 1 product.

Operational service providers are mainly the intended readership. Both, their software developers of the interferometric systems and their operators are addressed. Of course, the proposed quality test and validation routines need to be implemented and tested by the software developers. Furthermore, they receive information on the error sources in the different interferometric processing steps. This can be the basis for the improvement of the current algorithms and




implementations of single processing steps. The OSP’s operators need to follow this quality protocol and to report their checks.

1.3 GLOSSARY

The document uses acronyms which are often used in the InSAR, PSI, Terrafirma and GMES framework. The following table lists the abbreviations:

AOI Area Of InterestAPS atmospheric phase screenCR Corner ReflectorCVS Concurrent Versions SystemDEM Digital Elevation ModelD-InSAR Differential SAR InterferometryERS European Remote Sensing SatelliteESA European Space AgencyFFT Fast Fourier TransformGCP Ground Control PointGeoTIFF tif data with added geo-informationGMES Global Monitoring for Environment and SecurityInSAR SAR InterferometryLOS line of sightMPEG Motion Pictures Experts GroupOSP Operational Service Providerpdf probability density functionPCC Parametric Cubic ConvolutionPSI Persistent Scatterer InterferometryPTA Point Target AnalysisQC Quality ControlQCP Quality Control ProtocolSAR Synthetic Aperture RadarSCR Signal to Clutter RatioSLA Service Level AgreementSLC Single Look Complex ProductSNR Signal to Noise Ratiotiff / tif Tagged Image File Format




1.4 REFERENCES

This section lists the applicable and reference documents. The applicable documents should be available to clarify and complete this document. The reference documents can be used to obtain more detailed information.

1.4.1 APPLICABLE DOCUMENTS

[A1] Statement of Work AO/1-4704-B-TM

[A2] Geohazard Risk Management Services (Land Motion) Proposal NPA-Group No. NPA-GSE-4704/05/I-LG version 4 September 2005

1.4.2 REFERENCE DOCUMENTS

[R1] S5: Service Portfolio Specifications (Version 4) R. Capes and R. Burren (NPA) 21st June 2006

[R2] C5 Service Validation Protocol (Version 3) Bert Kampes (DLR) January 2006

[R3] EC Fast Track Services http://www.gmes.info/166.0.html

[R4] http://wgcv.ceos.org/

[R5] http://www.isprs.org/technical_commissions/wgtc_1.html#wgI/2

[R6] CEOS SAR Calibration Workshop, ESTEC, Noordwijk, Netherlands September 1993

[R7] Permanent Scatterers in SAR Interferometry Ferretti A., C. Prati, F. Rocca TGARS, Vol. 39, No. 1, pages 8-20 January 2001

[R8] Statistics of the Stokes parameters and the complex coherence parameters in one–look and multi–look speckle fields I R. Touzi, A. Lopes EEE Trans. Geosci. Remote Sensing, vol. 34, no 2, pp. 519–531 1996

[R9] ERS SAR Calibration – Derivation of the Backscattering Coefficient s0 in ESA ERS SAR Products ES-TN-RS-PM-HL09 Issue 2, Rev. 5f H. Laur, P. Bally, P. Meadows, J. Sanchez, B. Schaettler, E. Lopinto, D. Esteban 5. Nov 2004

[R10] Replica pulse power correction factor ESA Product Control Service http://earth.esa.int/pcs/ers/sar/calibration/replica_pwr/

http://wgcv.ceos.org/




[R11] Absolute Calibration of ASAR Level 1 Products Generated with PF-ASA B.Rosich and P. Meadows issue 1 revision 5 07 October 2004

[R12] Instrument, Level 1b and Absolute Calibrations M. Rocca et al. Envisat Validation Review, Esrin 9-13. Dec 2002 http://envisat.esa.int/workshops/validation_12_02/closing/RA2_conclusions-1.htm

[R13] ERS-1 SAR RADIOMETRIC CALIBRATION H. Laur, P. Meadows, J.I. Sanchez, E. Dwyer Published in the Proceedings of the CEOS SAR Calibration Workshop (ESA WPP-048) Sept. 93

[R14] ENVISAT ASAR Product Calibration and Product Quality Status B. Rosich, SAR Workshop 2004 Ulm, Germany 27-28 May 2004

http://earth.esa.int/workshops/ceos_sar_2004/papers/22_rosich.pdf




1.5 DOCUMENT OVERVIEW

This document describes the Quality Control Protocol for Terrafirma level 1 products. It is based on the theory and algorithms of InSAR which will be described in the Service Validation Protocol C5 [R2]. The reason is that the quality control and the validation of the processing chains are thematically very closely related. This relation is visualized in Fig. 1. The following sections describe the Quality Control Protocol self-governed.

The section Description of the Quality Control Protocol details how to generate the deliveries and provides examples of the generated quality control data. Furthermore, it explains how to fill out the quality protocol. At the same time, information on the interpretation of the protocol items is given. The document is completed by an example Quality Control protocol and an empty protocol template.

.

Fig. 1: Visualisation of the relation2 between the quality control protocol and the processing chain validation. Both are based on InSAR algorithms and on the signal and system theory. This document describes the Quality Control Protocol self-governed.

The document in hand covers the following aspects:

• Section 1 gives an introduction into the document. It details its purpose and scope and lists the applicable and reference documents.

• Section 2 provides a brief overview on the Terrafirma level 1 products and the related processing concepts.

• Section 3 shows different working scenarios to handle the QCP.

• Section 4 explains the items of the Quality Control Protocol. It can be considered as a catalogue of deliverables to the end-user.

• The appendix provides an example Quality Control Protocol and a template for the OSPs.




1.6 USED TEXT STYLES

Different kinds of information are formatted accordingly in order to support the reader. The following table lists the used text styles:

xv –crop 10 20 100 50 img command line statements and file names

Quality Control Document document names vec = FindGen( 3 ); source code statement or configuration text

This document .. describing information

number of processed scenes entry in the quality control protocol table

name of the city or test site comment in the quality control protocol table







2 INSAR SOFTWARE AND PRODUCTS OVERVIEW

Terrafirma establishes the European GMES ground motion hazard service. This service is based on SAR interferometric processing techniques. Depending on the degree of interpretation and modelling three levels of InSAR products are the output of the service. These are defined in the Service Portfolio Specifications [R1]. The proposed quality control procedures are related to the basic level 1 products only. But due to the hierarchic nature of the Terrafirma product tree the higher product levels (level 2 and level 3) take advantage from these. The quality control is independent of the historical or monitoring processing and applies consequently to both level 1 product types (H-1 and M-1). The Terrafirma level 1 product includes several interferometric processing techniques. The following list provides the included RAW InSAR measurements:

• conventional interferometry (InSAR) and differential interferometry (D-InSAR) • stacked InSAR • Persistent Scatterer Interferometry (PSI) • corner reflector and active transponder InSAR

The different complexity of the processing and the required software is substantial. Fig. 2 shows two examples for level 1 data.

Fig. 2: Examples for two of the several different level 1 products in the Terrafirma framework. On the left a simple differential interferogram is shown. Each colour cycle corresponds to about 2.8 cm displacement per month. The right image shows the permanent scatterer technique on the city of Berlin. The different complexity of the processing and the required software is substantial.

Nevertheless, all these processing techniques are based on interferometric SAR processing. Furthermore, the advanced processing techniques (e.g. the persistent scatterer interferometry, the small baseline subset approach (SBAS) or the stacked InSAR) which utilise long time series of phase measurements are still very similar. They just implement different types of frequency estimators in order to get the final displacement product. This fact allows to setup a common Quality Protocol and to validate the processing chains.




3 QUALITY CONTROL WORKING SCENARIOS

In the course of the Terrafirma project the Quality Control Protocol (QCP) needs to be established. I.e. acceptance needs to be attained on the OSP and customer side. Therefore, the handling of the protocol is kept simple and straight forward. The OSP needs to implement the procedures and delivers the required quality check information to the customer directly. The QCP is considered an important part of the delivered monitoring data according to the Service Portfolio Specifications (S5) [R1]. Fig. 3 visualises this simple but effective working scenario. The QCP is a service to confirm the customers receive the highest quality product.

Fig. 3: The OSP needs to implement the procedures and delivers the required quality check information to the customer directly.

At a later date, the working scenario can be adapted. This can be the case for the quality control of the EC Fast Track Services [R3]. An independent Quality Control Authority can be introduced for such a monitoring service. The mandatory regulations of the Quality Control are managed by this entity. This allows some form of part- centralised, final QA check before products go to recipients and a continuous quality service which can be updated responding to actual developments and problems. Fig. 4 presents such a working scenario. The Quality Control Authority receives the Quality Control Protocol from the OSPs and the feedback on the monitoring quality from the customers (e.g. problem reports or success stories). The Quality Control Authority has many functions e.g.:

• supervise the execution of the QC, • compile annual reports on the current developments, • update the QCP depending on the actual developments, • mediate between OSP and customer in cases of discrepancies.




Fig. 4: More complicated working scenario including an independent Quality Control Authority.




4 DESCRIPTION OF THE QUALITY CONTROL PROTOCOL

In the course of the level 1 data generation a large amount of data needs to be processed. This is the reason manual interaction is avoided in order to allow a high data throughput. However, the quality check of some processing steps and the report on it requires some operator screening. The concept of the actual quality control is to minimize this sort of interaction.

An example protocol is provided in section 5.1 and a template for the usage in the course of the Terrafirma processing is given in section 5.2. The following section explains the quality control protocol and shows examples of the data to be generated. The sequence of quality control actions follows the processing sequence. Fig. 5 presents an overview on the sections of the protocol and their relation to the actual processing. The Quality Control Protocol is designed to be generic and should be generated in table form. In case an entry or deliverable in the report is not relevant it can be marked as “not applicable“.

Fig. 5: Overview on the sections of the Quality Control Protocol and their relation to the respective data processing. The hint (4.4.10 Tab4) means that the Displacement Phase Unwrapping test is reported in the table 4 of the Quality Control Protocol and the test is described in the section 4.4.10 of this document.




4.1 PROJECT OVERVIEW

The Quality Control Protocol starts with a brief description of the project on the test site area, the customer or subject, the processing directory, the project’s start and end date and the backup information. This part provides even internal information e.g. on the backup. There are two reasons. Firstly, all the processing information is kept together for the operator in one and the same document and secondly the repeatability of the processing is visible and proven to the customer. The Project Overview part of the Quality Control Protocol is a short table which can be generated automatically:

test site name of the city or test site

project name single word for the internal project name; e.g. munich

customer / subject customer’s name, or projects subject; e.g. BRGM

analysis type e.g. D-InSAR, stacked InSAR, PSI

processing directory absolute path of the data processing

project start date date of the project’s start

project end date date of the project’s end (usually delivery’s date)

backup date of backup information on the medium (e.g. LTO, USB-disk, DVD),

date of backup the backup-ed data (e.g. SLC, InSAR, PSI) and

date of backup the backup operator (identification code is sufficient)

is continued ..

4.2 DATA AVAILABILITY AND FEASIBILITY

The data availability is briefly reported in the next section of the Quality Control Protocol. The subject of this part is to prove the suitability of the data to monitor the testsite with its displacement effects. The number of ordered scenes, the number of received scenes and the number of processed scenes are reported in order to show the feasibility of the project. In case the monitoring is not optimal these table entries provide the information on how to get additional data (e.g. by an additional data order or by a more complicated processing including difficult scenes). The time range of ordered data and the time range of available data describe the intended time range of observation and the observable time range respectively. Together with the data gap in time the observable displacement effect can be characterized. A high Doppler frequency can make single acquisitions unusable. The number of scenes, their time range and the action taken (e.g. removed, processed) are reported in the entry high Doppler frequency scenes. The time – baseline – plot completes this information. It is a simple diagram of the used (not the available) data into a graph where the x-axis describes the baseline in meters and the y-axis the time in years. The visualization of different sensors, Doppler frequencies and absolute time is optional but recommended. Fig. 6 provides an example for a time – baseline – plot. In each processing system one scene is selected to provide the reference geometry and all the other scenes are coregistered on this (super) master scene. The next table entry reports the orbit and the acquisition date of this scene.

The table entry on SLA signed reports on the successful communication of the OSP (supplier) with the customer (recipient). The last lines in this section are related to the overall feasibility of the




monitoring of the expected effect with the specified processing algorithm. The final compliance is given by the feasibility of test site for PSI (D-InSAR / stacked InSAR) entry.

Fig. 6: example for a time – baseline – plot of the processed data

number of ordered scenes number of ordered scenes e.g. 87

number of received scenes number of received scenes e.g. 87

number of processed scenes number of processed scenes e.g. 87

time range of ordered data intended observation time e.g. 1992 – 2004

time range of available data available observation time e.g. APR 1992 – AUG 2002

largest data gap in time data gap in time after removal of unusable scenes

second largest data gap in time e.g. APR 1993 – FEB 1994 (the data gap should be

third largest data gap in time significant related to the repeat cycle)




high Doppler frequency scenes

number of scenes 1 of 87

time / time range AUG 2002

action 1 scene removed

time – baseline – plot image image similar to Fig. 6

(super) master scene e.g. orbit 20460, acquired March 20, 1999

SLA signed not applicable

expected effect unknown

feasibility of test site for PSI (D-InSAR / stacked InSAR)

yes

4.3 RELEVANT VERSION

The section on the relevant versions allows to track the software versions of the main-subsystems of the processing and provides the reference document versions. The reference documents are important because they define the deliverables, the deliverable’s format (Service Portfolio Specifications) as well as the quality control deliverables and actions (Quality Control Protocol).

The documentation of the software versions is the basis for the correct and complete data reprocessing. The granularity of the software version tracking depends on the OSP’s processing system. Each program used needs to have a unique software version (e.g. CVS version or by compilation date). The OSP can bundle software into sub-systems (e.g. InSAR, PS-detection and PSI) but needs to document these software package versions separately. Software which is likely to change often (e.g. calibration software, SLC input modules) needs to be tracked separately. The entry on the non standard processing allows to comment on experiments.

document / protocol / software item version Quality Control Protocol this doc version e.g. Version 1.0 (11/01/2006)

Service Portfolio Specifications (S5) project’s version e.g. Version 4 (06/21/2006)

Processing Software Version

input reader version for ERS, ASAR, TS-X, ALOS reader

InSAR software version for InSAR package

PSI software version for PSI package

calibration version for ERS, ASAR, TS-X, ALOS calibration

non standard processing comment on experiments e.g. not applicable




4.4 PROCESSING

The following quality checks are on the single processing steps of the InSAR, D-InSAR, PSI processing, scene calibration and PS- detection.

4.4.1 MISSING LINES CHECK ON SLCS

Even though the number of missing lines is reported in the SLC product this feature of the data should be checked additionally by visual inspection. Therefore, the amplitude of each SLC needs to be generated (with only little or no multi looking) and the resulting image is displayed (e.g. using xv). Fig. 7 provides an example for the observed effect caused by missing lines. The scenes amplitude degrades along a full range line and can even fade to zero. The phase stability, the calibration and consequently the PS detection is affected by this data feature. Depending on the location of the data corruption the effect needs to be classified into: severe, risky and insignificant. The example of Fig. 7 is obviously insignificant because the testsite is not affected. The OSP can decide what to do with the data but should report it (e.g. discard scene, mask area in scene, keep scene). The next table provides an according example in the quality control protocol in the processing section:

check result / comment date signature

SLC missing lines check 0 severe / 0 risky / 87 Ok 11/08/2004 NA

severe: not applicable / deleted




Fig. 7: missing lines example from the test site Las Vegas (ERS-2: orbit 34278 frame 2871)

4.4.2 COREGISTRATION: SINGLE SCENE OUTLIER DETECTION

After the shift estimation and InSAR image resampling the coregistration is checked. This check is applicable to the stacked InSAR and the PSI processing. The slave scenes need to be transformed into the super master or master scene geometry respectively. For the check, the resampled complex slave scenes are converted into single look amplitude images and are normalized to a common mean value1. A strong point scatterer which is visible in all scenes is selected and an area of 400 x 400 samples around it is extracted from all slave images. The sequence of images (in any order) is displayed. Outlier scenes (Fig. 8) are detected by an abrupt jump in space. The amplitude’s fading of the selected scatterer can be ignored.

1 It can be advantageous to correctly calibrate the scenes in case the scenes need to be calibrated anyway.




Fig. 8: left: correctly coregistered slave; right: severe example for a single scene outlier in coregistration. The operator used invalid DEM data and caused the geometric shift estimation to fail. The outlier detection can detect much more subtle misregistrations compared to this example.

There are different options to implement this check. The most simple is to use the UNIX image viewer xview:

> xv -crop 800 3200 400 400 */AMPL_CAL.ras

The command above displays the 400 x 400 samples area around x0=1000 and y0=3000 of all files AMPL_CAL.ras which are in the subdirectories below the current working directory. The coordinate x0=1000 and y0=3000 is the expected position of the selected strong point scatterer. To step through the images the operator needs to press the space key.

Another helpful option is to generate an MPEG animation from the extracted slave image chips. The required UNIX tools (e.g. makempeg) are freely available. The order of the chips in time can be easily build into the more automatic quality check. But the animation images need to be marked with an identifier for the current scene (e.g. using IDL).

The next table entry provides an example for this quality check:

coregistration single scene outlier

Ok 11/08/2004 NA

4.4.3 COREGISTRATION: SYSTEMATIC ERROR DETECTION

Interferometry requires sub-pixel accurate coregistration. This quality check detects systematic offsets on the sub-pixel accuracy level. Outlier scenes need to be detected before this test (section above). It is assumed that misregistered scenes are not removed from the processing. Instead they are reprocessed with adapted coregistration parameters which can handle the scene’s difficulties.




The resampled SLC scenes are converted into single look amplitudes ( )yxak , which are relatively

calibrated by the constant to obtain one and the same mean valuerelativec 2.

( ) ( )yxSLCcyxa krelativek ,, ⋅= (equ. 1)

relativec is estimated for each scene separately from the histogram. A temporal mean amplitude3

image is generated by simple averaging( yxamean , ) 4

( ) ( )SLC

N

k kmean N

yxayxa

SLC∑ == 1,

, . (equ. 2)

Three areas in the range and azimuth directions according to Fig. 9 are selected (plot rg 1-3 and plot az 1-3).

Fig. 9: areas of interest (AOI) for the sub-pixel quality check of the coregistration

2 It can be advantageous to correctly calibrate the scenes instead in case the scenes need to be calibrated anyway. In this case the SLC needs to be oversampled by a factor of two due to the power operation. 3 For averaging of uncalibrated images the amplitude is used to avoid aliasing. This is in contrast to the usual multilooking which is based on power averaging. 4 In case the amount of data does not fit into the computer’s memory the areas (plot rg 1-3 and plot az 1-3) can be processes separately or the averaging can be implemented recursively.




The areas should cover the project’s area of interest. In each of these areas the point scatterers are detected by the SCR or by a similar value ( )yxSCRcrude , applying a spatial SCR estimation (CEOS-

method) based on the mean amplitude5.

( ) ( )

( )∑∑ ++

⋅⋅=

dx dyN

dx

N

dymean

dydxmeancrude

dyydxxa

NNyxayxSCR

,

,, (equ. 3)

The sums in the denominator are on the blue areas shown in Fig. 10 which are traversed by the indexes and . and are the number of samples which are integrated in each

direction.

dx dy dxN dyN

Fig. 10: areas defined by CEOS to estimate the signal power of the dominant scatterer (inside the green cross) and the clutter power (blue areas). The data are oversampled by a factor of four.

An oversampling is not necessary for this crude scatterer detection. The resulting image is similar to

Fig. 11. The coordinates of the area’s point scatters are obtained by thresholding the

or the .

( )integer, scattereryx( yxSCRcrude , ) ( )yxSCR ,

( ) ( )thresholdscatterer yxSCRyx

>= ,, integer (equ. 4)

5 This SCR-value is used for detection only. Therefore, the crude estimation is possible and allows an effective implementation and fast processing. Some misdetections do not cause problems. Of course a standard SCR estimation can be applied just as well and is more accurate.




Fig. 11: SCR of the area ‘plot rg 1’. The point scatters are detected by simple thesholding. Bright dots correspond to point scatterers which are visible in all SLCs.

Fig. 12: Green dots are the detected point scatterers in the area ‘plot rg 1’. The corresponding integer positions are the starting points for the sub-pixel accurate peak determination of the scatterer’s point

response. The peak location provides the expected (true) scatterer location and is

compared with the sub-pixel accurate peak location

( )meanscattereryx,

( )kscattereryx, of the same scatterer in each of the

single SLCs (k is the SLC index).

These integer coordinates are the starting points for the peak localisation in the mean

amplitude image which is supported by a point target analysis (PTA).

( )integerscattereryx,

( yxamean , )

( ) ( )( )integerscatterermeanlocal

meanscatterer yxayx ,maxarg, = (equ. 5)




Fig. 13: peak localisation by a routine which finds the local peak starting from integer coordinates

and providing the sub-pixel accurate peak coordinate ( ) egerscattereryx int, ( )mean

scattereryx, . The red line is the

path of the algorithm to find the local peak (steepest ascent).

The same peak localisation is performed for each single SLC amplitude image with

( yxak , )SLCNk K1=

( ) ( )( )integerscattererklocal

kscatterer yxayx ,maxarg, = . (equ. 6)

The coregistration error of the SLC with index in range k x∆ and azimuth y∆ can be assessed by

. (equ. 7) ( ) ( ) ( )kscatterermeanscatterer

k yxyxyx ,,, −=∆∆

The radial error is:

22 yxr ∆+∆=∆ . (equ. 8)




These shift errors , and x∆ y∆ r∆ are plotted with respect to the range coordinate x for the areas ‘plot rg 1-3’ and with respect to the azimuth coordinate for the areas ‘plot az 1-3’. Fig. 14 and Fig. 15 show the estimated errors for the ‘plot rg 1’ area. The green line indicates the ideal case for the error. The red line is the mean coregistration error in units of SLC pixels. The example shows a coregistration accuracy of 0.2 samples and better for this area. These plots need to be created and permanently stored on disk. The path to and the filenames of the plot images are reported in the quality protocol.

y

Fig. 14: coregistration error in range in units of one sample depending on the range position.




Fig. 15: coregistration error in azimuth in units of one sample depending on the range position.

Fig. 16: detectable coregistration error by the described method which is visible in the coherence images above.

The following table entry reports on the described check of the systematic coregistration error. It provides the location on the disk of the generated error plots for each SLC scene.




coregistration systematic error

/SANexport/tvsp02/InSAR/MUNICH/QC

plot_orbit_rg_[1-3].tif; plot_orbit_az_[1-3].tif

11/08/2004 NA

4.4.4 ORBIT TREND AND APS CHECK

After the D-InSAR processing only displacement, atmosphere, orbit and noise contribute dominantly to the interferometric phase. This check is a visual inspection of the single interferograms and can be applied in the course of the PSI and stacked InSAR processing.

Each differential interferogram is displayed on screen by the operator. Fig. 17 provides examples for the different effects which can typically be observed. The operator checks for the dominant phase contribution and reports it. The created list can be a simple text file (e.g. contributions.txt) and is not a delivery. But the number of scenes which have been assigned to the different types of contributions is part of the quality control protocol.

It can be an indicator for the not optimal master scene selection if nearly every scene is affected by the same strong effect. It does not matter if it is atmosphere, noise, an orbit phase ramp or a large missing data area. In such a case the master scene selection should be verified and changed accordingly.

A delivery item in the Quality Control protocol is an overview of all differential interferograms which are sorted according to the distance of the absolute baseline. Fig. 18 provides an example for such a quicklook image (deliverable: dinsar_quicklook.tif). The directory and the filename of the image need to be noted in the APS and orbit trend check comment field. In case the interferograms are generated without spectral shift filtering (which is the standard in the PS processing) the coherence should decrease with the absolute baseline. Exceptions are possible due to high Doppler frequencies and heavy weather conditions during the acquisitions and should be checked.

It follows an example entry in the Quality Control protocol for this APS and orbit trend check:

APS and orbit trend check /SANexport/tvsp02/InSAR/MUNICH/QC

contributions.txt dinsar_quicklook.tif

11/08/2004 NA




Fig. 17: examples for different dominant contributions to the interferometric phase




Fig. 18: D-InSAR quicklooks sorted with respect to absolute effective baseline. The coherence should decrease from top left to the lower right. Exceptions are possible due to high Doppler frequencies and heavy weather conditions during the acquisitions and should be checked. (deliverable: dinsar_quicklook.tif)




4.4.5 COHERENCE IMAGES

For stacked InSAR processing the coherence map has a meaning and is related to the interferometric phase accuracy. For the point scatterer based techniques this entry is not applicable because the phase stability needs to be estimated by the SCR. The coherence images are a delivery for each interferogram (coherence_orbit.tif). The estimation window size needs to be reported and should provide enough samples in order to reduce the underestimation and the variance of the coherence. Details are reported in [R8]. An example for the coherence image section in the Quality Control protocol follows:

coherence images estimation window (az x rg): 20 x 4 samples


coherence_orbit.tif

11/08/2004 NA

4.4.6 SINGLE SCENE PHASE UNWRAPPING

Depending on the applied phase unwrapping method an error is propagated differently over the image. Branch Cut Methods can have large areas affected whereas Least Squares Methods may cause local spikes and a global phase bias (missing fringes). The phase inconsistencies in the interferograms can be reported by the residues. Therefore the residues are calculated and plotted into the relative phase image. The charge of the residue is indicated by coloured dots (e.g. green and red). This residue visualisation does not show the error of the phase unwrapping but the difficulty of the actual interferogram. In case a Branch Cut Method is used the branch cuts need to be plotted into the residue image. Fig. 19 provides an example for the scene phase unwrapping delivery if applicable.

The entry for the scene phase unwrapping can have the following form for the PSI technique:

scene phase unwrapping not applicable 11/08/2004 NA




Fig. 19: interferogram with the residues; red: positive residues; green: negative residues; blue: single branch cut line crossing this line adds π21× ; purple: two branch cut lines (crossing this line adds

π22× ). In this example the branch cuts are determined by the MCF algorithm.

4.4.7 SCENE CALIBRATION

Two different calibration strategies can be applied. The first option is the absolute calibration using the calibration procedure and constants from the according mission centre (e.g. [R9], [R10] and [R11]). The second is the relative calibration related to the master scene. The quality control protocol copes with both methods. The applied method is reported in the scene calibration line of the processing info table. Two deliverables allow to check the calibration quality. The histograms of all the calibrated intensity images are plotted (cal_histograms.tif). An example is shown in Fig. 20. The spread of the histogram ensemble regarding the Median (green in Fig. 20) should be small and is reported for two regions ( peaksσ and curveσ red in Fig. 20). The requirement for Envisat is e.g.

and a stability of over three years [R12]. From [R14] the expected actual variation of the histogram shifts can be obtained for IMS products of the sensor ENVISAT/ASAR. A standard deviation of 0.4 dB can be expected for the sensor ERS-1 [R13].

dB5.0± dB1.0±




Fig. 20: histogram plot (cal_histograms.tif) of calibrated intensities. The red lines indicate the two regions for the estimation of the deviation of the single calibrations from the median which is highlighted in green.

The second deliverable for the calibration check is the mean power image (cal_mean.tif) in single look resolution. It is a radiometrically improved radar image. A single miscalibrated scene with a high power can degrade the overall mean image masking the high quality mean. The deliverable allows the operator to confirm that the calibrated mean is not degraded by such an effect.

In the scene calibration section of the Quality Control protocol the location of the two deliverables and the calibration algorithm are reported:

scene calibration firstly absolute and adjusted relative;


cal_histograms.tif cal_mean.tif

11/08/2004 NA




Fig. 21: left: one look high quality calibrated mean power (cropped of the deliverable cal_mean.tif); right: single calibrated scene (same croped area);

4.4.8 PS DETECTION

The PS detection should be based on the SCR. This is the reason the Quality Protocol assumes an estimated SCR is available regardless of the used method ([R6], [R7]). Consequently, an estimated phase stability of the detected scatterers can be reported. The SCR is transformed into the expected phase standard deviation by the approximation

SCR⋅

=2

1ϕσ . (equ. 9)

The histogram showing the frequency of the detected PS’s expected phase error ϕσ is a deliverable.

Fig. 22 shows an example (psc_histogram.tif).




Fig. 22: histogram of the expected phase error of the detected PS candidates (psc_histogram.tif)

The SCR threshold or dispersion index which has been applied in order to get the PS candidates is the first entry in the table. The number of detected scatterers per square kilometre characterises the testsite and is reported in the entry candidates density. The item final density is the PS density after the removal of misdetected stable scatterers. The spatial distribution of the PSs is reported by two plots (psc_image.tif and (ps_image.tif) of the PS locations over the calibrated mean intensity (cal_mean.tif). The first plot shows the PS candidates whereas the second presents the used PSs only. The expected phase stability can be colour coded. Fig. 23 provides an example for the candidates plot deliverable.

The Quality Control protocol entry provides the following information:

PS detection SCR threshold: 1.5 (or dispersion index)

candidates density: 287 [scat/km2]

final density: 250 [PS/km2]


psc_histogram.tif ps_histogram.tif psc_image.tif ps_image.tif cal_mean.tif

11/08/2004 NA




Fig. 23: example (small area) for the PS candidates plot (psc_image.tif).

4.4.9 DEM UPDATE UNWRAPPING TEST

The measurements of the DEM update are relative estimates between two PSs only. These estimates are performed in a network and consequently the absolute DEM update can be obtained by integration. This network is irregularly sampled in space and should be redundant in order to minimise the error propagation. But similar to conventional InSAR phase unwrapping the smallest meshes need to be free of residuals. Integration errors would be the consequence and a global under estimation can result in case of noticeable residues. In case of this irregular sampling the smallest meshes are triangle loops. Due to the redundant network these smallest triangles need to be determined e.g. by a simple triangulation (the different resolution in range and azimuth should be considered). But the triangle arcs should still represent available relative estimates. In the obtained triangle loops the residuals are calculated by directed adding of the three single relative estimates. These residuals should be small and can be plotted similar to Fig. 24 (colour scale -1.5 m to +1.5 m). The residues plot image is considered a deliverable even in case the DEM update estimates are not integrated in the course of the processing. It provides useful information on the relative estimation outlier.

The entry of the DEM Update Unwrapping provides the location of the residues image:

DEM Update Unwrapping /SANexport/tvsp02/InSAR/MUNICH/QC

topo_residuals.tif

11/08/2004 NA




Fig. 24: DEM update estimation residual image (colour scale -1.5 m to +1.5 m). This is the deliverable topo_residuals.tif.

4.4.10 DISPLACEMENT UNWRAPPING TEST

Similar to the relative DEM update measurements the displacement is estimated relatively only in order to cope with the atmospheric effect during the radar observation. Only the overall integration of the estimates results in an absolute displacement map. The triangular meshes obtained in the “DEM Update Unwrapping Test” are used for the residual image of the displacement estimates. Fig. 25 provides an example for such an image (the colour scale is from -0.5 mm/year to +0.5 mm/year).

The Displacement Unwrapping entry of the Quality Control protocol can have the following form:

Displacement Unwrapping /SANexport/tvsp02/InSAR/MUNICH/QC

disp_residuals.tif

11/08/2004 NA




Fig. 25: displacement estimation residual image (colour scale -0.5 mm/year to +0.5 mm/year). This is the deliverable disp_residuals.tif. Fig. 25: displacement estimation residual image (colour scale -0.5 mm/year to +0.5 mm/year). This is the deliverable disp_residuals.tif.

4.5 VISUALISATIONS 4.5 VISUALISATIONS

The visualisation of the estimated parameters e.g. the “raster of interpolated average annual displacement rates“ is a deliverable according to [R1]. For the visualisation the estimates can be filtered regarding outliers on the expense of spatial resolution and density of measurements. The visualisation filtering and its parameters should be reported in the section Visualisation of the Quality Control Protocol:

The visualisation of the estimated parameters e.g. the “raster of interpolated average annual displacement rates“ is a deliverable according to [R1]. For the visualisation the estimates can be filtered regarding outliers on the expense of spatial resolution and density of measurements. The visualisation filtering and its parameters should be reported in the section Visualisation of the Quality Control Protocol:

check check result / comment result / comment date date signature

signature




displacement map triangulation interpolation no extra filter

/SANexport/tvsp02/InSAR/MUNICH/DELIVERABLES

displ_map_1995.tif .. displ_map_2001.tif

11/08/2004 NA




Fig. 26: two different displacement visualisations of one and the same estimation. left: no visualisation filter results in high PS density but some outliers. right: visualization of the best estimate in an area of 100 m x 100 m only which reduces the PS density but removes the noise.

4.6 EXPECTED ACCURACY

This section adds an overview on the overall quality of the estimated displacement, height and geolocation. The table entry coherence map provides the location of the coherence image. This is an overlay of the full resolution radiometrically improved intensity and the coherence of each single estimation. The coherence is defined as:

( )∑=

−⋅⋅=N

i

j iifgrmie

N 1

mod1 ϕϕϕγ . (equ. 10)

N is the number of interferograms, and are the phase of the i-th interferogram and the

respective modelled phase. The modelled phase is the sum of the respective estimated DEM-update phase , the displacement phase and APS phase :

ifgrm

iϕmod

iϕ

topoiϕ

defoiϕ

atmoiϕ




. (equ. 11) atmoi

topoi

defoii ϕϕϕϕ ++=mod

Fig. 27 provides an example for the coherence map deliverable.

The next entry provides the geolocation accuracy which can be obtained from the available Ground Control Points (GCP). The accuracy and number of the GCPs and the ability to connect this point to the used permanent scatterers as well as the accuracy of the absolute height estimation influence this parameter. The table line correction due to GCP(s) provides the applied shift of the scene to match the reference points.

The absolute height accuracy provides the expected error on the total height measurement. It depends similarly to the previous table entry on the accuracy and number of the GCPs and the ability to connect this point to the used permanent scatterers.

The ambiguities entry informs on the ambiguities which can remain in the data in the case of a simple D-InSAR processing. E.g. the displacement ambiguity of 2.8 cm per fringe can be reported or the ambiguity between a vertical and horizontal displacement if it is relevant.

The displ. estimation accuracy provides the expected error on the final displacement estimates. It can be assumed that the applied model describes the data. Therefore it can be derived from the temporal coherence.

The following Quality Control Protocol segment provides an example for the Expected Accuracy section:


coherence map /SANexport/tvsp02/InSAR/MUNICH/QC

coh_map.tif

11/08/2004 NA

geolocation accuracy 25 m 11/08/2004 NA

correction due to GCP(s) azimuth: -13.05 m range: 60.91 m

11/08/2004 NA

absolute height accuracy 10 m 11/08/2004 NA

ambiguities not applicable 11/08/2004 NA

displ. estimation accuracy +/-1 mm/year assuming linear displacement 11/08/2004 NA




Fig. 27: coherence map overlaid on the radiometrically improved intensity. The scaling of the coherence colour table can be adjusted according to the actual test site. (deliverable: coh_map.tif)

4.7 PRODUCT DELIVERY

Seven deliveries are defined for the level 1 monitoring product according to the Service Portfolio Specifications (S5) [R1]. The completeness of delivery is confirmed in the first table entry reporting each single delivered item. In case more data are delivered these have to be listed as well. The table entry delivery date provides the exact date the data are send away to the customer. Together with the next entry delivery due date the pressure of time for the processing can be concluded. The two table entries delivery address and delivery service show that the mailing has been well organised and the customer is secure from loss of the data.





completeness of delivery 1. Database of PSI average annual displ. rates 2. Database of PSI time-series 3. Reference point table 4. Processing report (metadata) 5. Background reference image 6. Img of interpolated average annual displ. rates 7. Quality control sign-off

12/08/2004 NA

delivery date not applicable (could be 14/08/2004) 12/08/2004 NA

delivery due date not applicable (could be T0 + 2 months) 12/08/2004 NA

delivery address not applicable (could be post or ftp address) 12/08/2004 NA

delivery service not applicable (could be DHL or ftp)




5 APPENDIX

5.1 QUALITY CONTROL PROTOCOL EXAMPLE

1 Project Overview test site city of Munich

project name munich

customer / subject internal validation processing

processing directory /SANexport/tvsp02/InSAR/MUNICH

project start date 11/01/2004

project end date 01/03/2005

backup 11/10/2004 mirror disk: /home/tvsp06/adam/TVSP02 (all data) by NA

12/24/2004 tape LTO: (SLC, InSAR, PSI) by NA

01/01/2005 DVD: (PSI core data only) by NA

20/01/2005 USB disk: (all) by NA

2 Data Availability number of ordered scenes 87

number of received scenes 87

number of processed scenes 87

time range of ordered data 1992 – 2004

time range of available data APR 1992 – AUG 2002

largest data gap in time 08-NOV-1993 - 05-APR-1995 (ca. 1.5 years) // after removal of unusable scenes

second large data gap in time 04-JAN-2001 - 22-AUG-2002 (over 1.5 years)

third large data gap in time


number of scenes 1 of 87

time / time range AUG 2002

action 1 scene removed

time – baseline – plot image /SANexport/tvsp02/InSAR/MUNICH/QC/baselineplot.jpg




(super) master scene orbit 20460, acquired March 20, 1999

SLA signed not applicable

expected effect unknown


yes

3 Relevant Versions

document / protocol / software item version Quality Control Protocol Version 1.0 (11/01/2006)

Service Portfolio Specifications (S5) Version 4 (06/21/2006)


input reader ERS: 1.23 ASAR: - TS-X: - ALOS: - (CVS)

InSAR 1.8 (CVS)

PSI 2.12 (CVS)

calibration ERS: 1.1 ASAR: TS-X: ALOS:

non standard processing not applicable

4 Processing check result / comment date signa

ture SLC missing lines check 0 severe / 0 risky / 87 Ok 11/08/2004 NA

severe: not applicable / deleted


None 11/08/2004 NA



plot_orbit_rg_[1-3].tif; plot_orbit_az_[1-3].tif error smaller 0.2 samples

11/08/2004 NA

APS and orbit trend check /SANexport/tvsp02/InSAR/MUNICH/QC

contributions.txt dinsar_quicklook.tif

11/08/2004 NA

coherence images estimation window (az x rg): 20 x 4 samples


coherence_orbit.tif

11/08/2004 NA




scene phase unwrapping not applicable 11/08/2004 NA

scene calibration firstly absolute and adjusted relative;


cal_histograms.tif cal_mean.tif

11/08/2004 NA

PS detection SCR threshold: 1.5 (or dispersion index)

candidates density: 287 [scat/km2]

final density: 250 [PS/km2]


psc_histogram.tif ps_histogram.tif psc_image.tif ps_image.tif cal_mean.tif

11/08/2004 NA

DEM Update Unwrapping /SANexport/tvsp02/InSAR/MUNICH/QC

topo_residuals.tif

11/08/2004 NA

Displacement Unwrapping /SANexport/tvsp02/InSAR/MUNICH/QC

disp_residuals.tif

11/08/2004 NA

APS Check 11/08/2004 NA

5 Visualisation check result / comment date signa

ture displacement map triangulation interpolation no extra filter

/SANexport/tvsp02/InSAR/MUNICH/DELIVERABLES

displ_map_1995.tif .. displ_map_2001.tif

11/08/2004 NA

needs to be continued for other visualisations

6 Expected Accuracy check result / comment date signa

ture coherence map /SANexport/tvsp02/InSAR/MUNICH/QC

coh_map.tif

11/08/2004 NA

geolocation accuracy 25 m 11/08/2004 NA




correction due to GCP(s) azimuth: -13.05 m range: 60.91 m

11/08/2004 NA

absolute height accuracy 10 m 11/08/2004 NA

ambiguities not applicable 11/08/2004 NA

displ. estimation accuracy +/-1 mm/year assuming linear displacement 11/08/2004 NA

7 Product Delivery check result / comment date signa

ture completeness of delivery 1. Database of PSI average annual displ. rates

2. Database of PSI time-series 3. Reference point table 4. Processing report (metadata) 5. Background reference image 6. Img of interpolated average annual displ. rates 7. Quality control sign-off

12/08/2004 NA

delivery date not applicable (could be 14/08/2004) 12/08/2004 NA

delivery due date not applicable (could be T0 + 2 months) 12/08/2004 NA

delivery address not applicable (could be post or ftp address) 12/08/2004 NA

delivery service not applicable (could be DHL or ftp) 12/08/2004 NA

5.2 QUALITY CONTROL PROTOCOL TEMPLATE

The template starts on the next page in order to provide it without interfering document’s text




Quality Control Protocol

1 Project Overview test site

project name

customer / subject

processing directory

project start date

project end date

backup




2 Data Availability number of ordered scenes

number of received scenes

number of processed scenes

time range of ordered data

time range of available data

largest data gap in time

second large data gap in time

third large data gap in time


number of scenes

time / time range

action

time – baseline – plot image

(super) master scene

SLA signed

expected effect


3 Relevant Versions

document / protocol / software item version Quality Control Protocol

Service Portfolio Specifications (S5)


input reader

InSAR

PSI

calibration

non standard processing




4 Processing check result / comment date signa

ture SLC missing lines check



APS and orbit trend check

coherence images

scene phase unwrapping

scene calibration

PS detection

DEM Update Unwrapping

Displacement Unwrapping

APS Check




5 Visualisation check result / comment date signa

ture displacement map

needs to be continued for other visualisations

6 Expected Accuracy check result / comment date signa

ture coherence map

geolocation accuracy

correction due to GCP(s)

absolute height accuracy

ambiguities

displ. estimation accuracy

7 Product Delivery check result / comment date signa

ture completeness of delivery

delivery date

delivery due date

delivery address

delivery service

-- End of document --

Documents

Quality Conrol Protocol for Level 1 Products · Quality Control Protocol for Level 1 Products ... 3 QUALITY CONTROL WORKING SCENARIOS ... [R6] CEOS SAR