222 lines
11 KiB
XML
222 lines
11 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<topsApp>
|
|
<component name="topsinsar">
|
|
<property name="Sensor name">SENTINEL1</property>
|
|
<component name="reference">
|
|
<catalog>reference.xml</catalog>
|
|
</component>
|
|
<component name="secondary">
|
|
<catalog>secondary.xml</catalog>
|
|
</component>
|
|
</component>
|
|
</topsApp>
|
|
<!--
|
|
General Note: Using syntax highlighting makes it easier to read XML file.
|
|
-->
|
|
<!-- This is an xml comment -->
|
|
<!-- An xml comment begins with the 4 characters at the start of this line and
|
|
end with the 3 characters at the end of this line. -->
|
|
<!-- The rest of this file contains comments only. -->
|
|
<!--
|
|
An xml file is structured with content appearing between the tags indicated
|
|
with the symbols '< >' and the matching closing tag symbols '</ >'. There are
|
|
4 different types of tags used in the 11 lines at the top of this file:
|
|
|
|
(1) The tag <topsApp> and its closing tag </topsApp> are required but the
|
|
name is arbitrary.
|
|
|
|
(2) The <property> </property> tags are used for simple properties. These
|
|
tags includes a 'name' ('sensor name' in the above example) as an attribute
|
|
of the tag as well as a value appearing between the opening and closing tags.
|
|
|
|
(3) The <component> </component> tags are used for collections of properties
|
|
belonging to the component indicated by the 'name' attribute of the tag.
|
|
|
|
(4) The <catalog> </catalog> has no 'name' attribute and the value given
|
|
between the tags is the name of another xml file containing the properties
|
|
for the component.
|
|
|
|
There are other types of tags that may be used as shown in examples below.
|
|
|
|
-->
|
|
<!--
|
|
The 11 lines at the top of this file give the minimal input file for running
|
|
insarApp.py, but most of the input information is contained in the two xml
|
|
files reference.xml and secondary.xml sandwiched between the <catalog> tag and the
|
|
</catalog> tag.
|
|
The reference.xml and secondary.xml files are different in structure for different
|
|
sensors but identical to each other in structure for a given sensor. Examples
|
|
of reference.xml for each sensor type are given in this directory with names like
|
|
reference_tops_sentinel1a.xml. You can use these files as templates for creating your own
|
|
reference.xml and secondary.xml files. You can also in-line the contents of those
|
|
files directly in the insarApp.xml file as in the following example for ALOS:
|
|
|
|
<topsApp>
|
|
<component name="topsinsar">
|
|
<component name="reference">
|
|
<property name="orbit directory">/Users/agram/orbit/S1A/precise</property>
|
|
<property name="auxiliary data directory">/Users/agram/orbit/S1A/aux</property>
|
|
<property name="output directory">reference</property>
|
|
<property name="swath number">2</property>
|
|
<property name="safe">../data/S1A_IW_SLC__1SSV_20150119T135944_20150119T140004_004241_005286_4271.SAFE</property>
|
|
</component>
|
|
<component name="secondary">
|
|
<property name="orbit directory">/Users/agram/orbit/S1A/precise</property>
|
|
<property name="auxiliary data directory">/Users/agram/orbit/S1A/aux</property>
|
|
<property name="region of interest">[35.4, 35.6, -119.6, -119.4]</property>
|
|
<property name="output directory">secondary</property>
|
|
<property name="swath number">2</property>
|
|
<property name="safe">../data/S1A_IW_SLC__1SSV_20150212T135943_20150212T140003_004591_005A67_5DEC.SAFE</property>
|
|
</component>
|
|
</component>
|
|
</topsApp>
|
|
|
|
-->
|
|
<!-- <<INPUTS FOR topsApp.py>>
|
|
This file provides a basic template for setting up interferogram input file for topsApp.py. Only the commonly used options are described here.
|
|
|
|
There are three ways of providing basic inputs to topsApp.py. Choose any one to work with. We recommend Method 1.
|
|
|
|
Method 1: Using topsApp.xml [Uses in-built configurability]
|
|
|
|
>topsApp.py
|
|
- Automatically looks for topsApp.xml and loads ISCE Application instance configuration.
|
|
|
|
Method 2: Using topsinsar.xml [Uses in-built configurabiluty]
|
|
> topsApp.py
|
|
- Automatically looks for topsinsar.xml and loads ISCE Application family configuration.
|
|
- "insarApp" is a specific instance of family "topsinsar". topsApp.py first reads topsinsar.xml to configure object and then reads topsApp.xml. If values are repeated in the two files, topsApp.xml takes precedence over topsinsar.xml .
|
|
|
|
|
|
Method 3 : Using arbitrary xml file with the same structure as below.
|
|
|
|
> topsApp.py input.xml [Explicitly force use of specific XML file)
|
|
- topsApp.py checks for topsinsar.xml and loads information if available.
|
|
- topsApp.py then checks for topsApp.xml and if available updates/creates configuration.
|
|
- topsApp.py then "input.xml" and updates/creates configuration.
|
|
-->
|
|
<!-- <<ISCE XML property formats>>
|
|
ISCE XML files support two types of property definitions.
|
|
|
|
Format 1:
|
|
<property name="Sensor name">SENTINEL1</property>
|
|
|
|
Format 2:
|
|
<property name="Sensor name">
|
|
<value>SENTINEL1</value>
|
|
</property>
|
|
-->
|
|
<!--
|
|
|
|
<topsApp> This tag name doesn't really matter.
|
|
<component name="topsinsar"> This component has to be named topsinsar
|
|
|
|
Mandatory entries:
|
|
|
|
Full list of sensors can be obtained using "topsApp.py -h"
|
|
<property name="Sensor name">SENTINEL1</property>
|
|
|
|
Reference and secondary information are provided through catalogs.
|
|
The structure of these catalog files are sensor dependent.
|
|
See "reference_TOPS_SENSOR.xml" for examples of different sensors.
|
|
<component name="reference">
|
|
<catalog>reference.xml</catalog> Grabs information from reference.xml
|
|
</component>
|
|
<component name="secondary">
|
|
<catalog>secondary.xml</catalog> Grabs information from secondary.xml
|
|
</component>
|
|
|
|
-->
|
|
<!-- Optional entries.
|
|
These need not be defined by the user.
|
|
Default values will be used if not provided.
|
|
Uncomment the <property> tags if you want to use these.-->
|
|
<!-- << DEM >>
|
|
If not provided, SRTM DEM will be automatically downloaded.
|
|
See "dem_latest.xml" in examples directory for an example.-->
|
|
<!--
|
|
<property name="demFilename">dem_latest.dem</property> Grabs information from dem_latest.dem.xml
|
|
-->
|
|
<!--<property name="range looks">2</property>-->
|
|
<!--<property name="azimuth looks">4</property>-->
|
|
<!--Subsetting the amount of data to be processed.
|
|
To selectively process only some swaths, add the following tag. Note that even if its a single swath provide the entry as a list. This entry overrides the swath number entry in reference.xml and secondary.xml. If not included, all swaths will be processed.
|
|
<property name="swaths">[1,2]</property>
|
|
|
|
To selective process a region, provide a bounding box in SNWE convention (lat/lon)
|
|
This will again override any region of interest in reference.xml and secondary.xml. If the region of interest is covered by a fewer number of swaths, only those swaths will be processed.
|
|
<property name="region of interest">[32.5, 33,130.4, 132.5]</property>
|
|
-->
|
|
<!-- Disabling Enhanced Spectral Diversity azimuth offset refinement
|
|
By default, ESD is always performed.
|
|
<property name="do ESD">False</property> -->
|
|
<!-- <<FILTER STRENGTH>>
|
|
Goldstein filter length-->
|
|
<!--<property name="filter strength">0.4</property>-->
|
|
<!-- <<PHASE UNWRAPPING>>
|
|
Phase unwrapping can be optionally turned off.
|
|
Following unwrappers are currently available:
|
|
grass, icu, snaphu, snaphu_mcf, downsample_snaphu-->
|
|
<!--<property name="do unwrap">True</property>-->
|
|
<!--<property name="unwrapper name">snaphu_mcf</property>-->
|
|
<!-- 2 Stage unwrapping option requires the following tags:-->
|
|
<!--<property name="do unwrap">True</property> -->
|
|
<!--<property name="unwrapper name">snaphu_mcf</property> -->
|
|
<!--<property name="do unwrap 2 stage">True</property> -->
|
|
<!--<property name="unwrapper 2 stage name">MCF</property> -->
|
|
<!-- <<GEOCODING>> -->
|
|
<!-- Creating geocoded coregistered stacks is easy with ISCE.
|
|
You can specify the exact geocoding bounding box in SNWE format as follows.
|
|
As long as the same DEM and bounding box are used, all products will be
|
|
geocoded to the same grid.-->
|
|
<!--<property name="geocode bounding box">[19.1, 19.45, -155.45, -154.7]</property>-->
|
|
<!-- By default ISCE geocodes a long list of products. Once, you are familiar with
|
|
the product names, you can force ISCE to geocode only products of interest to you.
|
|
Geocoding parameters for a file named "abc.def" can be controlled using insarapp_geocode_abcdef.xml-->
|
|
<!--<property name="geocode list">['filt_topophase.flat', 'los.rdr', 'topophase.cor', 'phsig.cor']</property>-->
|
|
<!--
|
|
</component>
|
|
</insarApp>
|
|
-->
|
|
<!--
|
|
#####################################################################
|
|
#ionospheric correction module parameters
|
|
#the values below are the default values used by the module
|
|
<property name="do ionosphere correction">False</property>
|
|
<property name="apply ionosphere correction">False</property>
|
|
<property name="consider burst properties in ionosphere computation">False</property>
|
|
#choose from: ['subband', 'rawion', 'grd2ion', 'filt_gaussian', 'ionosphere_shift', 'ion2grd', 'esd']
|
|
<property name="start ionosphere step">subband</property>
|
|
<property name="end ionosphere step">esd</property>
|
|
|
|
<property name="height of ionosphere layer in km">200.0</property>
|
|
<property name="apply polynomial fit before filtering ionosphere phase">True</property>
|
|
<property name="maximum window size for filtering ionosphere phase">200</property>
|
|
<property name="minimum window size for filtering ionosphere phase">100</property>
|
|
<property name="maximum window size for filtering ionosphere azimuth shift">150</property>
|
|
<property name="minimum window size for filtering ionosphere azimuth shift">75</property>
|
|
#0: no correction
|
|
#1: use mean value of a burst
|
|
#2: use full burst
|
|
<property name="correct phase error caused by ionosphere azimuth shift">1</property>
|
|
|
|
#seperated islands or areas usually affect ionosphere estimation and it's better to mask them
|
|
#out. check ion/ion_cal/raw_no_projection.ion for areas to be masked out.
|
|
#The parameter is a 2-D list. Each element in the 2-D list is a four-element list: [firstLine,
|
|
#lastLine, firstColumn, lastColumn], with line/column numbers starting with 1. If one of the
|
|
#four elements is specified as -1, the program will use firstLine/lastLine/firstColumn/
|
|
#lastColumn instead. For exmple, if you want to mask the following two areas out, you can
|
|
#specify a 2-D list like:
|
|
#[[100, 200, 100, 200],[1000, 1200, 500, 600]]
|
|
<property name="areas masked out in ionospheric phase estimation">None</property>
|
|
|
|
#better NOT try changing the following two parameters, since they are related
|
|
#to the filtering parameters above
|
|
<property name="total number of azimuth looks in the ionosphere processing">50</property>
|
|
<property name="total number of range looks in the ionosphere processing">200</property>
|
|
#the above numbers should be integer multiples of the below numbers
|
|
<property name="number of azimuth looks at first stage for ionosphere phase unwrapping">10</property>
|
|
<property name="number of range looks at first stage for ionosphere phase unwrapping">40</property>
|
|
#####################################################################
|
|
-->
|