Last modified on Sept 04, 2023 16:39

Contributors: B. Calmettes (CLS), N. Taburet (CLS), C. J. Merchant (University of Reading), L. Carrea (University of Reading), R. Maidment (University of Reading)

Issued by: CLS/B. Calmettes

Date: 08/05/2023

Ref: C3S2_312a_Lot4.WP2-FDDP-LK-v1_202212_LWL_ATBD-v4_i1.1

Official reference number service contract: 2021/C3S2_312a_Lot4_EODC/SC1

History of modifications

List of datasets covered by this document

Related documents

Acronyms

General Definitions

Lake Water Level: Measure of the absolute height of the reflecting water surface beneath an orbiting satellite with respect to a vertical datum (geoid) and is expressed in metres.

Altimeter: A device that measures altitude, the distance of a point above sea level. Radar altimetry measures the two-way travel time of a radar pulse between the satellite antenna and the Earth's surface at the nadir of the spacecraft, from which an estimate of Lake Water Level can be derived and delivered to users as a dataset product.

Scope of the document

This document is the Algorithm Theoretical Basis Document (ATBD) for product Copernicus Climate Change Service (C3S) Essential Climate Variable (ECV) Lakes (LK) – LWL (Lake Water Level), version Climate Data Records (CDR) 4.0. It describes the logical and theoretical basis and justification that underpins the implementation of the Lake Water Level in the context of the C3S. It details the methodology to be applied on the satellite altimetry data and also describes its limitations.

Executive summary

The C3S Lake production system (C3S ECV LK) provides an operational service, generating lake surface water temperature and lake water level climate datasets for a wide variety of users within the climate change community. This document covers the lake water level system.

The LWL science team and the LWL system development team developed water level retrieval algorithms to meet user requirements. The algorithms are designed to derive the most possible benefit from the active and passive input data streams and achieve the best quality. Regular quality monitoring exercises are conducted to ensure that the algorithms allow the LWL product to move towards user requirements targets. These procedures and processes are described here in detail.

This document describes the algorithms used to generate the water level product, which is performed in three main steps: (1) Selection of the appropriate altimetric input data, (2) estimation of the water level itself including filtering of outliers and (3) updating of the timeseries containing the water level values and the associated uncertainty.

1. Instruments

The water level estimation is performed using data from multiple instruments on several missions. Table 1 shows the instruments on board the different missions.

Table 1: List of missions and instruments.

1.1. Poseidon-1

SSALT (Single frequency Solid State radar ALTimeter), also called Poseidon-1, has validated the technology of a low-power (49 W), lightweight (23 kg without redundancy) altimeter for future Earth observing missions. It was supplied by the French Space Agency (CNES). It shares the same antenna as the National Aeronautics and Space Administration (NASA) altimeter NRA (Nasa Radar Altimeter); thus, only one altimeter operates at any given time (on Topex/Poseidon it operated about 10% of the time, or one cycle in ten).

