4. L1a/b Products Format Specification#
4.1 Main product header#
The Main Product Header (MPH) is an XML file present in all the BIOMASS L1 products. BIOMASS L1 products are folder based and the MPH is top level leaf of the product tree.
The MPH main scope is to provide all the information related to the:
Genesis of the product;
Identification of the product for example for cataloguing purposes;
Product consistency (filesize).
For the detailed description of the MPH content and format refer to [AD3]. Here just a schematic representation is reported.
bio:EarthObservation Root element of metadata representation tailored for BIOMASS SAR products
om:phenomenonTime Time coverage of the product
gml:TimePeriod Time coverage of the product as a period
gml:beginPosition Start date and time of the product
gml:endPosition Stop date and time of the product
om:resultTime Time when the sensing data has become available
gml:TimeInstant Identifiable position in time
gml:timePosition Date and time of data availability
om:validTime Time validity of the product
gml:TimePeriod Time validity of the product as a period
gml:beginPosition Validity start date and time of the product
gml:endPosition Validity stop date and time of the product
om:procedure Procedure used to sense the data
eop:EarthObservationEquipment Equipment used to sense the data
eop:platform Platform description
eop:Platform Nested element for platform description
eop:shortName Satellite name
eop:instrument Instrument description
eop:Instrument Nested element for instrument description
eop:shortName Sensor name
eop:sensor Sensor description
eop:Sensor Nested element for sensor description
eop:sensorType Sensor type
eop:operationalMode Sensor operational mode
eop:swathIdentifier Swath identifier
eop:acquisitionParameters Acquisition parameters
bio:Acquisition Acquisition description
eop:orbitNumber Acquisition orbit number (orbit start)
eop:lastOrbitNumber Last orbit number (orbit stop)
eop:orbitDirection Orbit direction
eop:wrsLongitudeGrid Track number
eop:wrsLatitudeGrid Frame number
eop:ascendingNodeDate Date and time of ANX
eop:startTimeFromAscendingNode Start time from ANX
eop:completionTimeFromAscendingNode Stop time from ANX
sar:polarisationMode SAR Polarisation mode
sar:polarisationChannels SAR Polarisation channels
sar:antennaLookDirection SAR antenna look direction
bio:missionPhase BIOMASS mission phase
bio:instrumentConfID BIOMASS instrument configuration identifier
bio:dataTakeID BIOMASS data take identifier
bio:orbitDriftFlag BIOMASS orbit drift flag
bio:globalCoverageID BIOMASS global coverage identifier
bio:majorCycleID BIOMASS major cycle identifier
bio:repeatCycleID BIOMASS repeat cycle identifier
om:observedProperty Observed property (empty)
om:featureOfInterest Observed area
eop:Footprint Footprint description
eop:multiExtentOf Footprint representation structure, coordinates in posList
gml:MultiSurface
gml:surfaceMember
gml:Polygon
gml:exterior
gml:LinearRing
gml:posList Footprint points, i.e. 4 corner coordinates of the scene starting with the first-right in flight direction and proceeding CCW (first point to be added as fifth point to close the polygon)
eop:centerOf Acquisition centre representation structure
gml:Point
gml:pos Coordinates of the centre of the acquisition
om:result Observation result
eop:EarthObservationResult
eop:browse
eop:BrowseInformation
eop:type Browse type
eop:referenceSystemIdentifier Coordinate reference system name
eop:fileName
ows:ServiceReference Browse Image filename
ows:RequestMessage download request (empty)
eop:product
bio:ProductInformation
eop:fileName
ows:ServiceReference Product filename
ows:RequestMessage download request (empty)
eop:version Product baseline
eop:product (list)
bio:ProductInformation
eop:fileName
ows:ServiceReference Product filename (internal files)
ows:RequestMessage download request (empty)
eop:size Product size
bio:rds Representation data file related to xml product
eop:metaDataProperty Observation metadata
bio:EarthObservationMetaData
eop:identifier Product identifier
eop:doi Digital Object Identifier
eop:acquisitionType Type of acquisition
eop:productType Product type
eop:status Status of the product
eop:downlinkedTo Downlink information
eop:DownlinkInformation
eop:acquisitionStation Acquisition station
eop:acquisitionDate Downlink date time
eop:processing Data processing information
bio:ProcessingInformation
eop:processingCenter Processing centre
eop:processingDate Processing date and time
eop:processorName Processor name
eop:processorVersion Processor version
eop:processingLevel Processing level
eop:auxiliaryDataSetFileName Auxiliary DS file name
eop:processingMode File Class
bio:sourceProduct BIOMASS source product identifier
bio:TAI-UTC Difference between TAI and UTC times of product
bio:numOfTFs Number of transfer frames
bio:numOfTFsWithErrors Number of transfer frames with errors
bio:numOfCorruptedTFs Number of corrupted transfer frames
bio:numOfISPs Number of instrument source packets
bio:numOfISPsWithErrors Number of instrument source packets with errors
bio:numOfCorruptedISPs Number of corrupted instrument source packets
bio:numOfLines Number of L0 lines
bio:numOfMissingLines Number of L0 missing lines
bio:numOfCorruptedLines Number of L0 corrupted lines
bio:incompleteSlice Incomplete L0 slice flag
bio:partialSlice Partial L0 slice flag
bio:framesList List of L1 frames contained in L0
bio:incompleteFrame Incomplete L1 frame flag
bio:partialFrame Partial L1 frame flag
bio:refDoc Reference document
Main product header (metadata schematic representation)
4.2 Measurement data sets (MDS)#
4.2.1 SAR image MDS#
The SAR image MDS is used to store the SAR image binary raster data as generated by the L1 processor for all the foreseen BIOMASS data polarisations (HH, HV, VH, VV).
The format used to store the SAR image MDS is the Cloud Optimized GeoTIFF [RD1].
A Cloud Optimized GeoTIFF (COG) is a regular GeoTIFF file, aimed at being hosted on a HTTP file server, with an internal organization that enables more efficient workflows on the cloud. It does this by leveraging the ability of clients issuing HTTP GET range requests to ask for just the parts of a file they need.
The COG format is natively supported by GDAL library [RD2] [RD3] and by libraries and tools based on GDAL library (Dask and Rasterio packages for Python, …).
Differently from other SAR missions (and from the standard way of storing SAR data), for the BIOMASS mission SAR data are stored separating amplitude and phase values of each pixel instead of its real and imaginary parts. In particular, the SAR image MDS will be composed by two files:
one COG file with the amplitude values (square root of beta-nought quantity, absolute calibration constant applied, linear scale) of each pixel;
one COG file with the phase values (radians) of each pixel.
For both the files, four separated components will be used, one for each BIOMASS data polarisation in lexicographic order (i.e., HH, HV, VH, VV). It must be noted that all the four polarisations of BIOMASS L1 products will be sampled over the same sampling grid, allowing an easy access through the different components.
Obviously for L1b products (DGM) only the first file with the amplitude values will be included in the product, being the data already detected and not complex.
The main rationale behind this choice stands in the products usability. Amplitude and phase representation has in fact several advantages from the users’ point of view:
ease image visualization on a map, either using a data browser on a cloud computing platform or through a GIS software on a local PC, and the generation of overviews;
run applications that exploit the amplitude only;
run fast workflows on a cloud computing platform on a custom subset of data;
speed-up applications working on all the polarisations together;
and more.
Compression strategy
The separation of amplitude and phase parts allows to introduce with benefit a set of different strategies for data compression. Making use of native LibTIFF libraries capabilities [RD4], it is possible to adopt:
32bits/pixel + GeoTIFF
LERC_ZSTDcompression (MAX_Z_ERROR=0.0001) for amplitude part;32bits/pixel + GeoTIFF
LERC_ZSTDcompression (MAX_Z_ERROR=0.001) for phase part.
This approach will allow to achieve a considerable compression factor (~2x with an error of 0.06dB on amplitude @-37dB and of 0.001rad / 0.0572deg on phase).
VRT – GDAL Virtual Format
The VRT driver is a format driver for GDAL that allows a virtual GDAL dataset to be composed from other GDAL datasets with repositioning, and algorithms potentially applied as well as various kinds of metadata altered or added.
For the sake of “retro-compatibility” and to ease the management of BIOMASS data by those SAR processing applications designed to work on real and imaginary parts, it is foreseen to include in BIOMASS L1a products a VRT file (XML format). The scope is to describe how to pass from the amplitude and phase representation (stored on disk) to the real and imaginary parts one. VRT files are natively managed by GDAL library allowing to perform this transcoding on-the-fly directly during the access to the data stored on disk, so that the whole process is transparent for the user.
Here below a sample VRT file is reported:
<<?xml version=“1.0” encoding=“utf-8”?>
<VRTDataset rasterXSize=“1380” rasterYSize=“21265”>
<GCPList Projection=“GEOGCRS["WGS 84",ENSEMBLE["World Geodetic System 1984 ensemble",MEMBER["World Geodetic System 1984 (Transit)"],MEMBER["World Geodetic System 1984 (G730)"],MEMBER["World Geodetic System 1984 (G873)"],MEMBER["World Geodetic System 1984 (G1150)"],MEMBER["World Geodetic System 1984 (G1674)"],MEMBER["World Geodetic System 1984 (G1762)"],MEMBER["World Geodetic System 1984 (G2139)"],ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1]],ENSEMBLEACCURACY[2.0]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],CS[ellipsoidal,3],AXIS["geodetic latitude (Lat)",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433]],AXIS["geodetic longitude (Lon)",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433]],AXIS["ellipsoidal height (h)",up,ORDER[3],LENGTHUNIT["metre",1]],USAGE[SCOPE["Geodesy. Navigation and positioning using GPS satellite system."],AREA["World."],BBOX[-90,-180,90,180]],ID["EPSG",4979]]”>
<GCP Id=“1” Info=“GCP1” Pixel=“0” Line=“0” X=“2.766610117165289” Y=“40.867629249542226” Z=“47.44995130971074”/>
<GCP Id=“2” Info=“GCP2” Pixel=“0” Line=“2000” X=“2.7229108886640847” Y=“40.9850029875603” Z=“47.6954053286463”/>
<!– omissis –>
<GCP Id=“46” Info=“GCP46” Pixel=“1379” Line=“18000” X=“1.7056110678368939” Y=“41.777702020736534” Z=“527.1823539100587”/>
<GCP Id=“47” Info=“GCP47” Pixel=“1379” Line=“20000” X=“1.657004737026843” Y=“41.8941560464991” Z=“652.2788440166041”/>
<GCP Id=“48” Info=“GCP48” Pixel=“1379” Line=“21264” X=“1.6270188350235635” Y=“41.96792825220514” Z=“688.6636372571811”/>
</GCPList>
<Metadata>
<MDIType key=“AREA_OR_POINT”>Area</MDIType>
<MDIType key=“MATRIX_REPRESENTATION”>SCATTERING</MDIType>
<MDIType key=“ABS_MAX_Z_ERROR”>0.0001</MDIType>
<MDIType key=“PHASE_MAX_Z_ERROR”>0.001</MDIType>
<MDIType key=“PolarisationsSequence”>HH HV VH VV</MDIType>
<MDIType key=“Swath”>S2</MDIType>
<MDIType key=“DATETIME”>2024-05-31T13:19:44.034802</MDIType>
<MDIType key=“IMAGEDESCRIPTION”>BIOMASS L1</MDIType>
<MDIType key=“SOFTWARE”>BPS-Biomass L1 Processor-2.2.3</MDIType>
</Metadata>
<VRTRasterBand dataType=“CFloat32” band=“1” subClass=“VRTDerivedRasterBand”>
<Description>HH</Description>
<NoDataValue>-9999.0</NoDataValue>
<Metadata>
<MDIType key=“POLARIMETRIC_INTERP”>HH</MDIType>
</Metadata>
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_abs.tiff</SourceFilename>
<SourceBand>1</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_phase.tiff</SourceFilename>
<SourceBand>1</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<PixelFunctionType>polar</PixelFunctionType>
<SourceTransferType>Float32</SourceTransferType>
<PixelFunctionArguments amplitude_type=“AMPLITUDE”/>
</VRTRasterBand>
<VRTRasterBand dataType=“CFloat32” band=“2” subClass=“VRTDerivedRasterBand”>
<Description>HV</Description>
<NoDataValue>-9999.0</NoDataValue>
<Metadata>
<MDIType key=“POLARIMETRIC_INTERP”>HV</MDIType>
</Metadata>
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_abs.tiff</SourceFilename>
<SourceBand>2</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_phase.tiff</SourceFilename>
<SourceBand>2</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<PixelFunctionType>polar</PixelFunctionType>
<SourceTransferType>Float32</SourceTransferType>
<PixelFunctionArguments amplitude_type=“AMPLITUDE”/>
</VRTRasterBand>
<VRTRasterBand dataType=“CFloat32” band=“3” subClass=“VRTDerivedRasterBand”>
<Description>VH</Description>
<NoDataValue>-9999.0</NoDataValue>
<Metadata>
<MDIType key=“POLARIMETRIC_INTERP”>VH</MDIType>
</Metadata>
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_abs.tiff</SourceFilename>
<SourceBand>3</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_phase.tiff</SourceFilename>
<SourceBand>3</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<PixelFunctionType>polar</PixelFunctionType>
<SourceTransferType>Float32</SourceTransferType>
<PixelFunctionArguments amplitude_type=“AMPLITUDE”/>
</VRTRasterBand>
<VRTRasterBand dataType=“CFloat32” band=“4” subClass=“VRTDerivedRasterBand”>
<Description>VV</Description>
<NoDataValue>-9999.0</NoDataValue>
<Metadata>
<MDIType key=“POLARIMETRIC_INTERP”>VV</MDIType>
</Metadata>
<ColorInterp>Gray</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_abs.tiff</SourceFilename>
<SourceBand>4</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<SimpleSource>
<SourceFilename relativeToVRT=“1”>bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_i_phase.tiff</SourceFilename>
<SourceBand>4</SourceBand>
<SourceProperties RasterXSize=“1380” RasterYSize=“21265”/>
</SimpleSource>
<PixelFunctionType>polar</PixelFunctionType>
<SourceTransferType>Float32</SourceTransferType>
<PixelFunctionArguments amplitude_type=“AMPLITUDE”/>
</VRTRasterBand>
</VRTDataset>
Metadata
The TIFF and GeoTIFF tags used to annotate SAR image MDS are described in the following table. For the complete description of each tag refer to official TIFF format documentation [RD5].
Table 2 — SAR image MDS – TIFF and GeoTIFF tags
Tag Name |
Code |
Value |
Description |
|---|---|---|---|
ImageWidth |
256 |
Variable |
Number of columns in the image, i.e. the number of pixels per row. |
ImageLength |
257 |
Variable |
Number of rows of pixels in the image. |
BitsPerSample |
258 |
32 or 16 |
Number of bits per component. |
Compression |
259 |
32946 (DEFLATE), 34887 (LERC), 50000 (ZSTD) |
Compression scheme used on the image data. |
LercParameters |
50674 |
Variable |
LERC compression parameters: version, additional compression. e.g. 4,2 for LERC v4 with ZSTD |
PhotometricInterpretation |
262 |
1 |
Colour space of the image. Always set to 1 (minimum value is black). |
ImageDescription |
270 |
Variable |
A string that describes the image. Examples: “BIOMASS L1a” and “BIOMASS L1b”. |
SamplesPerPixel |
277 |
3, 4 |
The number of components per pixel. Always set to 4 for L1a/b, i.e., one per polarisation in the order defined by PolarisationsSequence, can be 3 or 4 for L1c. |
PlanarConfiguration |
284 |
2 |
How the components of each pixel are stored. Always set to 2 (separate). |
Software |
305 |
Variable |
Software name and version that created the image. |
DateTime |
306 |
Variable |
Date and time of image creation in the format: YYYY:MM:DD HH:MM:SS |
TileWidth |
322 |
Variable |
The tile width in pixels. This is the number of columns in each tile. |
TileLength |
323 |
Variable |
The tile length (height) in pixels. This is the number of rows in each tile. |
TileOffsets |
324 |
Variable |
For each tile, the byte offset of that tile, as compressed and stored on disk. |
TileByteCounts |
325 |
Variable |
For each tile, the number of (compressed) bytes in that tile. |
SampleFormat |
339 |
3 or 1 |
Specifies how to interpret each data sample in a pixel. Set to 3 (IEEE floating point data) or 1 (unsigned integer data). |
ModelTiePointTag |
33922 |
N * (pixel, line, lat, long, h) |
Maps image pixels to geographic coordinates, where N is the number of tie points in the scene, i.e.: - 5 tie points along range direction - 1 tie point each 10 seconds along azimuth direction Note: values have been computed in order to have an overall accuracy not worse than 100m (above ellipsoid). |
GeoKeyDirectoryTag |
34735 |
Variable |
Contains the value of all GeoTIFF keys of type SHORT and the location of the values for GeoTIFF keys of other types. |
|
42112 |
Variable |
Contains GDAL metadata (see table below) |
|
42113 |
Variable |
ASCII encoded nodata or background pixel value. |
The GDAL_METADATA tag content is listed in the following table
Table 3 — SAR image MDS – GDAL_METADATA tiff tag content
Tag Name |
Value |
Description |
|---|---|---|
Swath |
S1,S2,S3 |
Image swath: S1,S2,S3 |
PolarisationsSequence |
Variable |
String: list of polarisations associated to the raster bands in the corresponding order. For esample: “HH HV VH VV” means that band 1 corresponds to the HH polarization, band 2 to the HV polarization band 3 to the VH polarization and band 4 to the VV polarization |
|
Variable |
Maximum compression error threshold. Used only in case compression scheme is LERC, |
|
SCATTERING or |
SCATTERING is used for l1a/l1b product. SYMMETRIZED SCATTERING is used for l1c products when the cross-polarisations are combined. |
|
Variable |
This metadata is associated to the GDAL raster band. For each raster band it specifies which polarization the band is associated to. Possible values are “HH”, “HV”, “VH”, “VV” |
Overviews
The usage of amplitude and phase representation together with the exploitation of GDAL library allows to easily add to amplitude COG file one or more overviews of the SAR image.
Overviews are sub-sampled versions of a SAR image. Adding one or more overviews at different resolution levels allows to use pyramidal viewers directly on SAR image amplitude file, without the need of transcoding operations or of further processing.
The following (minimum) number of overviews is foreseen:
for L1a products:
multi-look factors (range x azimuth): 2x2 (ground resolution ~ 100x17m)
multi-look factors (range x azimuth): 5x5 (ground resolution ~ 250x42m)
multi-look factors (range x azimuth): 10x10 (ground resolution ~ 500x83m)
multi-look factors (range x azimuth): 20x20 (ground resolution ~ 1kmx167m)
for L1b products: 5. multi-look factors (range x azimuth): 2x2 (ground resolution ~ 100x100m) 6. multi-look factors (range x azimuth): 5x5 (ground resolution ~ 250x250m) 7. multi-look factors (range x azimuth): 10x10 (ground resolution ~ 500x500m) 8. multi-look factors (range x azimuth): 20x20 (ground resolution ~ 1x1km)
4.3 Annotation data sets (ADS)#
4.3.1 Main ADS#
This section describes in details the content of main ADS and of all its DSR.
An overview is provided by figure and table below.
Fig. 3 — Main ADS
Table 4 — Main ADS
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Acquisition information DSR. This DSR contains information that applies to the entire data set. |
|
1 |
|
SAR image DSR. This DSR contains all the necessary information to exploit the measurement data set (i.e. SAR images). |
|
1 |
|
Instrument parameters DSR. This DSR contains the main instrument settings at the time of imaging. |
|
1 |
|
RAW data analysis DSR. This DSR contains the main elements related to the RAW data consolidation and analysis performed by the processor. |
|
1 |
|
Processing parameters DSR. This DSR contains the exhaustive list of static SAR processing parameters and of corrections applied. |
|
1 |
|
Internal calibration DSR. This DSR contains the results of the internal calibration analysis performed by the processor. |
|
1 |
|
Radio Frequency Interference mitigation DSR. This DSR contains information on detected RFI and on their mitigation. |
|
1 |
|
Doppler parameters DSR. This DSR contains the Doppler Centroid (DC) and Frequency Modulation rate (FM) parameters estimated and used during processing. |
|
1 |
|
Radiometric calibration DSR. This DSR contains all the necessary information to absolutely calibrate the data pixels. |
|
1 |
|
Polarimetric distortion DSR. This DSR contains the necessary information e.g. receive and transmit polarisation distortion matrix, allowing users to correct for them if not applied at processing level. |
|
1 |
|
Ionosphere correction DSR. This DSR contains the results of the ionosphere correction estimated and applied by the processor. |
|
1 |
geometry |
Geometry DSR. This DSR contains all the necessary information to understand the Earth model/geometry used in the image and its geolocation. |
|
1 |
quality |
Quality DSR. This DSR contains in a single DSR quality flags and thresholds for basic quality assessment done at processing level. |
|
1 |
annotationLUT |
Annotation LUT DSR. This DSR contains the list of Look-Up Tables (LUTs) complementing product main annotations. |
|
1 |
The content of each DSR is described making use of tables as the one here above. All the tables share the same structure and are filled following the same conventions, i.e.:
Name: defines the name of the element or attribute;
Description: describes the purpose of the element or attribute including the units (if applicable). The absence of a unit designation for string data types implies a string literal and for numerical data types (integers, floats, etc…) the absence of a unit designation implies an absolute number;
Data Type: defines the data type of the element or attribute;
Cardinality: for elements, this column defines the number of occurrences of the element in the form
minOccurs..maxOccurs; for attributes, “optional” means the attribute may or may not be present and “required” means the presence of the attribute is mandatory.
In general, elements are displayed in normal font, attributes are displayed in italics.
Data types requiring a dedicated definition table are underlined, for all the others the common reference is sec. 7.1.1.
4.3.1.1 Acquisition information DSR#
This DSR contains information that applies to the entire data set.
Fig. 4 — Acquisition information DSR (acquisitionInformationType)
Table 5 — Acquisition information DSR (acquisitionInformationType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
mission |
Mission (BIOMASS). |
|
1 |
swath |
Swath (S1, S2, S3). |
|
1 |
|
Product type (SCS, DGM). |
|
1 |
|
List of polarisations. |
|
1 |
|
Zero Doppler start time of the image [UTC]. |
|
1 |
|
Zero Doppler stop time of the image [UTC]. |
|
1 |
|
Mission phase identifier (COM, TOM, INT). |
|
1 |
|
True if in drift phase, False otherwise. |
bool |
1 |
|
Sensor mode (Measurement, RX Only, External Calibration). |
|
1 |
|
Global coverage identifier. |
|
1 |
|
Major cycle identifier. |
|
1 |
|
Repeat cycle identifier. |
|
1 |
|
Absolute orbit number at data set start time. |
|
1 |
|
Relative orbit number (track) at data set start time. |
|
1 |
|
Orbit pass (Ascending, Descending). |
|
1 |
|
Platform heading relative to North [deg]. |
|
1 |
|
Data take identifier. |
|
1 |
frame |
Frame identifier. This value is considered unique per beam. In case the product is non-framed, this field is empty. In case the product has been obtained from the merging of two frames, this number corresponds to the longer one. |
|
1 |
|
Product composition indicator, where the valid values are: “Nominal”, to indicate a framed product of nominal length; “Merged”, if the product is resulting from the merging of a “short” frame with the contiguous one; “Partial”, if the product length is not nominal, but it is not merged to a contiguous one since it is “long enough”; “Incomplete”, if the product length is not nominal due to contingency (e.g., data loss); “Not Framed”, if the product is not framed, i.e., as long as input L0 one. |
|
1 |
Table 6 — Acquisition information DSR (polarisationListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
polarisation |
Polarisation (HH, HV, VH, VV). |
|
1 … 4 |
4.3.1.2 SAR image DSR#
This DSR contains all the necessary information to exploit the measurement data set (i.e. SAR images).
Fig. 5 — SAR image DSR (sarImageType)
Table 7 — SAR image DSR (sarImageType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Two-way slant range time to first sample of the image [s]. |
|
1 |
|
Two-way slant range time to last sample of the image [s]. |
|
1 |
|
Zero Doppler azimuth time of the first line of the image [UTC]. |
|
1 |
|
Zero Doppler azimuth time of the last line of the image [UTC]. |
|
1 |
|
Time spacing between range samples of the image [s]. For L1a products, this value is the inverse of the range sampling frequency. For L1b products, this value is obtained dividing |
|
1 |
|
Time spacing between azimuth lines of the image [s]. |
|
1 |
|
Pixel spacing between range samples [m]. |
|
1 |
|
Nominal pixel spacing between azimuth lines [m]. |
|
1 |
|
Total number of samples in the image (image width). |
|
1 |
|
Total number of lines in the image (image length). |
|
1 |
projection |
Projection of the image, either Slant Range or Ground Range. |
|
1 |
|
List of |
|
1 |
datum |
Datum used during processing. |
|
1 |
footprint |
Image footprint, expressed as a list of latitude and longitude values separated by spaces [deg]. Values are specified for each of the 4 corner coordinates of the scene quicklook, starting with the first-right in flight direction and proceeding CCW (same convention used in MPH and overlay ADS). |
|
1 |
|
Representation of the image pixels within the image MDS (I Q, Abs Phase, Abs, Pow Phase, Pow). |
|
1 |
|
Data type of output pixels within the image MDS. |
|
1 |
|
Physical quantity stored in output data (Beta-Nought, Sigma-Nought or Gamma-Nought). |
|
1 |
|
Pixel value in case of invalid data. |
|
1 |
Table 8 — SAR image DSR (coordinateConversionListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of coordinate conversion records within the list. |
|
required |
|
Polynomial used to convert image pixels between slant range and ground range. The coefficients used on range lines between updates are found by linear interpolation between the updated and previous values. Considering the worst case (entire slice processed non-framed, one entry each 10 seconds), list |
|
0 … 15 |
Fig. 6 — SAR image DSR (coordinateConversionType)
Table 9 — SAR image DSR (coordinateConversionType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Zero Doppler azimuth time corresponding to the start of the current polynomial validity area [UTC]. |
|
1 |
t0 |
Two-way slant range time origin for coordinate conversion polynomial [s]. |
|
1 |
sr0 |
Slant range origin used for ground range calculation [m]. |
|
1 |
|
Coefficients to convert from slant range to ground range. |
|
1 |
gr0 |
Ground range origin used for slant range calculation [m]. |
|
1 |
|
Coefficients to convert from ground range to slant range coefficients. |
|
1 |
4.3.1.3 Instrument parameters DSR#
This DSR contains the main instrument settings at the time of imaging.
Fig. 7 — Instrument parameters DSR (instrumentParametersType)
Table 10 — Instrument parameters DSR (instrumentParametersType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Sensing time of first line of the input RAW data for all the polarisations [UTC]. |
|
1 |
|
Sensing time of last line of the input RAW data for all the polarisations [UTC]. |
|
1 |
|
Number of samples of the input RAW data. |
|
1 |
|
Number of lines of the input RAW data. |
|
1 |
|
List of Sampling Window Position changes (SWP) [s]. The list contains an entry for each on-board SWP update. |
|
1 |
|
List of Sampling Window Length changes (SWL) [s]. The list contains an entry for each on-board SWL update. |
|
1 |
|
List of Pulse Repetition Frequency changes (PRF) [Hz]. The list contains an entry for each on-board PRF update. |
|
1 |
rank |
Number of PRIs between transmitted pulse and received echo. |
|
1 |
|
List of transmitted pulses. The list contains an entry for each on-board transmitted pulse update. |
|
1 |
|
Instrument configuration identifier. |
|
1 |
|
Radar carrier frequency [Hz]. |
|
1 |
|
RX gain list. |
|
1 |
|
True if input RAW data contain preamble sequence, False otherwise. |
bool |
1 |
|
True if input RAW data contain postamble sequence, False otherwise. |
bool |
1 |
|
True if input RAW data contain interleaved calibration sequences, False otherwise. |
bool |
1 |
|
Data format for instrument samples. There is one element corresponding to the data format for each packet type in the segment. |
|
1 |
Table 11 — Instrument parameters DSR (firstLineSensingTimeListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Sensing time of first line of the input RAW data for the current polarisation [UTC]. |
|
1 … 4 |
Table 12 — Instrument parameters DSR (lastLineSensingTimeListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Sensing time of last line of the input RAW data for the current polarisation [UTC]. |
|
1 … 4 |
Table 13 — Instrument parameters DSR (swpListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of SWP records within the list. |
|
required |
swp |
SWP record [s]. This record holds the SWP for the given Zero Doppler azimuth time. Considering the worst case (entire slice processed non-framed, one change each 10 seconds), list |
|
1… 15 |
Table 14 — Instrument parameters DSR (swlListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of SWL records within the list. |
|
required |
swl |
SWL record [s]. This record holds the SWL for the given Zero Doppler azimuth time. Considering the worst case (entire slice processed non-framed, one change each 10 seconds), list |
|
1… 15 |
Table 15 — Instrument parameters DSR (prfListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of PRF records within the list. |
|
required |
prf |
PRF record [Hz]. This record holds the PRF for the given Zero Doppler azimuth time. List |
|
1… 5 |
Table 16 — Instrument parameters DSR (txPulseListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of transmitted pulse records within the list. |
|
required |
|
Transmitted pulse record. This record holds the nominal transmitted pulse information for the given Zero Doppler azimuth time. List |
|
1… 5 |
Fig. 8 — Instrument parameters DSR (txPulseType)
Table 17 — Instrument parameters DSR (txPulseType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Zero Doppler azimuth time of transmitted pulse change [UTC]. |
|
1 |
|
Transmit pulse length [s]. |
|
1 |
|
Starting frequency of the transmit pulse [Hz]. |
|
1 |
|
Starting phase of the transmit pulse [rad]. |
|
1 |
|
The linear rate at which the frequency changes over the pulse duration [Hz/s]. |
|
1 |
Fig. 9 — Instrument parameters DSR (rxGainListType)
Table 18 — Instrument parameters DSR (rxGainListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
RX gain, extracted from RAS control message. |
|
2 |
Fig. 10 — Instrument parameters DSR (dataFormatType)
Table 19 — Instrument parameters DSR (dataFormatType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Data format of echo packets. |
|
1 |
|
Data format of calibration packets. |
|
1 |
|
Data format of noise packets. |
|
1 |
|
The calculated mean bit rate for the segment provide as input to the processor [Mbps]. |
|
1 |
4.3.1.4 RAW data analysis DSR#
This DSR contains the main elements related to the RAW data consolidation and analysis performed by the processor.
Fig. 11 — RAW data analysis DSR (rawDataAnalysisType)
Table 20 — RAW data analysis DSR (rawDataAnalysisType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Error counters computed starting from input Instrument Source Packets stream. |
|
1 |
|
Extracted RAW data I and Q channels statistics for all the polarisations. |
|
1 |
|
In/out-of-band power ratio list. This element contains lists of in/out-of-band power ratio measurements. The list contains an entry for each measurement made along azimuth and it is organised per polarisation. |
|
1 |
Fig. 12 — RAW data analysis DSR (errorCountersType)
Table 21 — RAW data analysis DSR (errorCountersType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Total number of errors detected in ISP headers. |
|
1 |
|
Total number of missing ISP. |
|
1 |
Table 22 — RAW data analysis DSR (rawDataStatisticsListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Extracted RAW data I and Q channels statistics for the current polarisation. |
|
1 … 4 |
Fig. 13 — RAW data analysis DSR (rawDataStatisticsType)
Table 23 — RAW data analysis DSR (rawDataStatisticsType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
|
Calculated I bias. |
|
1 |
|
Calculated Q bias. |
|
1 |
|
Calculated I/Q quadrature departure. |
|
1 |
|
Calculated I/Q gain imbalance. |
|
1 |
Table 24 — RAW data analysis DSR (inOutBandPowerRatioListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
In/out-of-band power ratio measurements for the current polarisation. |
|
1 … 4 |
Table 25 — RAW data analysis DSR (powerRatioListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
count |
Number of in/out-of-band power ratio measurements for the current polarisation within the list. |
|
required |
|
In/out-of-band power ratio measurements. Considering the worst case (entire slice processed non-framed, one entry each 5 seconds), list |
|
1 … 30 |
Fig. 14 — RAW data analysis DSR (powerRatioType)
Table 26 — RAW data analysis DSR (powerRatioType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Zero Doppler azimuth time of the in/out-of-band power ratio measurement [UTC]. |
|
1 |
value |
In/out-of-band power ratio measurement. |
|
1 |
4.3.1.5 Processing parameters DSR#
This DSR contains the exhaustive list of static SAR processing parameters and of corrections applied.
Fig. 15 — Processing parameters DSR (processingParametersType)
Table 27 — Processing parameters DSR (processingParametersType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Version of the processor used to generate the product. |
|
1 |
|
Product generation time [UTC]. |
|
1 |
|
Processing mode (Nominal, PARC). |
|
1 |
|
Source of the orbit data used during processing. Set to “Extracted” if the orbit information extracted from source packets is used during processing. Set to “Auxiliary” if the orbit information from an input auxiliary file is used during processing. |
|
1 |
|
Source of the attitude data used during processing. Set to “Extracted” if the attitude information extracted from source packets is used during processing. Set to “Auxiliary” if the attitude information from an input auxiliary file is used during processing. |
|
1 |
|
True if raw data correction was performed, False otherwise. |
bool |
1 |
|
True if RFI detection was performed, False otherwise. |
bool |
1 |
|
True if RFI correction was performed, False otherwise. Implies activation of |
bool |
1 |
|
Domain where the RFI mitigation step was performed (Time, Frequency, Time and Frequency, Frequency and Time). |
|
1 |
|
RFI mask used for mitigation. Valid values are: “Single”, to use the same mask for all the polarizations; “Multiple”, to use a dedicated mask for each polarization. |
|
1 |
|
Polarization-dependent RFI masks combination method (AND, OR). Used only in case |
|
1 |
rfiFMChirpSource |
Chirp source for Frequency Domain detection. |
|
1 |
rfiFMMitigationMethod |
Frequency Domain mitigation method. |
rfiFMMitigationMethodType |
1 |
|
True if internal calibration estimation was performed, False otherwise. |
bool |
1 |
|
True if internal calibration correction was performed, False otherwise. |
bool |
1 |
|
Chirp source to be used for range compression (Nominal, Replica or Internal). |
|
1 |
|
Range compression method used during processing (Matched Filter or Inverse Filter). |
|
1 |
|
True if processing was extended in the range direction including samples not having the full phase history, False otherwise. |
bool |
1 |
|
Doppler Centroid estimation method used during processing (Geometry, Combined, Fixed). |
|
1 |
|
Doppler centroid value used during processing [Hz]. Used only in case |
|
1 |
|
True if antenna pattern correction (first step) was applied, False otherwise. |
bool |
1 |
|
True if antenna pattern correction (second step) was applied, False otherwise. |
bool |
1 |
|
True if antenna cross-talk correction was applied, False otherwise. |
bool |
1 |
|
Parameters used during range processing. |
|
1 |
|
Parameters used during azimuth processing. |
|
1 |
|
True if bistatic delay correction was applied, False otherwise. |
bool |
1 |
|
Method used for bistatic delay correction (Bulk or Full). |
|
1 |
|
True if range spreading loss compensation was performed, False otherwise. |
bool |
1 |
|
Range spreading loss reference slant range [m]. The range spreading loss is compensated by amplitude scaling each range sample by |
|
1 |
|
Processing gain computed and applied multiplicatively to the image during processing for all the polarisations. |
|
1 |
|
True if polarimetric correction has been performed, False otherwise. |
bool |
1 |
|
True if defocusing at ionosphere height has been performed, False otherwise. |
bool |
1 |
|
Ionosphere height estimation method (Automatic, Feature Tracking, Squint Sensitivity, Model, Fixed). |
|
1 |
|
True if Faraday Rotation correction has been performed, False otherwise. |
bool |
1 |
|
True if ionospheric phase screen correction has been performed, False otherwise. |
bool |
1 |
|
True if group delay correction has been performed, False otherwise. |
bool |
1 |
|
True if autofocus has been performed, False otherwise. |
bool |
1 |
|
Autofocus method used during processing (Map Drift). |
|
1 |
|
True if detection has been performed, False otherwise. |
bool |
1 |
|
True if thermal denoising has been performed, False otherwise. |
bool |
1 |
|
Processing gain computed and applied multiplicatively to the thermal noise level before using it during denoising step for all the polarisations. |
|
1 |
|
True if slant range to ground range conversion has been performed, False otherwise. |
bool |
1 |
Fig. 16 — Processing parameters DSR (spectrumProcessingParametersType)
Table 28 — Processing parameters DSR (spectrumProcessingParametersType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Name of the weighting window type used during processing. |
|
1 |
|
Value of the weighting window coefficient used during processing. |
|
1 |
|
Total available bandwidth [Hz]. |
|
1 |
|
Bandwidth used during processing [Hz]. |
|
1 |
|
Bandwidth for each look used during processing [Hz]. |
|
1 |
|
Number of looks. |
|
1 |
|
Overlap between looks [Hz]. |
|
1 |
Table 29 — Processing parameters DSR (processingGainListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Processing gain computed and applied multiplicatively to the image during processing for the current polarisation. |
|
1 … 4 |
Table 30 — Processing parameters DSR (noiseGainListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Processing gain computed and applied multiplicatively to the thermal noise level before using it during denoising step for the current polarisation. |
|
1 … 4 |
4.3.1.6 Internal calibration DSR#
This DSR contains the results of the internal calibration analysis performed by the processor.
Fig. 17 — Internal calibration DSR (internalCalibrationType)
Table 31 — Internal calibration DSR (internalCalibrationType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Internal calibration parameters effectively used during processing (Model or Extracted). |
|
1 |
|
Chirp source effectively used for range compression (Nominal, Replica or Internal). Can be different from |
|
1 |
|
Noise parameters used during processing (Model or Extracted). |
|
1 |
|
Internal calibration parameters list. This element contains lists of internal calibration parameters calculated from the calibration pulses extracted from the downlink. The list contains an entry for each calibration sequence contained in the input data and it is organised per polarisation. If the list is empty, the nominal parameters values in the instrument auxiliary data file will be used instead. |
|
1 |
|
Noise list. This element contains lists of noise parameters derived from the noise ISPs. The list contains an entry for each noise sequence contained in the input data and it is organised per polarisation. If the list is empty, the nominal noise value in the instrument auxiliary data file will be used instead. |
|
1 |
Table 32 — Internal calibration DSR (internalCalibrationParametersListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Internal calibration parameters derived from the calibration pulses for the current polarisation. |
|
1 … 4 |
Table 33 — Internal calibration DSR (internalCalibrationSequenceListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
count |
Number of internal calibration sequences for the current polarisation within the list. |
|
required |
|
Internal calibration parameters derived from the calibration pulses. Considering the worst case (10 minutes datatake, one entry each 10 seconds), list |
|
0 … 60 |
Fig. 18 — Internal calibration DSR (internalCalibrationSequenceType)
Table 34 — Internal calibration DSR (internalCalibrationSequenceType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Zero Doppler azimuth time in azimuth at which internal calibration parameters applies [UTC]. |
|
1 |
|
Amplitude drift for the current power gain product (PGP). |
|
1 |
|
Phase drift for the current power gain product (PGP) [rad]. |
|
1 |
|
Amplitude drift derived from model. |
|
1 |
|
Phase drift derived from model [rad]. |
|
1 |
|
Indicates if the current amplitude and phase drifts are valid (within the configured threshold) when compared to the mean and standard deviation of all the amplitude and phase drifts. |
bool |
1 |
|
Indicates if the current amplitude and phase drifts are valid (within the configured threshold) when compared to the value of the model. |
bool |
1 |
|
3-dB pulse width of chirp replica cross-correlation function between the reconstructed replica and the nominal replica [Hz]. |
|
1 |
|
Peak Side Lobe Ratio (PSLR) of replica cross-correlation function between the reconstructed replica and the nominal replica [dB]. |
|
1 |
|
Integrated Side Lobe Ratio (ISLR) of cross-correlation function between the reconstructed replica and the nominal replica [dB]. |
|
1 |
|
Peak location of cross-correlation function between the reconstructed replica and the nominal replica [samples]. |
|
1 |
|
Indicates if the cross-correlation between the nominal replica and this extracted replica resulted in a valid peak location. |
bool |
1 |
|
Internal time delay [s] representing the calculated deviation of the location of this replica from the location of the transmitted pulse, i.e. the nominal replica. |
|
1 |
|
Amplitude of instrument internal transmit channel imbalance. |
|
1 |
|
Phase of instrument internal transmit channel imbalance [rad]. |
|
1 |
|
Amplitude of instrument internal receive channel imbalance. |
|
1 |
|
Phase of instrument internal receive channel imbalance [rad]. |
|
1 |
|
Amplitude of transmit power tracking for doublet D1. |
|
1 |
|
Phase of transmit power tracking for doublet D1 [rad]. |
|
1 |
|
Amplitude of receive power tracking for doublet D1. |
|
1 |
|
Phase of receive power tracking for doublet D1 [rad]. |
|
1 |
|
Amplitude of transmit power tracking for doublet D2. |
|
1 |
|
Phase of transmit power tracking for doublet D2 [rad]. |
|
1 |
|
Amplitude of receive power tracking for doublet D2. |
|
1 |
|
Phase of receive power tracking for doublet D2 [rad]. |
|
1 |
Table 35 — Internal calibration DSR (noiseListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Noise parameters derived from the noise packets for the current polarisation. |
|
1 … 4 |
Table 36 — Internal calibration DSR (noiseSequenceListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
count |
Number of noise sequences for the current polarisation within the list. |
|
required |
|
Noise parameters derived from noise packets. List |
|
0 … 2 |
Fig. 19 — Internal calibration DSR (noiseSequenceType)
Table 37 — Internal calibration DSR (noiseSequenceType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Zero Doppler azimuth time of the noise measurement [UTC]. |
|
1 |
|
Noise power correction factor. |
|
1 |
|
Number of noise lines used to calculate noise correction factor. |
|
1 |
4.3.1.7 Radio Frequency Interference mitigation DSR#
This DSR contains information on detected RFI and on their mitigation.
Fig. 20 — Radio Frequency Interference mitigation DSR (rfiMitigationType)
Table 38 — Radio Frequency Interference mitigation DSR (rfiMitigationType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
rfiTMReportList |
Time-domain RFI mitigation report list. This element is present only if time-domain RFI mitigation is performed. |
rfiTMReportListType |
0 … 1 |
|
Frequency-domain isolated RFI mitigation report list. This element is present only if frequency-domain RFI mitigation is performed. |
|
0 … 1 |
|
Frequency-domain persistent RFI mitigation report list. This element is present only if frequency-domain RFI mitigation is performed. |
|
0 … 1 |
Table 39 — Radio Frequency Interference mitigation DSR (rfiTMReportListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
rfiTMReport |
Time-domain RFI mitigation report. |
rfiTMReportType |
1 … 4 |
Fig. 21 — Radio Frequency Interference mitigation DSR (rfiTMReportType)
Table 40 — Radio Frequency Interference mitigation DSR (rfiTMReportType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
|
Percentage of input RAW data lines affected by RFI. |
|
1 |
|
Average percentage of affected input RAW data samples in the lines containing RFI. |
|
1 |
|
Maximum percentage of input RAW data samples affected by RFI in the same line. |
|
1 |
Table 41 — Radio Frequency Interference mitigation DSR (rfiIsolatedFMReportListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Frequency-domain isolated RFI mitigation report. |
|
1 … 4 |
Fig. 22 — Radio Frequency Interference mitigation DSR (rfiIsolatedFMReportType)
Table 42 — Radio Frequency Interference mitigation DSR (rfiIsolatedFMReportType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
|
Percentage of input RAW data lines affected by isolated RFI. |
|
1 |
|
Max percentage of bandwidth affected by isolated RFI in a single line. |
|
1 |
|
Average percentage of bandwidth affected by isolated RFI |
|
1 |
Table 43 — Radio Frequency Interference mitigation DSR (rfiPersistentFMReportListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Frequency-domain persistent RFI mitigation report. |
|
1 … 4 |
Fig. 23 — Radio Frequency Interference mitigation DSR (rfiPersistentFMReportType)
Table 44 — Radio Frequency Interference mitigation DSR (rfiPersistentFMReportType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
|
Max percentage of bandwidth affected by persistent RFI. |
|
1 |
|
Average percentage of bandwidth affected by persistent RFI. |
|
1 |
|
Percentage of lines affected by persistent RFI. |
|
1 |
4.3.1.8 Doppler parameters DSR#
This DSR contains the Doppler Centroid (DC) and Frequency Modulation rate (FM) parameters estimated and used during processing.
Fig. 24 — Doppler parameters DSR (dopplerParametersType)
Table 45 — Doppler parameters DSR (dopplerParametersType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
List of Doppler Centroid estimates that have been calculated during image processing. The list contains an entry for each Doppler Centroid estimate made along azimuth, i.e., each N seconds, where N is configurable. |
|
1 |
|
List of Frequency Modulation rate estimates that have been calculated during image processing. The list contains an entry for each Frequency Modulation rate estimate made along azimuth, i.e., each N seconds, where N is configurable. |
|
1 |
Table 46 — Doppler parameters DSR (dcEstimateListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of |
|
required |
|
Doppler Centroid estimate record which contains the Doppler Centroid calculated from geometry and estimated from the data, associated signal-to-noise ratio values and indicates which DCE method was used by the IPF during image processing. Considering the worst case (entire slice processed non-framed, one entry each 1 second), list |
|
1… 150 |
Fig. 25 — Doppler parameters DSR (dcEstimateType)
Table 47 — Doppler parameters DSR (dcEstimateType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Zero Doppler azimuth time corresponding to the start of the current polynomial validity area [UTC]. |
|
1 |
t0 |
Two-way slant range time origin for polynomial [s]. |
|
1 |
geometryDCPolynomial |
Doppler Centroid estimated from orbit and attitude, expressed as the following polynomial (assuming 5 coefficients): |
|
1 |
combinedDCPolynomial |
Doppler Centroid estimated from both orbit and attitude and data, expressed as the following polynomial (assuming 5 coefficients): |
|
1 |
combinedDCValues |
Combined Doppler Centroid estimates [Hz]. Each estimate represents the Doppler Centroid frequency at the slant range time specified by combinedDCSlantRangeTimes, estimated within the current block. The values are averaged on all the polarisations used for estimation. |
|
1 |
combinedDCSlantRangeTimes |
Two-way slant range times combinedDCValues are referred to [s]. |
|
1 |
combinedDCRMSError |
The RMS error of the Doppler Centroid estimate [Hz]. It is calculated as the average of the individual RMS residual errors between input fine Doppler Centroid estimates and the fitted polynomial. If the Doppler Centroid was not estimated with combined approach, this is set to 0. |
|
1 |
combinedDCRMSErrorAboveThreshold |
False if the RMS error is below the acceptable threshold for the Doppler Centroid estimated with combined approach. True if the RMS error is greater than or equal to the acceptable threshold. |
bool |
1 |
Table 48 — Doppler parameters DSR (fmRateEstimatesListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of |
|
required |
|
Frequency Modulation rate estimate record. Considering the worst case (entire slice processed non-framed, one entry each 1 second), list |
|
1… 150 |
4.3.1.9 Radiometric calibration DSR#
This DSR contains all the necessary information to absolutely calibrate the data pixels.
Fig. 26 — Radiometric calibration DSR (radiometricCalibrationType)
Table 49 — Radiometric calibration DSR (radiometricCalibrationType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Absolute calibration constant. Already applied to the image during processing for all the polarisations. |
|
1 |
Table 50 — Radiometric calibration DSR (calibrationConstantListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Absolute calibration constant applied multiplicatively to the image during processing for the current polarisation. |
|
1 … 4 |
4.3.1.10 Polarimetric distortion DSR#
This DSR contains the necessary information e.g. receive and transmit polarisation distortion matrix, allowing users to correct for them if not applied at processing level.
Fig. 27 — Polarimetric distortion DSR (polarimetricDistortionType)
Table 51 — Polarimetric distortion DSR (polarimetricDistortionType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
System cross-talk values. |
|
1 |
|
System channel imbalance values. |
|
1 |
Table 52 — Polarimetric distortion DSR (crossTalkList)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
H to V system cross-talk on transmit values, \(\delta_4\). |
complex |
1 |
|
V to H system cross-talk on transmit values, \(\delta_3\). |
complex |
1 |
|
H to V system cross-talk on receive values, \(\delta_1\). |
complex |
1 |
|
V to H system cross-talk on receive values, \(\delta_2\). |
complex |
1 |
Table 53 — Polarimetric distortion DSR (channelImbalanceList)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
H to V system channel imbalance on transmit values, \(f_2\). |
complex |
1 |
|
H to V system channel imbalance on receive values, \(f_1\). |
complex |
1 |
4.3.1.11 Ionosphere correction DSR#
This DSR contains the results of the ionosphere correction estimated and applied by the processor.
Fig. 28 — Ionosphere correction DSR (ionosphereCorrectionType)
Table 54 — Ionosphere correction DSR (ionosphereCorrectionType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Ionosphere height used for processing [m] (-1 if not available). |
|
1 |
|
Ionosphere height estimated using Feature Tracking or Squint Sensitivity method, if selected via configuration [m] (-1 if not available). |
|
1 |
|
Ionosphere height estimation method selected for ionospheric processing, between Feature Tracking and Squint Sensitivity, when |
|
1 |
|
Latitude value used to select ionosphere height estimation method between Feature Tracking and Squint Sensitivity, when |
|
1 |
|
True if ionosphere height estimation is completed successfully, False otherwise. |
bool |
1 |
|
|
|
1 |
|
True if computed filter dimensions are below maximum allowed values, False otherwise. |
bool |
1 |
|
Flag indicating if Faraday Rotation correction has been effectively applied or not. Can be different from |
bool |
1 |
|
Flag indicating if correction of azimuth shift estimated through autofocus has been effectively applied or not. Can be different from |
bool |
1 |
4.3.1.12 Geometry DSR#
This DSR contains all the necessary information to understand the Earth model/geometry used in the image and its geolocation.
Fig. 29 — Geometry DSR (geometryType)
Table 55 — Geometry DSR (geometryType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Digital Elevation Model (DEM) commanded for usage during processing (with version as attribute). |
|
1 |
|
True if the DEM effectively used during processing is the commanded one reported in |
bool |
1 |
|
Bias added to roll estimated from attitude to offset it [deg]. |
|
1 |
4.3.1.13 Quality DSR#
This DSR contains in a single DSR quality flags and thresholds for basic quality assessment done at processing level.
Fig. 30 — Quality DSR (qualityType)
Table 56 — Quality DSR (qualityType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Overall product quality index. This annotation is calculated based on specific quality parameters and gives an overall quality value to the product. |
|
1 |
|
Quality parameters list. The list contains an entry for each polarisation. |
|
1 |
Table 57 — Quality DSR (qualityParametersListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
|
required |
|
|
Quality parameters for the current polarisation. |
|
1 … 4 |
Fig. 31 — Quality DSR (qualityParametersType)
Table 58 — Quality DSR (qualityParametersType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
polarisation |
|
required |
|
missingISPFraction |
Number of missing ISP, expressed as a normalized fraction of the total number of ISP. |
|
1 |
maxISPGap |
Maximum number of gaps between science data ISPs. |
|
1 |
maxISPGapThreshold |
Threshold on maxISPGap. If maxISPGap exceeds this parameter, the processing will not continue. |
|
1 |
|
Number of invalid raw data samples (according to their mean and standard deviation), expressed as a normalized fraction of the total number of samples. |
|
1 |
|
This parameter specifies the expected mean of the samples in the extracted raw data. |
|
1 |
|
This is the value X such that the measured mean must fall between the |
|
1 |
|
This parameter specifies the expected standard deviation of the samples in the extracted raw data. |
|
1 |
|
This is the value X such that the measured standard deviation must fall between the |
|
1 |
rfiTMFraction |
Normalized fraction of image pixels impacted by time-domain RFI. |
|
1 |
maxRFITMPercentage |
Maximum normalized percentage of image pixels impacted by time-domain RFI. If the percentage exceeds this parameter, the processing will not continue. |
|
1 |
rfiFMFraction |
Normalized fraction of image spectrum impacted by frequency-domain RFI. |
|
1 |
maxRFIFMPercentage |
Maximum normalized percentage of image spectrum impacted by frequency-domain RFI. If the percentage exceeds this parameter, the processing will not continue. |
|
1 |
|
Number of invalid drift values, expressed as a normalized fraction of the total number of drifts. |
|
1 |
|
Maximum number of invalid drift values allowed, expressed as a normalized fraction of the total number of drifts. If the percentage of the invalid drifts does not exceed this value, then the invalid drifts will be discarded and only the valid ones will be further used in the processing. Otherwise, all the calculated drift values will be discarded and replaced with the corresponding model values. |
|
1 |
|
Number of invalid replicas, expressed as a normalized fraction of the total number of replicas extracted. |
|
1 |
invalidDCEstimatesFraction |
Number of invalid DC estimated, expressed as a normalized fraction of the total number of DC estimates. |
|
1 |
dcRMSErrorThreshold |
Doppler Centroid estimation root mean squared (RMS) error threshold [Hz]. If the RMS error of the Doppler Centroid combined estimates is above this threshold they are not used during processing; instead, the Doppler Centroid calculated from geometry is used. |
|
1 |
|
Quality measure of the ionospheric phase estimated by Faraday Rotation, expressed as standard deviation of the residual ionospheric phase screen [rad]. |
|
1 |
|
Normalized fraction of image blocks that need to have estimated an azimuth shift higher than the maximum allowed one, used to consider an autofocus estimation valid or not. |
|
1 |
|
Minimum normalized percentage of blocks within the image that need to have estimated an azimuth shift smaller than the |
|
1 |
4.3.1.13.1 Overall Product Quality Index#
As mentioned in Tab. 54, the overallProductQualityIndex is an unsigned integer value (i.e. a 32-bit integer ranging from 0 to 232 – 1) that summarizes the execution history of the L1 Processor. The L1’s overallProductQualityIndex is the decimal representation of a 32-bit array that is defined as follows:
Bit # |
Module/Sub-step |
Bit-Flipping Condition |
|---|---|---|
0 |
Input products and auxiliary files ingestion |
- Intentionally left blank, i.e. 0 - |
1 |
- Intentionally left blank, i.e. 0 - |
|
2 |
- Intentionally left blank, i.e. 0 - |
|
3 |
- Intentionally left blank, i.e. 0 - |
|
4 |
RAW data analysis |
RAW data statistics out of boundaries (set to 1 if |
5 |
- Intentionally left blank, i.e. 0 - |
|
6 |
- Intentionally left blank, i.e. 0 - |
|
7 |
- Intentionally left blank, i.e. 0 - |
|
8 |
Internal calibration |
Invalid calibration sequences above threshold (set to 1 if |
9 |
- Intentionally left blank, i.e. 0 - |
|
10 |
- Intentionally left blank, i.e. 0 - |
|
11 |
- Intentionally left blank, i.e. 0 - |
|
12 |
RFI mitigation |
- Intentionally left blank, i.e. 0 - |
13 |
- Intentionally left blank, i.e. 0 - |
|
14 |
- Intentionally left blank, i.e. 0 - |
|
15 |
- Intentionally left blank, i.e. 0 - |
|
16 |
Doppler Centroid estimation |
Doppler Centroid estimation fallback from Combined method to Geometry method activated (set to 1 if activated, otherwise set to 0) |
17 |
Doppler Centroid estimation root mean squared (RMS) error above threshold (set to 1 if invalidDCEstimatesFraction>0, otherwise set to 0) |
|
18 |
- Intentionally left blank, i.e. 0 - |
|
19 |
- Intentionally left blank, i.e. 0 - |
|
20 |
Range and azimuth compression |
- Intentionally left blank, i.e. 0 - |
21 |
- Intentionally left blank, i.e. 0 - |
|
22 |
- Intentionally left blank, i.e. 0 - |
|
23 |
- Intentionally left blank, i.e. 0 - |
|
24 |
Polarimetric and ionospheric corrections |
Ionosphere height estimation failing (set to 1 if |
25 |
IRI model used (set to 1 if IRI model is used as fallback solution, due to failure of ionosphere height estimation, or set to 0 if it is used on purpose or not used) |
|
26 |
Gaussian filter size out of boundaries (set to 1 if |
|
27 |
Inconsistent |
|
28 |
Geomagnetic equator crossing fallback activated, i.e., phase screen and group delay corrections not applied (set to 1 if activated, otherwise set to 0) |
|
29 |
- Intentionally left blank, i.e. 0 - |
|
30 |
Autofocus |
Number of failing estimations above threshold (set to 1 if |
31 |
- Intentionally left blank, i.e. 0 - |
Note that some bits are intentionally left blank to support user-defined custom information. The quality index bits aim at providing the user with hints for tracing possible problems in case of failures in the processing.
4.3.1.14 Annotation LUT DSR#
This DSR contains the list of Look-Up Tables (LUTs) complementing product main annotations.
Fig. 32 — Annotation LUT DSR (layerListType)
Table 59 — Annotation LUT DSR (layerListType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
count |
Number of layers. |
|
required |
layer |
LUT layer content. |
|
1 … 30 |
4.3.2 Look-Up Tables (LUT) ADS#
This section describes in details the content of Look-Up Tables (LUT) ADS.
This ADS complements the Main ADS one, including all those annotations that can be represented as 2D maps of values. This approach has been chosen in order to avoid worsening the Main ADS readability and handling, and also to provide an easier access to such information.
The name (LUT ADS) comes from the fact that this ADS contains a set of components, each of which:
is defined over a sampling grid which is a sub-sampled version of the grid over which the SAR image MDS is defined;
provides additional details about the domain over which the SAR image MDS is defined (latitude/longitude/height maps, …), or
provides layers of correction that have been already applied to the SAR image MDS during L1 processing (RFI mitigation masks, …) or that can be applied directly by the user on L1 data (denoising maps, …).
The format adopted for LUT ADS is NetCDF one [RD6]. Thanks to the flexibility provided by this format, all the components of this ADS are stored in the same file. In this way, considering that some layers are dedicated to geocoding information (latitude/longitude/height maps), it will be possible to directly place all the other maps on a geographical grid.
The LUT ADS file is organised as follows:
a series of root level attributes, containing all those global attributes referring to the file as a whole;
a dimensions group, where names and lengths of the dimensions used when creating data arrays (variables) are defined;
a series of coordinate variables, containing special variables to store the axes data values for each dimension in the dimensions group;
a series of components, each one composed by a group of variables which can be divided in:
the data arrays, storing the annotation Look-Up Tables themselves. A variable represents an array of values of the same data type and it is defined over two or more dimensions from the dimensions group;
ancillary scalar variables containing other useful metadata to complete the data definition.
Note that the LUT are defined over different sampling grids, depending on their specific definition, on the point in the processing chain where they have been computed (e.g., RFI masks are defined over a sub-sampled version of the RAW data sampling grid) and on the configured decimation factors.
Compression strategy
The NetCDF file used for LUT ADS will be in general a compressed one.
It must be noticed that considering that (see also sec. 4.3.2.3):
a L1a frame is a raster of 1500x30000 pixels (range x azimuth, worst-case in terms of data size);
the decimation ratio for a LUT is of a factor 20x120, except for geometry-based LUT for which a factor 2x12 is used;
Note
Factor 2x12 allows to get a sampling close to DEM posting, i.e., ~90m for Copernicus DEM;
LUT are typically (except
rfiTimeMask*,rfiFreqMask*, latitude, longitude and height ones) stored using float precision;the LUT ADS contains a maximum of 30 components;
the LUT ADS will have a size <80MB.
In order to reduce this size, a compression is applied. In particular, a zlib (LSD=None) compression is used with compression level equals 2. This level combines good compression (~2x) with a small increase in compression/decompression time.
4.3.2.1 Attributes#
The attributes contain the same list of parameters described in sec. 4.3.1.1 for the Acquisition information DSR. For all the details about these parameters refer to this section.
In addition, those included in the following table are added.
Table 60 — LUT ADS additional attributes
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Pixel value in case of LUT invalid data. Used for Boolean LUT (RFI masks). |
bool |
1 |
|
Pixel value in case of LUT invalid data. Used for float and double LUT. |
float |
1 |
|
Reference azimuth time to be used together with LUT relative azimuth time axes [UTC]. |
|
1 |
4.3.2.2 Dimensions / Coordinate variables#
The table below describes the dimensions and coordinate variables.
Table 61 — LUT ADS dimensions and coordinate variables
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
|
Slant range time axis for LUT defined on RAW data sampling grid [s]. |
float |
1 |
|
Range frequency axis for LUT defined on RAW data sampling grid [Hz]. |
float |
1 |
|
Azimuth relative time axis for LUT defined on RAW data sampling grid [s]. Reference is |
float |
1 |
|
Slant range time axis for LUT defined on range compressed data sampling grid [s]. |
double |
1 |
|
Azimuth relative time axis for LUT defined on range compressed data sampling grid [s]. Reference is |
double |
1 |
|
Slant range time axis for LUT defined on azimuth compressed data sampling grid [s]. |
float |
1 |
|
Azimuth relative time axis for LUT defined on azimuth compressed data sampling grid [s]. Reference is |
float |
1 |
4.3.2.3 Groups of variables#
The table below describes the groups of variables. It shall be kept into account that the list of variables present in a given product can be just a subset of this one, depending on the configuration of L1 processing chain generating it (e.g., if the RFI mitigation step is deactivated, the rfiTimeMask* and the rfiFreqMask* variables won’t be present in the LUT ADS).
Table 62 — LUT ADS groups of variables
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
group: |
Two-dimensional masks covering the whole SAR image and describing the areas where RFI time-domain mitigation has been applied (ones) or not (zeros) during L1 processing. One mask per polarisation is foreseen (by default, 4 in total). |
matrix (bool) |
4 (only if RFI mitigation step is activated) |
group: |
Two-dimensional masks covering the whole SAR image and describing the areas where RFI frequency-domain mitigation has been applied (ones) or not (zeros) during L1 processing. One mask per polarisation is foreseen (by default, 4 in total). |
matrix (bool) |
4 (only if RFI mitigation step is activated) |
group: radiometry variable: |
Two-dimensional map covering the whole SAR image and describing the conversion factor to translate the beta-nought values into sigma-nought ones. The conversion shall be performed in the following way:\(\sigma^0=\beta^0\bullet\sigma_{LUT}^0\)where:\(\beta^0\) are the values stored in the SAR image MDS (amplitudes) squared;\(\sigma_{LUT}^0\) is this LUT (amplitudes) squared;\(\sigma^0\) are the sigma-nought values after the conversion. Being this LUT defined over a sub-sampled grid with respect to the SAR image, a bilinear interpolation of the LUT is required before its application on the data. |
matrix (float) |
1 |
group: radiometry variable: |
As the sigma-nought map, but to translate the beta-nought values into gamma-nought ones. |
matrix (float) |
1 |
group: |
Two-dimensional map covering the whole SAR image and describing the Faraday Rotation plane computed during L1 ionospheric processing. Values are expressed in [rad]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the Faraday Rotation (final one, including plane) computed during L1 ionospheric processing. Values are expressed in [rad]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the Faraday Rotation expected standard deviation. Values are expressed in [rad]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the phase screen computed during L1 ionospheric processing. Values are expressed in [rad]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the TEC map computed during L1 ionospheric processing. Values are expressed in [TECU]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the range shifts computed during L1 ionospheric processing. Values are expressed in [m]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the azimuth shifts computed during L1 ionospheric processing. Values are expressed in [m]. |
matrix (float) |
1 (only if ionospheric correction step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the autofocus phase screen computed during L1 ionospheric processing. Values are expressed in [rad]. |
matrix (float) |
1 (only if autofocus step is activated) |
group: |
Two-dimensional map covering the whole SAR image and describing the autofocus phase screen standard deviation based on the WLS double integration. Values are expressed in [rad]. |
matrix (float) |
1 (only if autofocus step is activated) |
group: denoising variables: denoisingHH, denoisingHV, denoisingVH, denoisingVV |
Two-dimensional maps covering the whole SAR image and describing the conversion factor to translate the SAR image values into denoised values. Note that, depending on the quantity the denoising shall be applied to (beta/sigma/gamma-nought), the denoising map shall be previously converted to the same quantity. This can be done applying the conversion above described for the sigma-nought map, considering that denoising map values are to be interpreted as powers instead of amplitudes. The denoising operation shall be performed in the following way (assuming sigma-nought quantity is used):\(\widetilde{\sigma^0}=\sigma^0-\sigma_{LUT}^{noise}\)where:\(\sigma^0\) are the values stored in the SAR image MDS squared and converted into sigma-nought through the dedicated LUT;\(\sigma_{LUT}^{noise}\) is this LUT;\(\widetilde{\sigma^0}\) are the sigma-nought powers after the conversion. Being this LUT defined over a sub-sampled grid with respect to the SAR image, a bilinear interpolation of the LUT is required before its application on the data. One mask per polarisation is foreseen (by default, 4 in total). |
matrix (float) |
4 |
group: geometry variable: latitude |
Two-dimensional map covering the whole SAR image and describing the latitude coordinates of each (sub-sampled) pixel. Values are expressed in [deg]. |
matrix (double) |
1 |
group: geometry variable: longitude |
Two-dimensional map covering the whole SAR image and describing the longitude coordinates of each (sub-sampled) pixel. Values are expressed in [deg]. |
matrix (double) |
1 |
group: geometry variable: height |
Two-dimensional map covering the whole SAR image and describing the height coordinates of each (sub-sampled) pixel, derived from the Digital Elevation Model (DEM) used during processing. Values are expressed in [m], with the same reference of the used DEM. |
matrix (double) |
1 |
group: geometry variable: |
Two-dimensional map covering the whole SAR image and describing the incidence angle of each (sub-sampled) pixel. Values are computed during L1 processing considering an average height. Values are expressed in [deg]. |
matrix (float) |
1 |
group: geometry variable: |
Two-dimensional map covering the whole SAR image and describing the elevation angle of each (sub-sampled) pixel. Values are computed during L1 processing considering an average height. Values are expressed in [deg]. |
matrix (float) |
1 |
group: geometry variable: |
Two-dimensional map covering the whole SAR image and describing the local terrain slopes along range direction computed using the Digital Elevation Model (DEM). Values are expressed in [deg]. |
matrix (float) |
1 |
group: geometry variable: |
Two-dimensional map covering the whole SAR image and describing the local terrain slopes along azimuth direction computed using the Digital Elevation Model (DEM). Values are expressed in [deg]. |
matrix (float) |
1 |
As mentioned above, LUT are defined over different sampling grids.
By default, these sampling grids are set to have a ground resolution of 1x1km (range x azimuth), except for geometry-based LUTs for which a resolution close to DEM one is kept, i.e., 90x90m. This means that the default down-sampling factors with respect to SAR image MDS sampling grid are:
20x120 for L1a products (2x12 for geometry-based LUTs);
20x20 for L1b products (2x2 for geometry-based LUTs).
These parameters are configurable.
Here below a sample LUT ADS is reported (obtained with ncdump command).
netcdf bio_s2_scs__1s_20170111t050609_20170111t050630_i_g03_m03_c03_t010_f001_lut {
dimensions:
slantRangeTimeRAW = 87 ;
relativeAzimuthTimeRAW = 322 ;
rangeFreqRAW = 87 ;
slantRangeTimeRGC = 72 ;
relativeAzimuthTimeRGC = 214 ;
slantRangeTimeSLC = 69 ;
relativeAzimuthTimeSLC = 180 ;
variables:
float slantRangeTimeRAW(slantRangeTimeRAW) ;
slantRangeTimeRAW:units = “s” ;
float relativeAzimuthTimeRAW(relativeAzimuthTimeRAW) ;
relativeAzimuthTimeRAW:units = “s” ;
float rangeFreqRAW(rangeFreqRAW) ;
rangeFreqRAW:units = “Hz” ;
double slantRangeTimeRGC(slantRangeTimeRGC) ;
slantRangeTimeRGC:units = “s” ;
double relativeAzimuthTimeRGC(relativeAzimuthTimeRGC) ;
relativeAzimuthTimeRGC:units = “s” ;
float slantRangeTimeSLC(slantRangeTimeSLC) ;
slantRangeTimeSLC:units = “s” ;
float relativeAzimuthTimeSLC(relativeAzimuthTimeSLC) ;
relativeAzimuthTimeSLC:units = “s” ;
// global attributes:
:mission = “BIOMASS” ;
:swath = “S2” ;
:productType = “SCS” ;
string :polarisationList = “H/H”, “H/V”, “V/H”, “V/V” ;
:startTime = “2017-01-11T05:06:09.332291” ;
:stopTime = “2017-01-11T05:06:30.423772” ;
:missionPhaseID = “INT” ;
:driftPhaseFlag = “False” ;
:sensorMode = “Measurement” ;
:globalCoverageID = 3US ;
:majorCycleID = 3US ;
:repeatCycleID = 3US ;
:absoluteOrbitNumber = 10US ;
:relativeOrbitNumber = 10US ;
:orbitPass = “Ascending” ;
:platformHeading = 0. ;
:dataTakeID = 1234US ;
:frame = 1US ;
:productComposition = “Nominal” ;
:noDataValueBool = “False” ;
:noDataValueFloat = -9999. ;
:referenceAzimuthTime = “2017-01-11T05:06:09.332291” ;
:_NCProperties = “version=2,netcdf=4.9.0,hdf5=1.12.2” ;
group: rfiMitigation {
variables:
ubyte rfiTimeMaskHH(relativeAzimuthTimeRAW, slantRangeTimeRAW) ;
rfiTimeMaskHH:_FillValue = 0UB ;
rfiTimeMaskHH:description = “RFI Time Domain Mask H/H” ;
ubyte rfiTimeMaskHV(relativeAzimuthTimeRAW, slantRangeTimeRAW) ;
rfiTimeMaskHV:_FillValue = 0UB ;
rfiTimeMaskHV:description = “RFI Time Domain Mask H/V” ;
ubyte rfiTimeMaskVH(relativeAzimuthTimeRAW, slantRangeTimeRAW) ;
rfiTimeMaskVH:_FillValue = 0UB ;
rfiTimeMaskVH:description = “RFI Time Domain Mask V/H” ;
ubyte rfiTimeMaskVV(relativeAzimuthTimeRAW, slantRangeTimeRAW) ;
rfiTimeMaskVV:_FillValue = 0UB ;
rfiTimeMaskVV:description = “RFI Time Domain Mask V/V” ;
ubyte rfiFreqMaskHH(relativeAzimuthTimeRAW, rangeFreqRAW) ;
rfiFreqMaskHH:_FillValue = 0UB ;
rfiFreqMaskHH:description = “RFI Frequency Domain Mask H/H” ;
ubyte rfiFreqMaskHV(relativeAzimuthTimeRAW, rangeFreqRAW) ;
rfiFreqMaskHV:_FillValue = 0UB ;
rfiFreqMaskHV:description = “RFI Frequency Domain Mask H/V” ;
ubyte rfiFreqMaskVH(relativeAzimuthTimeRAW, rangeFreqRAW) ;
rfiFreqMaskVH:_FillValue = 0UB ;
rfiFreqMaskVH:description = “RFI Frequency Domain Mask V/H” ;
ubyte rfiFreqMaskVV(relativeAzimuthTimeRAW, rangeFreqRAW) ;
rfiFreqMaskVV:_FillValue = 0UB ;
rfiFreqMaskVV:description = “RFI Frequency Domain Mask V/V” ;
} // group rfiMitigation
group: ionosphereCorrection {
variables:
float phaseScreen(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
phaseScreen:_FillValue = -9999.f ;
phaseScreen:description = “Phase Screen (Bickel & Bates)” ;
phaseScreen:units = “rad” ;
float faradayRotationPlane(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
faradayRotationPlane:_FillValue = -9999.f ;
faradayRotationPlane:description = “Faraday Rotation Plane” ;
faradayRotationPlane:units = “rad” ;
float faradayRotation(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
faradayRotation:_FillValue = -9999.f ;
faradayRotation:description = “Faraday Rotation” ;
faradayRotation:units = “rad” ;
float faradayRotationStd(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
faradayRotationStd:_FillValue = -9999.f ;
faradayRotationStd:description = “Faraday Rotation Std” ;
faradayRotationStd:units = “rad” ;
float tec(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
tec:_FillValue = -9999.f ;
tec:description = “TEC” ;
tec:units = “TECU” ;
float rangeShifts(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
rangeShifts:_FillValue = -9999.f ;
rangeShifts:description = “Range Shifts” ;
rangeShifts:units = “m” ;
float azimuthShifts(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
azimuthShifts:_FillValue = -9999.f ;
azimuthShifts:description = “Azimuth Shifts” ;
azimuthShifts:units = “m” ;
float autofocusPhaseScreen(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
autofocusPhaseScreen:_FillValue = -9999.f ;
autofocusPhaseScreen:description = “Phase Screen (Autofocus)” ;
autofocusPhaseScreen:units = “rad” ;
float autofocusPhaseScreenStd(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
autofocusPhaseScreenStd:_FillValue = -9999.f ;
autofocusPhaseScreenStd:description = “Phase Screen Std (Autofocus)” ;
autofocusPhaseScreenStd:units = “rad” ;
} // group ionosphereCorrection
group: denoising {
variables:
float denoisingHH(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
denoisingHH:_FillValue = -9999.f ;
denoisingHH:description = “Denoising H/H” ;
float denoisingHV(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
denoisingHV:_FillValue = -9999.f ;
denoisingHV:description = “Denoising H/V” ;
float denoisingVH(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
denoisingVH:_FillValue = -9999.f ;
denoisingVH:description = “Denoising V/H” ;
float denoisingVV(relativeAzimuthTimeSLC, slantRangeTimeSLC) ;
denoisingVV:_FillValue = -9999.f ;
denoisingVV:description = “Denoising V/V” ;
} // group denoising
group: geometry {
variables:
double latitude(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
latitude:_FillValue = -9999. ;
latitude:description = “Latitude” ;
latitude:units = “deg” ;
double longitude(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
longitude:_FillValue = -9999. ;
longitude:description = “Longitude” ;
longitude:units = “deg” ;
double height(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
height:_FillValue = -9999. ;
height:description = “Height” ;
height:units = “m” ;
float incidenceAngle(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
incidenceAngle:_FillValue = -9999.f ;
incidenceAngle:description = “Incidence Angle” ;
incidenceAngle:units = “deg” ;
float elevationAngle(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
elevationAngle:_FillValue = -9999.f ;
elevationAngle:description = “Elevation Angle” ;
elevationAngle:units = “deg” ;
float rangeTerrainSlope(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
rangeTerrainSlope:_FillValue = -9999.f ;
rangeTerrainSlope:description = “Range Terrain Slope” ;
float azimuthTerrainSlope(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
azimuthTerrainSlope:_FillValue = -9999.f ;
azimuthTerrainSlope:description = “Azimuth Terrain Slope” ;
} // group geometry
group: radiometry {
variables:
float sigmaNought(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
sigmaNought:_FillValue = -9999.f ;
sigmaNought:description = “Sigma Nought” ;
float gammaNought(relativeAzimuthTimeRGC, slantRangeTimeRGC) ;
gammaNought:_FillValue = -9999.f ;
gammaNought:description = “Gamma Nought” ;
} // group radiometry
}
4.3.3 Orbit and attitude ADS#
The Orbit and Attitude ADS will be included as dedicated files in L1a/b products.
Their format is the EO Mission CFI SW Format Specification, as mentioned in [AD4] and described in [AD5]. This is the same format of the auxiliary orbit and attitude files taken input by the L1 processor. For what concern their content, in principle it will be the same too, unless the L1 processor performs any interpolation, extrapolation, … operation. In this case the modified orbit and attitude information are annotated in these two ADS.
4.3.4 Quick-look ADS#
The Quick-look ADS is a lower resolution version of the SAR image MDS. It is stored in PNG file format and it is always included with any BIOMASS L1 product.
The following rules and properties apply to Quick-look ADS:
for L1a products, quick-looks are a power detected, averaged and decimated version of the full SAR image;
for L1b products, quick-looks are a squared averaged and decimated version of the full SAR image.
BIOMASS products can contain one or two quick-look images, depending on the product type and on the selected colour coding method, which are a combination of the imagery from all the four polarisation channels. This is done exploiting the three Red-Green-Blue (RGB) channels of the PNG image and the Pauli decomposition colour coding scheme, i.e.:
Red channel: \(\left\vert HH-VV \right\vert\) (double bounce);
Green channel: \(\left\vert HV+VH \right\vert\) (volume scattering);
Blue channel: \(\left\vert HH+VV \right\vert\) (surface scattering).
or the HSV one, i.e. (see also https://en.wikipedia.org/wiki/HSL\_and\_HSV):
H: hue values;
S: saturation values;
V: brightness values.
for L1a products and the Lexicographic one for L1b products, i.e.:
Red channel: \(\left\vert HH \right\vert\);
Green channel: \(\frac{1}{2}\sqrt{{HV}^2+{VH}^2}\);
Blue channel: \(\left\vert VV \right\vert\).
4.3.5 Overlay ADS#
The Overlay ADS is a Keyhole Markup Language (KML) file that describes the product coverage area and is suitable for viewing the Quick-look ADS in any application that supports KML format (like, e.g., Google Earth or GIS applications). Its structure is described in the following figure and tables.
Fig. 33 — Overlay ADS
Table 63 — Overlay ADS
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
Document |
Document container for KML components. |
DocumentType |
1 |
Table 64 — Overlay ADS (DocumentType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
name |
Name of the document. |
|
1 |
description |
Description of the document. |
|
1 |
GroundOverlay |
Contains the parameters required to specify the footprint of the image and overlay the quicklook image on a map. |
GroundOverlayType |
1 |
Placemark |
Contains the metadata associated to the overlay. |
PlacemarkType |
1 |
Table 65 — Overlay ADS (GroundOverlayType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
name |
Name of the ground overlay. |
|
1 |
visibility |
Specifies whether the feature is drawn in the 3D viewer when it is initially loaded (0: not visible, 1: visible). |
|
1 |
TimeStamp |
Structure containing the time stamp of the overlay that can be used for dynamic visualizations over time. |
TimeStampType |
1 |
Icon |
Structure describing the image file used on the map overlay. |
IconType |
1 |
LatLonQuad |
Structure containing the latitude and longitude coordinates used to position the image overlay on the map. |
LatLonQuadType |
1 |
Table 66 — Overlay ADS (TimeStampType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
when |
Overlay time stamp in ISO 8601 format (YYYY-MM-DDThh:mm:ss). |
|
1 |
Table 67 — Overlay ADS (IconType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
href |
A local file specification or URL used to load the desired image and overlay it on the map. |
|
1 |
Table 68 — Overlay ADS (LatLonQuadType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
coordinates |
A string of 5 lon,lat coordinate pairs which describe the corners of the image. The string is of the form: lon,lat lon,lat lon,lat lon,lat lon,lat The coordinates must appear in the following order: last line first pixel, last line last pixel, first line last pixel, first line first pixel, last line first pixel |
|
1 |
Table 69 — Overlay ADS (PlacemarkType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
Name |
Name of the placemark. |
|
1 |
visibility |
Specifies whether the feature is drawn in the 3D viewer when it is initially loaded (0: not visible, 1: visible). |
|
1 |
TimeStamp |
Structure containing the time stamp of the placemark that can be used for dynamic visualizations over time |
TimeStampType |
1 |
Style |
Structure describing the stype used to display the placemark. |
StyleType |
1 |
ExtendedData |
Structure containing the metadata associated to the overlay. |
ExtendedDataType |
1 |
Polygon |
Structure containing the latitude and longitude coordinates used to position the image overlay on the map. |
PolygonType |
1 |
Table 70 — Overlay ADS (StyleType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
LyneStyle |
Line style. |
LyneStyleType |
1 |
PolyStyle |
Polygon style. |
PolyStyleType |
1 |
Table 71 — Overlay ADS (LyneStyleType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
color |
Line color in 32 bit hex format (AABBGGRR order). |
|
1 |
width |
Line width. |
|
1 |
Table 72 — Overlay ADS (PolyStyleType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
color |
Polygon color in 32 bit hex format (AABBGGRR order). |
|
1 |
Table 73 — Overlay ADS (ExtendedDataType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
Data |
Metadata. |
DataType |
1…inf |
Table 74 — Overlay ADS (DataType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
value |
Metadata value. |
|
1 |
Table 75 — Overlay ADS ()
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
tessellate |
Tessellate option. |
|
1 |
|
Altitude mode option. |
|
1 |
|
Polygon outer boundary description. |
|
1 |
Table 76 — Overlay ADS (outerBoundaryIsType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
LinearRing |
Linear ring description. |
LinearRingType |
1 |
Table 77 — Overlay ADS (LinearRingType)
Name |
Description |
Data Type |
Cardinality |
|---|---|---|---|
coordinates |
A string of 5 lon,lat,height coordinate tuples which describe the corners of the image. The string is of the form: lon,lat,height lon,lat,height lon,lat,height lon,lat,height lon,lat,height The coordinates must appear in the following order: last line first pixel, last line last pixel, first line last pixel, first line first pixel, last line first pixel |
|
1 |