quality conrol protocol for level 1 products · 3 quality control working scenarios ... [r6] ceos...

Doc.: QCP Issue: 1.6 Date: 16.12.2008 Page: 1 of 61

Remote Sensing Technology Institute

Terrafirma Stage II - Quality Control Protocol -

prepared:

N. Adam Date A. Parizzi

approved:

R. Capes Date

released:

Ph. Bally Date

Terrafirma

Quality Control Protocol for Level 1 Products

DLR-IMF – Remote Sensing Technology Institute




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.6 $

// -------------------------------------------------------------

// Date : $Date: 2008/12/15 11:14:45 $

// -------------------------------------------------------------

// Author : Nico Adam

// -------------------------------------------------------------

// Last modified by : $Author: nadam $

// *************************************************************

/* *************************************************************

* $Log: terrafirma_level1_quality_control__cvs.doc,v $

* Revision 1.6 2008/12/16 18:14:20 pari_al

* changes to Chapter 4

* a) fixed responsibility of Coreg Check to the OSP

* b) Made optional Calibration and PS Detection

* c) Changed figure 5 to introduce the optional

* d) fixed responsibility of the UW controls to the OSP

* Revision 1.5 2008/07/18 11:14:45 nadam

* added section on feedback of the OSPs

*

* 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 A.............................................................................................................................

5.1 FEEDBACK BY TRE ................................................................................................................... 43 5.2 FEEDBACK BY ALTAMIRA .......................................................................................................... 43 5.3 FEEDBACK BY GAMMA RS ........................................................................................................ 49 5.4 FEEDBACK BY NPA .................................................................................................................. 51

6 APPENDIX B ............................................................................................................................ 54

6.1 QUALITY CONTROL PROTOCOL EXAMPLE ...................................................................................... 54 6.2 QUALITY CONTROL PROTOCOL TEMPLATE ..................................................................................... 57




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 . 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 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 ) 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:

AIO area of interest

APS atmospheric phase screen

CR corner reflector

CVS Concurrent Versions System

DEM digital elevation model

D-InSAR Differential SAR Interferometry

ERS European Remote Sensing Satellite

ESA European Space Agency

FFT Fast Fourier Transform

GCP ground control point

Geo TIFF tif data with added geo-information

GMES Global Monitoring for Environment and Security

InSAR SAR Interferometry

LOS line of sight

MPEG Motion Pictures Experts Group

OSP Operational Service Provider

pdf probability density function

PCC Parametric Cubic Convolution

PSI Persistent Scatterer Interferometry

PTA Point Target Analysis

QC Quality Control

QCP Quality control Protocol

SAR Synthetic Aperture Radar

SCR Signal To Clutter Ratio

SLA Service Level Agreement

SLC Single Look Complex Product

SNR signal To Noise Ratio

tiff / tif Taged 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

http://wgcv.ceos.org/

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




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

[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 . 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. . 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. : 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 gives an introduction into the document. It details its purpose and scope and lists the applicable and reference documents.

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

Section shows different working scenarios to handle the QCP.

Section 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 . 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. shows two examples for level 1 data.

Fig. : 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) . Fig. visualises this simple but effective working scenario. The QCP is a service to confirm the customers receive the highest quality product.

Fig. : 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 . 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. 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. : 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 and a template for the usage in the course of the Terrafirma processing is given in section . 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. 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. The implementations of the QCP can vary and it is left to the experience and responsibility of the OSPs. In case of an entry or deliverable in the report is not relevant it can be marked as ‚not applicable‚. Anyhow during the following chapter some examples of implementation are presented.

Fig. : 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 test site 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. 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. : 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.

(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. 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. is obviously insignificant because the test-site 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 signa

ture

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

severe: not applicable / deleted




Fig. : 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, different protocols can be implemented. In the QCP the type of method used, the expected or measured precision and the units of the measure, have to be provided. The expected precision mentioned is the expected precision of the coregistration, consequently can be considered the threshold above of which a scene is considered not correctly coregistered to the master / super master scene. The requirements of the coregistration are set by the OSP.




Fig. : 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.

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

coregistration check Type : PS positions

Precision:

Unit : pixels

11/08/2004 NA

coregistration single scene outlier

Ok 11/08/2004 NA

4.4.3 COREGISTRATION QUALITY CONTROL: AN EXAMPLE OF SYSTEMATIC ERROR MEASUREMENT

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. Here we have an example of the how to measure the systematic coregistration errors.

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

calibrated by the constant relativec to obtain one and the same mean value1.

1 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.




yxSLCcyxa krelativek ,, (equ. )

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

image yxamean , is generated by simple averaging3

SLC

N

k k

meanN

yxayxa

SLC

1,

, . (equ. )

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

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

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 amplitude4.

2 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.

3 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.

4 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.




dx dyN

dx

N

dy

mean

dydxmean

crude

dyydxxa

NNyxayxSCR

,

,, (equ. )

The sums in the denominator are on the blue areas shown in Fig. which are traversed by the

indexes dx and dy . dxN and dyN are the number of samples which are integrated in each

direction.

Fig. : 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. . The coordinates integer, scattereryx of the area’s point scatters are obtained by thresholding the

yxSCRcrude , or the yxSCR , .

thresholdscatterer yxSCRyx

,,

integer (equ. )




Fig. : 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. : 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 mean

scattereryx, and is

compared with the sub-pixel accurate peak location kscattereryx, of the same scatterer in each of the

single SLCs (k is the SLC index).

These integer coordinates integer

scattereryx, are the starting points for the peak localisation in the mean

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

integer

scatterermeanlocal

mean

scatterer yxayx ,maxarg, (equ. )




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

eger

scattereryxint

, and providing the sub-pixel accurate peak coordinate 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 yxak , with

SLCNk 1

integer

scattererklocal

k

scatterer yxayx ,maxarg, . (equ. )

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

kscatterer

mean

scatterer

kyxyxyx ,,, . (equ. )

The radial error is:

22 yxr . (equ. )




These shift errors x , y and r are plotted with respect to the range coordinate x for the areas

‘plot rg 1-3’ and with respect to the azimuth coordinate y for the areas ‘plot az 1-3’. Fig. and Fig.

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.

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

coregistration systematic error

/SANexport/tvsp02/InSAR/MUNICH/QC

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

11/08/2004 NA




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

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

.




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. 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. 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. : examples for different dominant contributions to the interferometric phase




Fig. : 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 . 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. 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. : 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

The importance of the calibration of the scenes depends on the method that is later used to detect the PS candidates. For this reason the OSPs will decide whether it is relevant or not to provide this information. An example is proposed below.

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. , and ). 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. . The spread of the histogram ensemble regarding the Median (green in Fig. ) should be small and is reported for two regions

( peaks and curve red in Fig. ). The requirement for Envisat is e.g. dB5.0 and a stability of

dB1.0 over three years . From 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 .




Fig. : 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. : 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 OSPs can also provide optionally information about the selected PS candidates in order to understand how many points have been processed and which technique has been used to select them. Every selection method has to be reported together with its own threshold. The technique/s and the threshold/s which has/have been applied should be 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. provides an example for the candidates plot deliverable.




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

The Quality Control protocol entry provides the following information:

PS detection Method 1

threshold: 1.5 (or dispersion index)

…….

Method n

threshold:

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. : example (small area) for the PS candidates plot (psc_image.tif).

4.4.9 RESULTS TEST

The inversion, that transforms the relative estimations in measures respect to a reference point, is often source of errors. Testing the spatial unwrapping of the PS network is useful to understand some eventual effects of this error propagation. The OSP is free to implement the algorithm that better suite for its processor. A method that exploits the consistency properties of the network is presented in the two following paragraphs.

4.4.9.1 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. (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. : DEM update estimation residual image (colour scale -1.5 m to +1.5 m). This is the deliverable topo_residuals.tif.

4.4.9.2 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. 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. : 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

The visualisation of the estimated parameters e.g. the ‚raster of interpolated average annual

displacement rates“ is a deliverable according to . 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:


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

Fig. : 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. )

N is the number of interferograms, ifgrm

i and mod

i 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 topo

i , the displacement phase defo

i and APS phase atmo

i :

atmo

i

topo

i

defo

ii mod . (equ. )

Fig. 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:


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




Fig. : 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) . 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.





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)




5 APPENDIX A

This section lists the concerns and question of the OSPs regarding the quality control protocol. For clarity the main issues are extracted merely and an answer or an explanatory statement is provided to each single concern. Excerpts from the feedback documents are indicated by blue coloured paragraphs. The subsequent general comment applies to all feedbacks: The entry not applicable is explicitly allowed in the QCP table. In case alternative information is available it is recommended to provide it.

5.1 FEEDBACK BY TRE

This section is related to the feedback document from the 4th of December 2007.

‚The TRE display programs output in 8-bit jpeg format, which must be converted to 8-bit TIFF.‛

The output image can be provided in any standard, publicly accepted and available image format (e.g. PNG, JPEG and TIFF). It is recommended that

the images should be displayable with freely available tools independent from the used hardware and operating system and

one and the same image format is used throughout the QCP of one delivery.

The end user should not be confronted with file format conversion or license problems. I.e. LZH compression is to be avoided. Using the jpeg-format is fine. I recommend to provide high quality images reducing the compression.

‚We produce a jpeg image for each differential.‛

This is perfect. I recommend to add a line in the respective QCP table which refers to the names of the files or at least provides the naming convention and the location (i.e. the subdirectory on disk) of the files.

5.2 FEEDBACK BY ALTAMIRA

This section is related to the feedback document from the 30th of November 2007 by David Alboil and Geraint Cooksley.

‚PS detection is not made by SCR, but used thresholds and ps densities recorded.‛

A not relevant entry is foreseen to be visible as to be not applicable. The SCR threshold for the PS detection has been chosen due to its known and usable relation to the expected phase precision. The reporting of alternative information e.g. applied thresholds is a good idea. However, the end user finally needs to understand or at least needs to get a good impression how the used threshold is related to the expected phase stability of a single PS. At the moment, the algorithmic basis for your PS detection is unfortunately not disclosed. I.e. key information is missing and the provided values could be of no use to the end user. You could provide the relation between the actual values (on which a threshold is applied in a later step) and the finally estimated phase stability e.g. given by




the coherence. This missing relation can be derived from theory or alternatively you can create a scatter plot between your predicted phase stability and the finally estimated values. Fig. provides an example from DLR’s PSI-GENESIS system. The scatter plot shows the relation between the predicted coherence (i.e. phase stability) and the finally achieved coherence for each PS. Our prediction of coherence is biased and the precision reduces with the coherence. However, there is as simple linear relation and a threshold of 0.85 would result finally in an expected coherence of 0.75. The finally expected coherence 0.75 can be provided in the QCP because the end user can cope with this number.

Fig. : Example from DLR’s PSI-GENESIS system: The scatter plot provides the relation between the predicted coherence (i.e. phase stability) and the finally achieved coherence for each PS. Our prediction of coherence is biased and the precision reduces with the coherence. However, there is as simple linear relation and a threshold of 0.85 would result finally in an expected coherence of 0.75. The finally expected coherence 0.75 can be provided in the QCP because the end user can cope with this number.

‚Absolute height accuracy: Does this refer to the PS height estimates? If so, the absolute height estimate is dependant on knowledge of the true height of the reference point, which is usually unknown.‛

The absolute height accuracy should include finally all errors, i.e. the relative DEM update estimation error, the integration error and the error of the reference point. It has been included into the QCP because it propagates into the geolocation and determines the not correctable (e.g. by tie points) PS location accuracy. In fact, this error value is difficult to be expressed by a single number. The explanation is that the real height estimation precision depends on the actual PS quality and varies




in the test site. This is the reason a realistic expected standard deviation for the overall height error should be provided. It is correct that even this single accuracy number is very difficult to find for each processing. This is the motivation an algorithm is proposed which provides an estimate for the absolute height accuracy. The basic assumption is that the majority of scatterers are directly on the Earth’s surface. Fig. provides a typical histogram of the absolute height estimates in an area of 4 Km x 4 Km. Because the majority of scatterers are assumed to be on the ground, the peak of the histogram separates the estimates into the absolute heights from real scatterers above the Earth and results which are caused by errors and result from the scatterers directly on ground. Finally, it is the left (not causal) part of the histogram which is used to derive an estimate for the absolute height error. The algorithm is in principle the following: For each PS the likelihood function is estimated from a histogram generated in an appropriate area (in the Amsterdam and Alkmaar test site 4 Km x 4 Km are suitable because the area is flat). I.e. the histogram of absolute height estimates similar to Fig. is calculated. The peak in this function is determined and the histogram is converted into a likelihood function of the height error. For this reason the measurements on the right hand side of the peak are removed and the total number of remaining measurements on the

left leftN is determined. The height axis is converted into a high error axis by setting the height value

at the peak to zero. i.e. the axis of abscissae is added by groundh . Assuming a typical Gaussian error

distribution the likelihood function needs to be symmetric and the left half errleft hp of the wanted

likelihood function is obtained by normalising the histogram with the twice the number of total measurements.

left

groundabs

errleftN

hhhistogramhp

2

The standard deviation results from the integration (practically the summation)

err

m

m

errlefterrh hdhpherr

][0

][20

22

The un-symmetric integration is possible due to the normalization of the likelihood function to an area of 0.5, the factor of two and the symmetry assumption.

The proposed algorithm has been implemented and tested on the data provided in the course of the Terrafirma process validation project. Results are shown subsequently.




Fig. : typical likelihood function (histogram) of the absolute height estimates in an area of 4 Km x 4 Km.

Fig. shows the estimated likelihood functions for the Amsterdam ASAR test site from the Terrafirma validation project. An estimation area of 4000m x 4000m is used around each PS. The following table lists the estimated height error standard deviations for the different OSPs:

height error variance height error standard deviation

DLR 3.93 m2 1.98 m

OSP A 8.08 m2 2.84 m

OSP B 4.02 m2 2.01 m

OSP C 15.85 m2 3.98 m

OSP D 16.96 m2 4.12 m

The estimated standard deviations from these likelihood functions correlate well with the relative DEM update precisions found in the validation.

ground

estimates by scatterers above ground estimates by scatterers on ground

abs. height error 0 [m]

hground




Fig. : estimated error likelihood functions for the Amsterdam ASAR test site from the Terrafirma validation project. green: DLR, red: OSP A, black: OSP B, dark blue: OSP C, light blue: OSP D. The estimated standard deviations from these likelihood functions correlate well with the precisions found in the validation.

Fig. shows the estimated likelihood functions for the Alkmaar ASAR test site from the Terrafirma validation project. An estimation area of 4000m x 4000m is used around each PS. The following table lists the estimated height error standard deviations for the different OSPs:

height error variance height error standard deviation

DLR 4.19 m2 2.04 m

OSP A 7.22 m2 2.69 m

OSP B 3.77 m2 1.94 m

OSP C 15.20 m2 3.90 m

OSP D 19.93 m2 4.46 m




Fig. : estimated error likelihood functions for the Alkmaar ASAR test site from the Terrafirma validation project. green: DLR, red: OSP A, black: OSP B, dark blue: OSP C, light blue: OSP D. The estimated standard deviations from these likelihood functions correlate well with the precisions found in the validation.

The derived precisions are also confirmed by the Terrafirma process validation. Integration errors are included as long as these are significantly smaller in dimension compared to the estimation window size for the likelihood function. This is typically a given condition for least squares integration errors. In case of global integration errors (e.g. resulting from straightforward path following algorithms) the height offset error is eliminated by the ground height estimation. The absolute height error is underestimated in this particular case. However, a global integration error should be detected by the QC and removed. For this reason, a new algorithm for the detection of integration errors caused by path following algorithms is proposed in another section.

‚Displ. estimation accuracy: Should be called Expected error / confidence interval of the measurement; accuracy implies ground truth.‛




Ground truth data can be avoided. Similar to the estimation of the absolute height error the absolute deformation estimation precision can be measured from the data. The likelihood function of the deformation error is estimated in a zero deformation area. Such zero deformation areas can often be found by visual inspection of the final estimate’s deformation map. The error estimation is simplified compared to the described algorithm above by the fact that the complete error likelihood function can be estimated.

5.3 FEEDBACK BY GAMMA RS

This section is related to the feedback document from 5th of December 2007 by Urs Wegmüller.

‚To better suite the different processing chains of the OSP it is, in my opinion, important to use a more hierarchic structure for the QCP. The QCP element 4.4 should be better structured. At present it is a list of some quite detailed tests (e.g. missing line detection). Such tests are very often only relevant for one Processing chain but not for another.

The missing line check is a good example for a test which is applicable to each processing system. The missing information can not be recovered and a phase quality degrading results also in case of a self implemented focussing. Not relevant tests can get the entry not applicable in the QCP.

The modified structure should identify the relevant larger QC elements. For the early processing it is quite clear how this can be done, e.g.:

- input data QC

- SLC co-registration QC

For the main part of the processing this is much more difficult to do as the steps used by the OSP differ, the order differ, and critical aspects which would be good to be checked are different. One possible solution could be to keep this part very general and leave most of the responsibility with the OSP.QCP element 4.4 should be better structured .. One possible solution could be to keep this part very general and leave most of the responsibility with the OSP.‛

The order to finalize the QCP is not important however the completeness is. The actually developed QCP provides a practical tradeoff between complexity and comprehensiveness (i.e. implementation effort on the OSP side) and the end user requirements. The comparability of the QC outputs is key for the end user in order to get a good feeling on the quality of the delivered data. To keep the QCP more general and leave the responsibility with the OSP is not an option. This is clearly in contrast to the Terrafirma validation result.

‚coherence‛ or ‚phase standard deviation‛ is not clear enough because it depends very much from what phases it is estimated (e.g. before or after atmosphere removal?).




Equation 10 defines the coherence. It is in this form generally applicable. All estimated parameters can be included and it is expected that the different OSPs can apply different models. In case the APS is estimated it needs to be included into the model.

The coherence is also intended to be a relative quality measure. I.e. the PSs within a test site can be ordered according to their quality.

Pages 20-27, 4.4.2, 4.4.2: we map the entire offset field to check the registration which is a different (but likely better) approach. Our approach for this is not based on point scatterers. The co-registration accuracy is characterized in our case by the standard deviation of the offset estimates from the polynomial function used in the refinement. Offset fields and the offset regression determined for the already co-registered SLCs are typically also available.

Unfortunately, the section on the theoretical basis had to be removed from the QCP document. It included the equations for the precision on the estimation of mutual shifts. They are derived in:

Bamler R., Interferometric Stereo Radargrammetry: Absolute Height Determination from ERS-ENVISAT Interferograms. Proceedings IGARSS, Hamburg, 2000.

The theory and the Terrafirma validation confirm my experience on coregistration and suggest to update the coregistration algorithm and the quality reporting. However, in case you can not accept the effort to implement the proposed quality check you can provide your approach. I suggest to add a brief explanation how to interpret this quality information.

Page 28-30, 4.4.4 no DINSAR processing is done in our case therefore not applicable. The differential interferograms are only produced at the PS points, not at every pixel. Quicklooks of point differential interferograms could be calculated (but this is probably best done after correcting the point heights, the baselines, and considering at least linear deformation rates, and possibly also the atmospheric correction – which should then be separately displayed)

It can be advantageous to generate quicklooks of the interferometric data in an early stage of the processing. It can help to check for an optimal master scene selection or to remove unsuitable interferograms from the estimation. Quicklooks of differential interferograms sampled at the detected PSs can be an alternative delivery for the item 4.4.4.

Page 39, 4.6: chapter should be called ‚statistical accuracy‛ The focus should then be on statistical estimates of the precision of the heights and deformations. While in the proposed version this is done for the deformation rate the height accuracy and the geocoding accuracy are determined in ‚validation experiments‛ which should probably not be part of the QCP or which should at least be optional, as such information is often not available and its use seems not to be part of the OSP service. The statistical measures that can be calculated need to be precisely defined and also how they are applied (for each point, for filtered results, with/without APS etc.)

The entries absolute height and displacement accuracies were intended to be completed based on the OSPs experience on the used algorithms, the available data, the understanding on the error propagation and the difficulties during the actual data processing. No validation experiments are




required. However, the experiences from former validation experiments and projects could be helpful and should be included. In the update of the QCP algorithms for the estimation of the absolute height and deformation estimation precision are proposed.

5.4 FEEDBACK BY NPA

This section is related to the feedback document from 27th of November by Jessica Hole and Becky Stokes.

The Gamma display programs output in 8-bit sunraster or bitmap format, which have been converted to 8-bit TIFF using the Imagemagick Convert program.

The file format for visualisations is not important. However, sunraster images can not be easily displayed on a PC windows computer. A related recommendation is given in section 5.1.

4.2 Data Availability and Feasibility

Expected effect - Is this entry a description of the expected deformation phenomena?

Yes, you are right. This entry should provide a priory available information on any displacement effect. I suggest to provide any spatial and temporal information. The end user can compare this with the measurement and should be especially attentive in case of a discrepancy.

4.4.4 Orbit trend and APS check

The differential interferograms are only produced at the PS points, not at every pixel.

This seems to me a shortcoming in the actual implementation. It can be advantageous to generate quicklooks of the interferometric data in an early stage of the processing. It can help to check for an optimal master scene selection or to remove unsuitable interferograms from the estimation. Quicklooks of differential interferograms sampled at the detected PSs can be an alternative delivery for the item 4.4.4. The quicklooks provide very useful quality information at nearly no cost.

4.4.8 PS detection

A program/script for measuring the SCR of the PS and producing psc_histogram.tif and ps_histogram.tif would need to be created in order to carry out this step.

PS are selected by a combination of two methods

1. Temporal coherence (MSR threshold)

2. Spectral phase diversity (threshold)




I suggest to provide the applied thresholds of the used methods of your actual processing. Additionally, you should add the information how these thresholds limit the (expected) phase noise. The end user needs this information.

The 1) temporal coherence and 2) the spectral phase diversity are implemented to be predictors for the phase stability which can finally be expressed by the phase standard deviation of the single radar observation. Consequently there should be a relation between the expected phase noise standard deviation and your estimated prediction. It can be derived from theory or by scatter plots of the prediction versus the final coherence (or the respective phase standard deviation). An example is provided in Fig. .

4.4.8 PS detection

Should psc_image.tif and ps_image.tif be single look images?

In DLR’s PSI-GENESIS system these visualizations are based even on the oversampled scenes. From my practical experience, a better sampling improves the information provided by these images.

4.4.9 DEM update unwrapping test & 4.4.10 Displacement unwrapping test

Currently unsure how this fits into our processing chain. The height at each pixel is calculated relative to only one reference point.

The residual images according to Fig. and Fig. can also be generated with the described processing. Two independent estimates need to be calculated using two different reference points which are located close to each other and have a high SCR. The principle is visualized in Fig. . The two independent estimates are indicated by the blue and the green colour. The grey triangle shows an example cycle on which the residuum can be calculated.

Ref 1

Ref 2

need

s to

be

correc

t

plea

se c

heck

for hi

gh c

oher

ence

Fig. : Two independent estimates need to be calculated using the available algorithm. These are indicated by the blue and the green colour. Cycles for the calculation of the residua can now easily be found. An example is drawn in grey colour.




APS Check

What does this involve? There is no section in the QCP document.

At the moment, the check for the APS is not defined. The OSP can develop and apply a quality test which is appropriate to the actual processing system. E.g. the APS is checked in the DLR PSI-GENESIS processing by a visual inspection of the interpolated APS. Fig. provides examples for a typical APS and an estimated APS which requires to be checked in more detail before the processing continues.

Fig. : The APS is checked in the DLR processing by a visual inspection of the interpolated APS. left image: The APS looks cloudy i.e. as expected. right image: The ramp and the visible dipoles indicate the need for a more detailed inspection of this APS estimate.

4.6 Expected Accuracy

Coherence map - Is interpolation acceptable in coh_map.tif?

The defined coherence is physically given point-wise i.e. per PS. Moreover, there is no correlation of the coherence values of points close together. Consequently, there is no advantage for an additional interpolation and even sub-sampling should be avoided. The coherence range which is visualized can be adapted according to the actual data.




6 APPENDIX B

6.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


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


ture

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

severe: not applicable / deleted

coregistration check Type:

Precision:

Unit:

11/08/2004 NA


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 11/08/2004 NA





coherence_orbit.tif

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 Method: SCR

threshold: 1.5

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


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





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


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

6.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


Quality Control Protocol

Service Portfolio Specifications (S5)


input reader

InSAR

PSI

calibration

non standard processing




4 Processing


ture

SLC missing lines check

coregistration check



APS and orbit trend check

coherence images

scene phase unwrapping

scene calibration

PS detection

DEM Update Unwrapping

Displacement Unwrapping

APS Check




5 Visualisation


ture

displacement map

needs to be continued for other visualisations

6 Expected Accuracy


ture

coherence map

geolocation accuracy

correction due to GCP(s)

absolute height accuracy

ambiguities

displ. estimation accuracy

7 Product Delivery


ture

completeness of delivery

delivery date

delivery due date

delivery address

delivery service

-- End of document --

quality conrol protocol for level 1 products · 3 quality control working scenarios ... [r6] ceos...

Documents