Poseidon-1 operating at a single frequency of 13.65 GHz (Ku-band), for that reason, an external correction for the ionosphere must be supplied. It measures range (the distance from the satellite to the Earth's surface) by emitting a radar beam that is reflected back to the antenna from the Earth's surface.

1.2. Poseidon-2

Poseidon-2 is the Jason-1 mission's main instrument, derived from the experimental Poseidon-1 altimeter on Topex/Poseidon. It is a compact, low-power, low-mass instrument offering a high degree of reliability. Poseidon-2 is a radar altimeter that emits pulses at two frequencies (13.6 and 5.3 GHz, the second frequency is used to determine electron content in the atmosphere) and analyzes the return signal reflected by the surface. The signal round-trip time is estimated very precisely to calculate the range, after applying corrections. (Instrument supplied by CNES).

1.3. Poseidon-3

Poseidon-3 is the main instrument of the mission and a follow-on to the Poseidon-2 altimeter used on Jason-1. Small, lightweight and with low power consumption, it is also extremely reliable. It consists of a radar that transmits waves at two different frequencies (13.6 and 5.3 GHz, to make it possible to identify the atmosphere's electron content) then receives and analyses the signal reflected by the surface. Precise estimates of the round-trip time of the wave make it possible to calculate the distance between the satellite and the surface (after applying a few corrections).

Poseidon-3 is coupled with Doris (Doppler Orbitography and Radiopositioning Integrated by Satellite)/Diode (Détermination Inmédiate d'Orbite par Doris Embarqué). Doris is a satellite tracking system designed by CNES to provide precise orbits on-board low earth orbit satellites and Diode is an integrated software to the Doris instrument that calculates real-time location and very precise velocity of the satellite. This technology allows better measurement over coastal areas, inland waters and ice. In addition, to improve the accuracy of the measurements in these areas, Poseidon-2 is equipped with an open-loop tracking technique.

1.4. Poseidon-3B

The Poseidon-3B, supplied by CNES, is the main instrument of the Jason-3 mission; it is, derived from the altimeters on Jason-1 and then Jason-2. It allows to measure the range (the distance from the satellite to the Earth's surface), wave height and wind speed. This altimeter implements a mixed mode allowing on-board automatic transitions between the Diode/DEM (Digital Elevation Model) mode and the acquisition/tracking mode with respect to the satellite position. Indeed, Jason-2 uses the two altimeter modes, the "autonomous tracking" and the Diode/DEM modes, to improve measurements over coastal areas, inland waters and ice. But these modes have the disadvantage to be exclusive.

1.5. Poseidon-4

Poseidon-4 is a Synthetic Aperture Radar (SAR) dual frequency altimeter on board Sentinel-6A, that measures in the Ku (13.575 GHz) and C (5.3 GHz) bands. It measures altimeter range, backscatter coefficient (sigma0), significant wave height and ionospheric correction. This altimeter features higher performance than the previous generation, because of the introduction of a new, "interleaved" SAR operating mode. Poseidon-4 also features a new architecture, improving the role of the digital functions to support higher stability of the performances.

1.6. Radar Altimeter (RA-2)

The radar altimeter (RA-2), onboard EnviSat, is a fully redundant nadir-pointing pulse-limited radar operating via a single antenna at frequencies of 13.575 GHz and 3.2 GHz. It is designed to operate autonomously and continuously along the orbit to collect, on a global scale, calibrated samples of the earliest part of radar echoes from ocean, ice, and land and from their boundaries with minimum interruption. In contrast to earlier altimeters, a clear distinction is made between the robust collection of accurately quantified radar echo data by the instrument, and the interpretation of these data as meaningful geophysical quantities on ground.

One of the new features on RA-2 is the Model Free Tracker (MFT) in the onboard signal processor. The MFT software is designed to select the highest radar resolution while maintaining an adequate signal-to-noise ratio and keeping the leading edge of the radar echoes inside the window.

1.7. AltiKa

The altimeter named AltiKa on board SARAL (Satellite with Argos and Altika) uses a single frequency in Ka-band (35.75 GHz). It is the first oceanographic altimeter using such a high frequency. It is much less affected by the ionosphere than the sensors operating at Ku-band, and has greater performance in terms of vertical resolution, time decorrelation of echoes, spatial resolution and range noise. But its main drawback is that Ka-band electromagnetic waves are sensitive to rain.

1.8. SRAL

SAR Radar Altimeter (SRAL) on board Sentinel-3 is a delay-Doppler altimeter. The main frequency used for range measurements is the Ku-band (13.575 GHz, bandwidth 350 MHz). There are two radar modes: (1) Low-Resolution Mode (LRM) than is the conventional altimeter pulse-limited mode and (2) Synthetic Aperture Radar (SAR) mode: high along track resolution mode. On Sentinel-3A and Sentinel-3B, the SRAL altimeter is always operated at High Resolution Mode (commonly called SAR mode). Low Resolution Mode (LRM) is a back-up mode only.

Two tracking modes are provided, closed-loop mode (autonomous positioning of the range window using the median algorithm) and open-loop mode (range window position based on a priori knowledge of terrain altitude derived from a Digital Elevation Model (DEM)).

2. Input and auxiliary data

For lakes and reservoirs, the altimetry data processed for the currently operational production are those measured using altimetry instruments on board the Sentinel-3A, Sentinel-3B and Sentinel-6A.  Historical data was estimated using altimetry data from past missions: Topex/Poseidon, Jason-1, Jason-2, Jason-3 and Envisat. Data from SARAL is used occasionally for some lakes.

The update of the products is done using STC (Short Time Critical)-products, while in case of complete reprocessing, NTC – Non-Time Critical (or GDR – Geophysical Data Record)- data are used instead. The data provided by the AVISO² (Archiving, Validation and Interpretation of Satellite Oceanographic data) are delivered daily for STCs and once the cycle is complete for NTCs. The delivery time of these products is of the order of 2 days for the STC. For potential reprocessing, only the GDRs will be used and there is, by definition, no delivery time consideration for these reprocessing.

The input data needed for the processing (/ reprocessing) are:

• Altimetric measurements and associated corrections (STC and NTC) issued by Sentinel-6A Copernicus Hub (for sensors on board the Sentinel-3A and Sentinel-3B satellites).
• A master file listing all the lakes in the database with processing information for each of these lakes (tracks number, geographical limits on the lake for each track segment, type of correction for the humid troposphere, bias to be applied, type of tracker to be used). The lake selection presented in the current version of the product has been established by experts. Criteria were the selection of the largest lakes over which previous hydrological information was available for initialisation.

• An exclusion file that lists some parts of the lake to be excluded from the processing.

• A file with the average profiles along the tracks of each satellite above each lake of the data base. These average profiles have been calculated with the history of the past missions and can be used because the missions in progress are placed in orbits common to past missions (Sentinel-6A, Jason-3, Jason-2, Jason-1 and Topex/Poseidon share the same reference orbit, similarly to Envisat and SARAL). The mean profile corresponds to the variation in height of the geoid above the ellipsoid. As a first approximation, this height at each point along the track can be obtained using a geoid model, but even the best of the models cannot capture the small wavelengths of undulations in the geoid that are permanent characteristics of a lakes surface. For this reason, these short wavelengths of the geoid need to be calculated using data from past missions. Note that this calculation assumes that the vertical profile is constant along the track, regardless of the mean level variation of a lake. The estimates of these short wavelengths are then subtracted for each new passage of the satellite above a lake under a given track. For Sentinel-3A, average vertical profiles along the tracks on the lakes of the database were generated before the implementation in the processing chain.

• A file listing mean and maximal water level variations per lake from historical observations. To eliminate a cycle that would clearly be out of a historical maximum level variation threshold (1.4 bigger). The mean change in the level per unit of time was calculated for each lake. For each new cycle measured, a test is carried out to compare the new level with the last validated level, to ensure the level remains within limits of "acceptable" variations. This information is stored in a dedicated file that is "queried" by the algorithm at the end of the processing.

• A Historical Lake time series: a file per lake containing general information such as the geographic location, the country, and first/last dates with measurements as well as the previous lake water level estimations. This file is completed regularly with the more recent estimations.

The altimetry measurements at the input of the processing are archived at CNES (for Sentinel-6A), Copernicus Hub (Sentinel-3A/B,) and stored at CLS. All the master files and data files needed to process the altimetry measurements are provided by the Science Team.

In the event of NTC/GDRs data update for past or current missions as a result of the definition of new standards for NTC/GDRs, the entire lakes database may be reprocessed. For past missions it will be performed by the Science Team, while for the missions in progress, this will be done by the HydroWeb/HYSOPE processor for Short-Time Critical processing.

3. Algorithms

3.1. Overview

The monitoring of water levels of large lakes and reservoirs from space is performed by analysing measurements taken by radar altimeters on board several past, and current satellite missions.

The CNES/LEGOS (Laboratoire d’Etudes en Géophysique et Océanographie Spatiales) laboratory performed most of the pioneering work in that domain, and developed the HydroWeb website³  and products in the early 2000’s. The objective was to provide worldwide users with space-derived water level time series. Moreover, the lakes_cci project contributes to the improvement of the Lake Water Level (LWL9 estimates and fills the gaps by including data from past and current missions (such as Envisat or Cryosat-2).

In 2015, CNES, which has supported the R&D efforts aiming at improving the level 2 products for many years, decided to develop the HYSOPE (HYdrométrie Spatiale OPErationnelle) processor as a fully operational version of HydroWeb (Crétaux et al. 2015). The objective of this CNES initiative was to (i) deliver operational hydrology products to foster the development of scientific and user applications, and (ii) select a trusted operator for maintenance and exploitation of the system (as CLS).

The HYSOPE/HydroWeb processor is used as the processing chain for the production of the LWL variable in the framework of the Copernicus Climate Change Service (C3S).

The requirements for the development of HYSOPE are:

• To be based on input products whose production and access are guaranteed;
• To be able to include future altimeters with consistent product quality;
• To be able to integrate a much larger number of lakes;
• To deliver water level products within a maximum time delay of 3 days after acquisition;
• To provide products of peer-recognised scientific quality, evaluated via publication of procedures, algorithms and validation results.

The processing required to estimate LWL is a 3-step process as illustrated in Figure 1. Good quality high frequency measurements within the polygon bounding the lake, from multiple missions are used in the lake water level estimation (example in Figure 2 for Lake Superior).

Figure 1: Overview of the processing required to retrieve LWL from satellite measurements: Cylinders represent input dataset from multiple satellites. Parameter files in yellow, are required for each process step in blue. At each step, some measurements are rejected (red boxes) and files are generated with intermediate files (grey boxes). The last step allows the generation of the file containing the time series (green box). 


Figure 2: Example of Lake Superior with ground track coverages of Jason-3 (red) and Envisat (white). The process needs to take into account the complexity of the physical environment and the location of the tracks on an asymmetrically shaped lake with a group of small islands in the southwest corner of the lake and larger islands in the middle. In addition, the biases between the tracks and the missions have to be estimated.

The processing required to obtain and deliver a median water level estimate for each lake takes into account:

• The altitude of the satellite;
• Geographic and atmospheric corrections;
• The lake profile.

The resulting products are delivered in NetCDF format. 229 lakes worldwide are processed on an operational basis in C3S LWL product version 4.0. For each lake with a record, the time series is updated within 3 days after measurement, with a temporal coverage dependant on the altimetry mission coverage (10 days for Sentinel-6A, 27 days for Sentinel-3A and Sentinel-3B). The accuracy reported is lake-specific and depends on the altimetry missions used and on the shape of the lake. The average overall and mission-specific accuracy is included in the Product Quality Assessment Report (PQAR) [D 4].

Figure 3 illustrates the content of the data file for Lake Argentino (Argentina). It demonstrates how a time-series of measurements are available with variability information, and measurements derived from a number of different sensor systems.

Figure 3. Plot of the water level time series corresponding to Hysope processing for Lake Argentino. The blue dots represent the Lake Water Level corresponding to each satellite observation. Note that the time series has been computed since late 1992, starting with Topex/Poseidon until 2002, with Jason-1 between 2002 and 2008, with Jason-2 between 2008 and 2016, and with Jason-3 since October 2016. Data from Sentinel-3A is used since 2016 and data from Sentinel-6A is used from April 2022. This figure was generated with a toolbox available on the CDS⁴.

The satellite missions used to calculate changes in lake and reservoir levels are repetitive, i.e. the satellite passes over the same point on Earth after a constant time interval (of the order of 10 days, 28 days or 35 days depending on the type of orbit, respectively Jason-3, Sentinel-3/SRAL and SARAL/AltiKa for example). Each mission guarantees the ground position at nadir in a "cross track" band of +/- 1km. For a given lake, depending on its size, one or more satellites - and for each satellite, one or more tracks - can overpass it.

When the satellite is above the lake, the measurements are acquired along the track over the water surfaces, processed on board (waveform acquisition), and then reprocessed on the ground with several different waveform analysis models, among them, the ocean model (Brown 1977), used for biggest lakes (22 lakes with this model in dataset V4.0 in Table 2 ) and ice1 (an empirical method of the Offset Center of Gravity – OCOG) used for most of the lakes (Figure 4) . The best model from both algorithms is chosen per lake. This choice is made by the experts from the Science Team and the information is accessible for each lake and each satellite via the master file used for launching the computation. This information is defined in the parameter file, and it is not provided to the final user.

Figure 4: Lakes in dataset version 4.0. In red for lakes processed with ocean model retracking and in blue for lakes processed with ice1 retracking.

Table 2: Lakes processed with retracking ocean model.

The temporal sampling of the measurements along the track is 1 s (measurement at 1Hz) for all the satellites, and measurements at higher frequency are available within the products for more recent missions (18 Hz for Envisat, 20 Hz for Jason-2 and Jason-3, Sentinel-3A/B, Sentinel-6A and 40 Hz for the SARAL/AltiKa). For large lakes, bigger than 10,000 km², the ocean algorithm (waveform corresponding to a Brownian model) is used with measurements at 1 Hz. For lakes of a smaller size, the ice1 model and 1/20s or 1/40s measurements are used. In all cases, this choice is defined for the entire length of the time series and is recorded in the master file.

The processing consists of i) calculating the mean level along the track for each passage of one of the satellites above a given lake, and (ii) incrementing the time series with this new level value of the lake at the date of the passage. The list of lakes and tracks is known and included in the processing master file.

3.2. Methodology

3.2.1. General Description

The processing for each set of mission-specific data takes place according to an identical sequence of general tasks, which can be summarised as three main stages (Figure 1):

• Extract / select / read measurements from each of the STC files (Short-Time Critical mode) and calculate the water levels along the track (Level 2). For the case of a possible reprocessing, from the NTC/GDR files, all the measurements on all the lakes will be extracted.
• Recovery of the average profiles for the selected tracks, calculation of the lake level for the current track (Level 3), and validation of the most recently processed tracks.
• Update timeseries including the outlier rejection based on historical variability of each lake.

Each of these steps uses "subroutines" with a number of input files, whether they are master files supplied by the Science Team, or the outputs of the previous "subroutines".

The final NetCDF file is generated with this information. allowing the generation of figures with the water level variation.

3.2.2. Step 1: GDR Product selection and editing

3.2.2.1. Theoretical description: Overview

The first step consists of the following elements:

• Reading STC/NTC data. This data comes from different missions and may have different variable names.
• Reading master files (name of lakes, number of tracks and name of satellites, bias to be applied, retracking model used, track segments on the lake: a track can intersect a lake several times, depending on the presence of islands or emerged land areas). The master file is in text format. This file, in text format, is defined for internal use only and it is not provided to the final user⁵.
• Extraction of measurements on each lake overpassed by the satellite during the period considered according to the instructions in the master file. The file containing the selected data is in text format.
• Elimination of data according to predefined editing (corrections, flags). The file with this information, in text format, allows the later evaluation of the system quality.

For a given lake in the processing phase, the output of this first step is a text file with the set of pre-selected and filtered measurements which will be used in the step 2, and a file of control of the measurements rejected from the flags and the editing criteria.

Whatever the mission and whatever the lake, this step is unique. The altimetry database is explored for the latest measurements since the last update. The processing chain reads the master file in which key information on all the studied lakes is stored, as well as the different characteristics of the processing parameters, specific to each of these lakes, which need to be applied to data originating from each different mission.

When measurements corresponding to a passage from the satellite are found on one of the lakes included in the master file, the data to be processed on this lake can be extracted along the current track. The process continues until the last measurement of the track is obtained, in order to collect all the measurements on the studied lakes.

A set of editing parameters is queried to decide whether to select or reject each of the measurements along the current track. These editing parameters are identical for each satellite and each lake. A flag value is assigned according to the editing criteria (Table 3). Concerning the wet tropospheric corrections, the value can come from either the model or the radiometer depending on what is defined in the master file. The wet and dry tropospheric corrections consider the altitude of the measurement.

Table 3. Threshold and flags based on editing criteria.

All parameters are extracted from the altimetry database. For current missions (Sentinel-3A, Sentinel-3B, Sentinel-6A) the STC and NTC files provide i) high-rate (20 Hz) instantaneous measurements (ii) average measurement (1Hz) over one second for orbit, (iii) range estimates and (iv) geographic coordinates. Note that atmospheric corrections (Dry Tropospheric correction, Wet tropospheric correction and Ionospheric corrections) as well as tidal corrections (Pole tide and Earth tide) used in step 2 are provided in low resolution (1Hz).

For large lakes, the chain preferably uses 1Hz measurements with the Ocean retracking. For small lakes, the Offset Centre of Gravity (OCOG) Retracking is selected with high rates (the geophysical corrections are duplicated to match the measurements). This choice is indicated in the program via the master file read at the beginning of processing in this step.

Note that the processing chain does not use the quality flag based on the use of altimetric measurements over the oceans. However, it does use the flags of the individual corrections provided in the STCs and the NTCs, where applicable (e.g. a threshold -dependent flag is used for the ionospheric correction and for the dry/wet troposphere corrections as indicated in Table 3.

3.2.2.2. Process flow

The process flow is the same for the whole set of altimetry missions (past and current missions). Time series are being updated with new measurements from current missions: Sentinel-3A, Sentinel-3B and Sentinel-6A.

The procedure is as follows:

• Opening of the master file (text format) of the lakes including the part of the track to be used for the lake water level and the segments to be excluded from this track due to intersection with emerging lands (for example, the track crossing an island in the lake).
• Pre-selection of acquired tracks that overpass each of the studied lakes (there are potentially several lakes monitored per day).
• Selection of measurements that are exactly on track (considering the different keys of the master file and of the sections to be excluded: longitude bounds for each track, mode key for taking into account the wet troposphere correction, bias to be applied, and sections to be removed).
• Application of criteria for the rejection of individual measurements on the lake: based on thresholds (minimum and maximum) of the different components used for the LWL estimation. This step is also known as "Editing".
• Writing the output file that corresponds to the measurements selected after this step and the control file that lists the rejected measurements on the lake.

Figure 5 shows the selected and edited measurements over Athabasca Lake and a zoomed-in panel looking at track 710 in more detail. In this track, some segments are excluded due to the presence of islands along the track. The edited measurements are mainly located near the shore, probably caused by land contamination which produces low values on the backscatter coefficient.

Figure 5: Tracks over lake Athabasca from multiple satellites. In red, the measurements rejected from track 710 because of the edition criteria. Green measurements indicate those which are accepted.

3.2.2.3. Interfaces

3.2.2.3.1. Input data

Altimetric data file
Input parameters to be extracted: Table 4 contains the names of the netCDF variables for current missions: Sentinel-6A and Sentinel-3A/B downloaded from AVISO.

Table 4. Example of Sentinel-6A-STC or NTC data downloaded from AVISO.

Note: for corrections of wet troposphere and ionosphere, it is necessary to extract both the model value (model_wet_tropo_corr and iono_corr_gim_ku) and the instrumental corrections (rad_wet_tropo_corr and iono_corr_alt_ku). The correction from the model is used as a substitute in the case where the instrumental correction is flagged as inappropriate to use.

For the wet troposphere, the choice of the default value and thus of the backup value is given in the master file for each lake. For the ionospheric correction, the instrumental correction is chosen by default and the value of the model is only used in case of flag of the instrumental value. For more information on a particular lake, please contact the inland water team (inlandwaterlevel@groupcls.com)

Master Files

Two files are used in this stage of processing: master file and exclusion file. The master file gives the processing conditions for all the lakes. The exclusion file is dedicated solely to lakes where one or more tracks may cut the same lake several times depending on the lake shape, and the presence of islands (Figure 5). In these cases, it is necessary to remove segments along the track to avoid calculating levels on land in the direct surroundings of the lake. These files are not provided to end users.

Figure 6 and Figure 7 present examples of a master file and an exclusion file for a lake (Lake Argentino) respectively. The master file contains the information about the monitored lake, with individual lines dedicated to each track. The exclusion file contains a series of lines, each one containing information on the segments to be rejected for each satellite track.

Figure 6: Lake master file: example over the lake Argentino. The first line is the file header containing the number of tracks over the lake, the name of the lake, the continent, and the retracking to be used (normal for ocean model or ice1 for small lakes). Subsequent per-track lines contain the track number, the minimum/maximum longitude limits, a flag to indicate if the track is active, a key for the choice of wet tropospheric correction (model/radiometer), the name of the satellite and the bounds in case of an interleaved orbit. 

Figure 7: Lake exclusion file: Example over the lake Argentino. Each line contains the name of a lake, a number defining the used satellite, the number of segments to be rejected, and then for each segment, the number of the track and the limits (min and max) in longitude to be rejected.

In the Figure 7, example, over the lake Argentino, mission ERS-2/RA (mission code = 4), 3 segments must be removed: two segments (with longitudes from 287.08 to 27.09, and 287.11 to 281.17) from track 347 and one segment from track 10 (from longitude 287.23 to 287.31). Regarding the Envisat/RA-2 mission (mission code = 5), two segments are rejected, both on track 695.

3.2.2.3.2. Output data

For each new processing, the chain populates both a file with the rejected measurements and a file of the selected measurements resulting from the previous processing steps containing high frequency corrected altimetry data. Both files are in text format. The selected measurements file is used in the following step, while the rejected measurements file is used for diagnosis purposes.

3.2.2.4. Process description

3.2.2.4.1. Function 1: Geographical selection of measurements on lakes for a given day

Procedure: Reading of data on all the lakes of the database and the parameters that will allow the selection of measurements and geographical selection of the measurements on each of the lakes.
Input: NTC/STC measurement file of each satellite; parameter files.
Output: Table of measurements in text format (with corrections) actually located above each lake overflown during the day.

3.2.2.4.2. Function 2: Flag selection and "editing" of preselected measurements

Procedure: For all the measurements that have been geographically preselected, it is necessary to check whether the values of the measurements and corrections are flagged or not and then add the tests of "editing". The flagged values and the "editing" considered are described in Table 3.
Input: Measurement data from Function 1.
Output: Separated text files with selected and rejected measurements.

3.2.2.5. Quality control and diagnostics

If no measurements are selected at the end of Step 1 for a lake overpassed by a satellite during the processing day, an error alert code is raised and archived.

3.2.3. Step 2: Processing and filtering

3.2.3.1. Theoretical description: Overview

The mean profile along each track is computed in advance by the Science Team and is provided as a file regrouping the set of profiles of each track for each lake of the database. This information is only available internally.

Once the measurements have been selected in step 1, step 2 compute the lake level for each measurement. This is done by applying the corrections, as well as an additional correction, not extracted from the NTC measurements, but from an a priori correction file provided by the Science Team. This correction concerns the vertical bias that must be applied to each measurement to correct the height of the geoid above the reference ellipsoid. Indeed, the geoid over a lake has permanent vertical oscillations that are too tiny to be detected in the existing geoid grids, even the most accurate ones. For the calculation of the median level of a lake for a passage of a satellite, this corresponds to a vertical profile along the track to be removed. These profile values have all been calculated beforehand and are provided via a profile file in text format.

A second part step 2 involves removing the outliers along the track after calculating the median level of the lake along the track (this elimination is iterative and based on the standard deviations of each measurement relative to the calculated median level at each iteration). Figure 8 shows the altimetry principle: a signal is emitted to Earth that is reflected to satellite allowing the estimation of the distance (range).

Figure 8: Altimetry principle (Credits CNES – Mira production).

For each measurement we can define the height of the lake (Water Surface Height: WHS) at this point above the ellipsoid by the formula below:

Where orbit is the altitude of the satellite, and the corrected range is given by

Where:

• dry_tropo: Dry tropospheric correction
• wet_tropo: Wet tropospheric correction
• iono: Ionospheric correcition

To have the Lake Water Level (LWL) at the level of the geoid it is necessary to calculate:

The value of the geoid considered here is extracted from the file of average profiles as described above.

Once all the water heights have been calculated along the track, it remains to calculate the median and then the corresponding standard deviation. The median value was selected to avoid outliers at high frequency measurements. During the editing process, most of the outliers are rejected and, therefore the remaining data can be considered as normally distributed and the standard deviation provides reliable information about on their dispersion.

At the end of this calculation, additional data editing must be carried out:

• In a first iteration, each height measurement is compared with the median measurement that has just been calculated. If the absolute value of the deviation from the median measurement is greater than 1.5 times the value of the standard deviation, it is discarded.
• A new median value with the associated standard deviation is calculated at the end of the first iteration in order to proceed with a second (then third and fourth) iteration on the same principle with the selected values. However, for these iterations, a removal criterion equivalent to 2 times the standard deviation.

A maximum of four iterations are performed. If there are no rejected measures before the fourth iteration, the process stops.

3.2.3.2. Process Flow

The procedure of step2 is as follows:

• Calculation of the water level above the reference ellipsoid at each preselected measurement point.
• Reading of the file of the average profiles and recovery of the profiles of the lakes flown over.
• Subtraction of the mean profile on the levels at each point of measurements which have just been calculated.
• Rejection of outliers along the track (by the Standard Deviation test described in the previous section).
• Calculation of i) the median level for the considered cycle, and (ii) of the associated uncertainty based on the standard deviation of the selected measurements.

3.2.3.3. Interfaces

3.2.3.3.1. Input data

Input data are contained in the following input files:

• The profile files (one file per lake, satellite and track) for the geoid correction in Equation [3].
• The output file from Step 1 with the selected measurements.

3.2.3.3.2. Output data

For a given lake in the processing phase, the output of step 2 is a file, in text (.txt) format, with the dates, median lake levels, and standard deviations (as associated error of the valid measurements that have been calculated), as well as a control file containing the rejected altimetry measurements for future use in diagnostic purposes.

A file containing the rejected altimetry data is also generated with the purpose of being used in the future for diagnostic purposes.

3.2.3.4. Process description

3.2.3.4.1. Function 1: Geoid correction

Reading the file containing the selected measurements from Step 1 (section 3.2.2), and the profile file for the lake/satellite/track processed. This function allows the water height at each point along the track considered, on the lake considered, to be calculated using Equation [1].

In a second stage, interpolation in the profile file of the closest reference point with respect to the measurement point being processed (calculation of the distance between the measurement point to be corrected and the corresponding reference points in the mean profile file) and then apply the geoid correction according to Equation [3].

3.2.3.4.2. Function 2: Editing

Once the set of measurements has been corrected for the various parameters, including the mean profile, as indicated in function 1, additional editing is carried out as described in section 3.2.2.4.2.

At the end of this editing, a file recording the measurements that were filtered is saved, as well as a file recording the selected measurements. These two files serve as quality control of the process. Finally, a third file is created for each lake with the set of cycles that have been processed. It should be noted that during this stage, since all the data of the previous day is processed, several satellites may have flown over a given lake, and in this case, there may be several successive lake level calculations, and thus several lines in this file.

3.2.3.5. Quality control and diagnoses

If no measurements have been selected at the end of Step 2 for a lake overflown by a satellite during the processing day, an error alert code shall be assigned and archived. The warning codes for each step (1, 2 and following) make it possible to differentiate the type of rejection of the measurements on a given lake, in order to help the operator for a later evaluation of the problem.

3.2.4. Step 3: Time series update

3.2.4.1. Theoretical description: Overview

Step 3, which is the final step, retrieves the last validated file for each lake that has just been processed, and appends it with the new levels resulting from the calculation that has just been done. In this third stage, the last median level measurements of the lake are validated. For this, a file which indicates the maximum accepted variations of level for a lake by time step is queried. This internal file is created and provided by the hydrological experts from the Science Team. It is based on the history of the lake or reservoir level variations in the database, and allows a level variation threshold limit value to be estimated. The level variation between the most recent estimate and the last validated estimate is compared to this reference level variation value. Should it exceed this value, the new estimate is deemed not validated. Step 3 is, therefore, a third level of quality control editing after those set up in the first two steps of the processing.

The thresholds for time-variations of water level are defined for each lake. These values were set by experts who accounted for the history of water level changes within the lake or reservoir. Over reservoirs, regulation effects are therefore also accounted for, unless there is an unprecedented large regulation intervention that exceeds all the prior ones recorded within the historical values.

These threshold values are included in a file (one value per lake) that is read at the input of this step of the algorithm.

For each new passage of a satellite over a lake, one calculates:

Where the index "last" represents the last validated cycle (which can be n but also a date even earlier according to previous eliminations), L the measured level of the lake and t refers to the date. The last validated measurement must be read, provided it is "remote", i.e. at least 5.5 days (empirical value) from the measurement to be tested. If the last date is too close, the previous date will be searched until we get a sufficiently distant date.

A weighting factor of 1.4 is applied to the maximum value Dmax of the drift. In other words, any measurement of height of the lake for which DMlast is greater than 1.4 Dmax will be rejected. When DMlast is less than 1.4 Dmax the lake water height for the passage under consideration is considered valid.

Once this calculation has been completed the product file is updated with the last tracks processed for each of the lakes of the day.

3.2.4.2. Process flow

• Reading the file of the mean and maximal level variations of each lake provided by the Science Team provides water level thresholds based on historical information. This information about the maximum accepted variations is only available internally. For more information on a particular lake, please contact the inland water team (inlandwaterlevel@groupcls.com).
• A measurement providing a variation above the maximal variation threshold is considered an outlier and is edited.
• Writing (update) the lake water levels on the "Product File"

For a given lake in the processing phase, the output of step 3 is a new text file with the calculated water levels and the associated uncertainties. The final NetCDF file available at CDS (Copernicus Data Service) is generated with this information. Toolboxes for the visualisation of the lake water level variation are also available in the CDS.

3.2.4.3. Interfaces

3.2.4.3.1. Input data

The input data are found in the following input files:

• The file of last validated cycles (historical data);
• The last product file for the lake under consideration (for each studied lake);
• The file of the typical variations of each lake (used to edit the cycles). These standard variations are read at each new processing iteration, in order to check whether the level of the lake that has just been calculated remains within validated margins.

3.2.4.3.2. Output data

Final water level time series file in C3S netCDF format.

3.2.4.4. Process description

3.2.4.4.1. Function 1: Validation

Validation of the last passage(s) processed for each lake at the end of Step 2. The algorithm described in Equation [3] is applied (test on average and maximum drifts of the level of the lake).

3.2.4.4.2. Function 2: Writing output data

If applicable, writing of the water level in the new product file.

3.2.4.5. Quality control and diagnoses

If the height of the lake at the end of Step 3 could not be validated for a lake overpassed by a satellite during the processing day, an error alert code is raised and archived.

The alert codes for each step (1, 2 and 3) make it possible to differentiate the type of rejection of the measurements for a given lake, in order to help the operator for a later evaluation of the issue.

A rejection flag (for each lake processed each day) can be assigned and automatically conveyed to the operator.

4. Output data

The Product User Guide and Specification (PUGS) [D 5] contains the complete description of the output product in NetCDF format. The files generated during the processing are the following (for external and internal use):

1. the updated water level time series including the uncertainty and the metadata. One NetCDF file is available per lake. Figures with the time series for each lake can be generated using the data in these files (e.g. Figure 3);
2. the control data of the processing for possible further analyses (in case of detected issues, or to support further examination);
3. an updated archive of the cycles eliminated.

File 1 is available for public distribution as the Lake Water Level product on the C3S Climate Data Store. Files 2 and 3 are kept internally at CLS and are not publicly available.

5. Limitations

The lake processing chain, initially developed at LEGOS, is based on the use of altimetry measurements from the CTOH database (Center for Topography of the Oceans of LEGOS), including Envisat GDRs. This database also includes some enhanced corrections that are not in the data sets of institutional suppliers (AVISO, European Space Agency: ESA), such as those for the wet and dry troposphere and ionosphere. As part of the online version of HYSOPE (that serves the Copernicus Climate Change Service), these tailored corrections are by default replaced by their corresponding standard corrections included in the operational input products. Additionally, a module for calculating the height of the geoid has been developed in the operational chain, based on a grid provided by the LEGOS.

6. Algorithm Performance Monitoring and Recording

When reading the individual satellite measurements over a lake, a number of tests are performed, and error or validation flags are allocated. The tests performed and their corresponding flag values are indicated in Table 3. Each measurement, thus, has an associated flag which is zero if the measurement is valid.

The "editing" therefore corresponds to tests on threshold values for the corrections applied to the measurement. Note that in the input data themselves (e.g. from AVISO) parameters can already be flagged: the standard value being that of the fill value associated with each of the variables.

References

Brown, G. S. (1977). The Average Impulse Response of a Rough Surface and its Applications. IEEE J. Oceanic Eng. 2 67 – 74.

Cretaux J-F., Arsen A., Calmant S., et al. (2011). SOLS: A lake database to monitor in the Near Real Time water level and storage variations from remote sensing data, Advances in space Research, 47, 1497-1507

Crétaux, J-F., Biancamaria, S., Arsen, A., Bergé-Nguyen, M. and Becker, M. (2015). Global surveys of reservoirs and lakes from satellites and regional application to the Syrdarya river basin. Environmental Research Letters, 10(1), 015002.

Cretaux J-F, Abarca Del Rio R., Berge-Nguyen M., Arsen A., Drolon V., Clos G., and Maisongrande P. (2016). Lake volume monitoring from Space, Survey in geophysics, 37: 269-305. 10.1007/s10712-016-9362-6

Cretaux J-F. Bergé-Nguyen M. Calmant S. Jamangulova N. Satylkanov R. Lyard F. Perosanz F. Verron J. Montazem A. S. Leguilcher G. Leroux D. Barrie J. Maisongrande P. and Bonnefond P. (2018). Absolute calibration / validation of the altimeters on Sentinel-3A and Jason-3 over the lake Issykkul, Remote sensing, 10, 1679. 10.3390/rs10111679

Ričko M. C. M. Birkett, J. A. Carton, and J-F. Cretaux. (2012). Intercomparison and validation of continental water level products derived from satellite radar altimetry, J. of Applied Rem. Sensing, Volume 6, Art N°: 061710.10.1117/1.JRS.6.061710

Tilling R L, Ridout A and Shepherd A. Estimating Arctic sea ice thickness and volume using CryoSat-2 radar altimeter data. Advances in Space Research. Volume 62, Issue 6, 15 September 2018, Pages 1203-1225. https://doi.org/10.1016/j.asr.2017.10.051

Wingham, D. J., Rapley, C. G. and Griffiths, H. (1986). New Techniques in Satellite Tracking Systems. In IGARSS. 86 Symposium Digest September. Zurich, Switzerland, 185-90.

Related articles

• Page:
  ECV - Glaciers, Ice Sheets, Lakes, Soil Moisture
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: Product User Guide Specification (PUGS)
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: System Quality Assurance Document (SQAD)
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: Product Quality Assurance Document (PQAD)
• Page:
  IV Version 1.2; SEC Version 2.0; GMB Version 2.0: Product Quality Assessment Report (PQAR)