Contributors: B. Calmettes (CLS), G. Calassou (CLS), N. Taburet (CLS)

Issued by: CLS/B. Calmettes

Date: 12/02/2024

Ref: C3S2_312a_Lot4.WP2-FDDP-LK-v2_202312_LWL_ATBD-v5_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.

Single-track lake: is a lake observed over several cycles by a single track of an altimetry mission satellite. Those lakes are usually small, with a mean surface area of 13.44 km² in the LWL-S dataset v1.0

Scope of the document

This document is the Algorithm Theoretical Basis Document (ATBD) for two Lakes (LK) Essential Climate Variable (ECV) products on Lake Water Level (LWL), made available through the Copernicus Climate Change Service (C3S). These are the LWL Climate Data Records (CDR) version 5.0 and LWL-S (Lake Water Level - Single-track Lakes) CDR version 1.0. The latter product, given that the size of the surface is usually small, is also called Lake Water Level Small-lakes. This document describes the logical and theoretical basis, and justification that underpins the generation of the Lake Water Level datasets in the context of the C3S. It also details the methodology applied to generate the data products from the satellite altimetry data, and its limitations. 

Executive summary

The C3S Lake production system (C3S ECV LK) provides an operational service generating lake water level climate datasets. The dataset collections include one for medium to large lakes that considers the geoid variation along the track and the estimation of bias between tracks (LWL), and one for lakes observed only by a single track of an altimetry mission satellite (LWL-S) and usually with small surface area. These collections are made available for a wide variety of users within the climate change community. This document covers the algorithm theoretical basis description for both datasets.  

The LWL science teams 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 data and information extraction. Regular quality monitoring exercises are conducted to ensure that the algorithms allow the LWL and LWL-S products to move closer towards user requirements targets. These procedures and processes are described here in detail. 

This document describes the algorithms used to generate the water level products. Both products need the altimetry data from different instruments (Section 1). Input and ancillary data are described in Section 2. Finally, the algorithms used for the estimation of the water level itself for each dataset, including filtering and outliers, are described in Section 3.

1. Instruments

The water level estimation is performed using data from multiple instruments on several satellite 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, 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 operated at any given time (on Topex/Poseidon it operated about 10% of the time, or one orbital cycle in ten). 

Poseidon-1 operated at a single frequency of 13.65 GHz (Ku-band), for that reason, an external correction for the ionosphere must be used. It measured 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 was the Jason-1 mission's main instrument, derived from the experimental Poseidon-1 altimeter on Topex/Poseidon. It was a compact, low-power, low-mass instrument offering a high degree of reliability. Poseidon-2 was a radar altimeter that emitted pulses at two frequencies (13.6 and 5.3 GHz, the second frequency was used to determine electron content in the atmosphere) and analyzes the return signal reflected by the surface. The signal round-trip time was estimated very precisely to calculate the range, after applying corrections. (Instrument supplied by CNES).

1.3. Poseidon-3

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

Poseidon-3 was 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 for the Doris instrument that calculates real-time location and very precise velocity of the satellite. This technology enabled better measurement over coastal areas, inland waters and ice. In addition, to improve the accuracy of the measurements in these areas, Poseidon-3 was equipped with an open-loop tracking capability. 

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 enables the measurement of the range (the distance from the satellite to the Earth's surface), wave height and wind speed. This altimeter implements a mixed mode allowing for 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. However, these modes have the disadvantage of being exclusive. 

1.5. Poseidon-4

Poseidon-4 is a Synthetic Aperture Radar (SAR) dual frequency altimeter on board the Sentinel-6A mission, 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 performance stability. 

1.6. Radar Altimeter (RA-2)

The radar altimeter (RA-2), onboard Envisat, was a fully redundant nadir-pointing pulse-limited radar, operating via a single antenna at frequencies of 13.575 GHz and 3.2 GHz. It was 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 could be 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 was the Model Free Tracker (MFT) in the onboard signal processor. The MFT software was 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 performs better in terms of vertical resolution, time decorrelation of echoes, spatial resolution and range noise. However, its main drawback is that Ka-band electromagnetic waves are sensitive to rain. 

1.8. SRAL

SAR Radar Altimeter (SRAL) on board Sentinel-3 missions 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) is the conventional altimeter pulse-limited mode, and (2) SAR mode which is a 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). 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 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 missions. 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 within 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 altimetry measurements at the input of the processing are archived at CNES (for Sentinel-6A), at Copernicus Hub (Sentinel-3A/B) and stored at Collecte Localisation Satellites (CLS). All the master files and data files needed to process the altimetry measurements are provided by the Science Team.

2.1. Lake Water Level

This product provides lake water level measurements of medium to large lakes, considering the changes to the geoid value along the tracks and the estimation of the possible bias. The input data needed for the processing (or reprocessing) are:

• Altimetric measurements and associated corrections (STC and NTC), issued for Sentinel 3A and Sentinel 3B from Copernicus Dataspace Ecosystem⁴ and for Sentinel-6A from Eumetsat Data Services⁵ via CNES.
• A master file. This lists 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 in the Science team. Selection criteria were the largest lakes over which previous hydrological information was available for initialisation.
• An exclusion file. This 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 using the historical records from past missions. These 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 wavelength variations in 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 all missions, average vertical profiles along the tracks on the lakes of the database were generated to be used in the processing chain.
• A file listing mean and maximal water level variations per lake from historical observations. This file is used to eliminate a cycle that would clearly be out of a historical maximum level variation threshold (1.4 times larger). 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 updated regularly with the more recent estimations.

NTC/GDRs data are subject to updating on occasion for past or current missions as a result of the definition of new standards for NTC/GDRs. In the event of this, 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.

2.2. Lake Water Level – Single-track

This product provides water level measurements of lakes observed by a single track from a single mission, and usually with a small surface area (mean surface area of 13.45 km² for more than 10 000 lakes in dataset V1.0) The data needed for the calculation of the LWL-S product are:

• Altimetric measurements and associated corrections (STC and NTC), issued for Sentinel 3A and Sentinel 3B from Copernicus Dataspace Ecosystem⁶ and for Sentinel-6A from Eumetsat Data Services⁷ via CNES.
• A master file listing all the lakes to treat with the associated processing information. In contrast to the LWL products, the processing information concerns one track for each lake and contains:
  • the lake identifier;
  • the mission with observations over the monitored lake and the associated track number;
  • the mission bias;
  • a priori information on the mean water level of the lake and the standard deviation of the water level time serie;
  • a minimal threshold on the sigma0 values selected by track;
  • the sigma0 value chosen for a track (defined by a percentile value in the sigma0 track distribution and used to update the water level time series).

The lakes selected to generate the LWL-S products are chosen as mono-track lakes (i.e a lake observed with only one altimetric mission and a single track) due to the LWL-S algorithm definition.

• A polygon file which contains the spatial footprint for each lake in which the altimetric measurements are selected spatially in order to keep only measurements acquired over water surface. These spatial footprints are defined as polygons in a [json] format and are derived from the intersection of (i) the OLTC (Open Loop Tracking Command) footprint of the altimetric missions, a dataset of polygons with an on-board a priori elevation to ensure a correct reception centring over hydrological bodies, and (ii) the lakes mask defined in the HydroLake database (Messager et al., 2016).   

3. Algorithms

3.1. Lake Water Level

3.1.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 has 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 satellite-derived water level time series. Moreover, the lakes_cci project contributes to the improvement of the Lake Water Level (LWL) estimates and fills the gaps in the record by including data from past and current missions (such as Envisat or Cryosat-2).

In 2015, CNES, which has supported the research and development 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 within 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 measurement 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. For each lake with a record, the time series is updated within 3 days after the measurement is acquired, 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 3].

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 (Argentina). 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 has been used since 2016 and data from Sentinel-6A is used from April 2022. This figure was generated with a toolbox available on the Climate Data Store (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 (for example, of the order of 10 days, 28 days or 35 days for Jason-3, Sentinel-3/SRAL and SARAL/AltiKa respectively, depending on the type of orbit). 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) that is used for biggest lakes (22 lakes with this model in dataset V5.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 selection information is accessible for each lake and each satellite via the master file used for launching the computation, and is shown in Figure 4. This information is defined in the parameter file, and it is not provided to the final user.

Figure 4: Lakes in dataset version 5.0. In ‘+’ green, for lakes processed with ocean model retracking and in dark grey dots 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 (smaller than 10,000 km², which means most lakes) 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.1.2. Methodology

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

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.
2. 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.
3. 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, enabling the production of figures that visualise the water level variation.

3.1.2.2. Step 1: GDR Product selection and editing

3.1.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 is defined for internal use only and it is not provided to the final user.¹⁰
• Extraction of measurements for 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, enables 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 step 2, and a log file for recording 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 acquired for 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 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.1.2.2.2. Process flow

The process flow is the same for the whole set of altimetry missions, both past and current. 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 (Canada) from multiple satellites. In grey, the measurements at level 2 rejected because of the edition criteria. Green measurements indicate those which are accepted.

3.1.2.2.3. Interfaces

3.1.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.1.2.2.3.2 Output data

For each new processing run, 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 diagnostic purposes.

3.1.2.2.4. Process description

3.1.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 overpassed during the day.

3.1.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.1.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.1.2.3. Step 2: Processing and filtering

3.1.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 computes the lake level for each measurement. This is done by applying the corrections, as well as an additional correction (concerning vertical bias), not extracted from the NTC measurements, but from an a priori correction file provided by the Science Team. This vertical bias correction 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 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 of 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: WSH) at this point above the ellipsoid by the formulae below:

WSH=orbit-corrected_range [1]

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

Corrected_range = range_ku + dry_tropo + wet_tropo + iono + tides (pole and earth) [2]

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:

LWL=WSH-geoid [3]

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, the median and then the standard deviation are calculated. 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 to be normally distributed. The standard deviation therefore provides reliable information concerning 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 previously calculated, 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 each of these iterations, a different removal criterion is applied, using 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.1.2.3.2. Process Flow

The procedure of step 2 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 overpassed lakes.
• Subtraction of the mean profile of the geoid 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.1.2.3.3. Interfaces

3.1.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.1.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.1.2.3.4. Process description

3.1.2.3.4.1 Function 1: Geoid correction

Reading the file containing the selected measurements from step 1 (Section 3.1.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.1.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.1.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 overpassed a given lake, and in this case, there may be several successive lake level calculations, and thus several lines in this file.

3.1.2.3.5. Quality control and diagnoses

If no measurements have been selected at the end of step 2 for a lake overpassed 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.1.2.4. Step 3: Time series update

3.1.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 the variation (DM) between last measurements as follows:

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 sought 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, for any measurement of height of the lake where 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.1.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 into 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 on the CDS (Climate Data Store) is generated with this information. Toolboxes for the visualisation of the lake water level variation are also available in the CDS.

3.1.2.4.3. Interfaces

3.1.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.1.2.4.3.1 Output data

Final water level time series file in C3S netCDF format.

3.1.2.4.4. Process description

3.1.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 (testing the average and maximum drifts of the level of the lake).

3.1.2.4.4.2 Function 2: Writing output data

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

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

3.2. Lake Water Level – Single-track

3.2.1. Overview

As for the LWL products calculated for large lakes, the water level products for single-track lakes (LWL–S) use radar altimetry data from sensors on the Sentinel-3A (S3A) and Sentinel-3B (S3B) missions and the Jason-3 (J3) and Sentinel-6A (S6A) mission pair.

This product line is provided as an extension to the LWL products by using an approach that estimates lake water level time series based on a fixed geoid grid. On one hand, this choice speeds up the procedures for calculating time series. On another hand, this procedure (known here as "single-track mode") can only be used for lakes with altimetry observations from a single track from a single mission.

The generation of LWL-S products, as part of the C3S, is carried out using the HYSOPE software (also used for the LWL estimate) but with the configuration historically used to process river water levels (river mode).

The specifications for the river processing mode are similar to those specified for the LWL processing mode (Figure 9).

Figure 9: Overview of the processing required to retrieve LWL-S from satellite measurements.

The processing differs between lake mode used for the LWL product (Figure 1), and river mode used for the LWL-S product (Figure 9) in some of the editing approaches. LWL-S processing (river mode) does not require the computation of the mean geoid profile, but uses a geoid grid whose properties are described in section 3.2.2.4.1. The frequency of measurements for each lake depends on the mission revisit time (27 days for Sentinel 3A/B and 10 days for Jason3/Sentinel-6A). 

As with Hysope in lake mode, Hysope's river mode takes the following variables into account:

• Satellite altitude,
• Geographic and atmospheric corrections
• Geoid data associated with the lake.

Finally, the output products are in NetCDF format.

3.2.2. Methodology

3.2.2.1. General Description

Each mission-specific data set is processed in three main stages (see Figure 9) as follows:

• Extract / select / read measurements from 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 are extracted.
• Data selection of measurements for extracting the high-frequency measurements for each lake in two steps: i) a coarse rectangular selection window and (ii) finer selection using a polygon adapted to each target.
• The data filtering which consists of several successive statistical filters: i) on the dispersion of the high frequency (HF) measurements in relation to historic averages, (ii) on the dispersion of the remaining HF measurements in relation to their average, and (iii) filtering corresponding to the maximum time derivative of the water level defined for a lake.

Each of these steps uses "subroutines" with several input files, which are either master files supplied by the Science Team, or the outputs of the previous "subroutines".

The final NetCDF file is generated with this information, allowing for time series with the water level variation to be generated.

3.2.2.2. Step 1: GDR Products reading and editing

3.2.2.2.1. Theoretical description: Overview

This first step allows the mission track to be processed by track according to the following steps:

• Extraction of parameters that are necessary for all processing (date, position, reference, geophysical and instrumental corrections) throughout the track,
• Editing and calculation of the corrected water level (geophysical corrections required).

This first step function (which depends on the mission) takes the altimeter measurements of an entire track as input, performs the editing, applies the necessary scale factors, and provides as output the corrected water level for each instantaneous measurement (Level 2).

3.2.2.2.2. Process flow

The following part explains how the Sentinel-3A and Sentinel-3B water levels are computed in the process used to generate the LWL-S products. The process used for the computation of the Sentinel-6A and the one used for Jason-3 water level are almost identical.

For each instantaneous L2 measurement (k), provided it is valid, the following steps are performed:

• Computation of the raw water height at 20 hz (Hb) which can be define as the difference between the satellite altitude (alt_20hz) and the measured range retrieved with the ICE-1 retracking algorithm (ice_range_20hz_ku):

• Computation of the algebraic sum of the geophysical corrections xcorr. The geophysical corrections include the ionospheric correction, dry tropospheric correction, wet tropospheric correction, solid tide and polar tide.
• Estimation of the corrected water level by substituting the sum of the geophysical corrections from the raw water height.
• Transformation of the date of measurements at 20Hz (number of seconds since 1/1/2000) into calendar format (DD/MM/YYYY), and time (HH:MM).
• Change of scale according to the Table 5.

Table 5: Variables computed at the end of the editing step of the Sentinel-3 data.

3.2.2.2.3. Interface

3.2.2.2.3.1 Input data

Whatever the satellite mission, the input data for step 1 is as follows:

• A master file, indicating the tracks to be processed. It is always the same master file that is used at every stage of the processing chain.
• Altimetry measurements (IGDR /GDR for Sentinel 3A/B or STC/NTC for Jason3/Sentintel-6A).

Altimetric data file
The Sentinel-3A (identical to Sentinel-3B data) are used here to illustrate the content of the altimetric data file used. However, this content is slightly different for other missions used for the generation of the LWL-S products: Jason-3 and the Sentinel-6A missions, particularly in names of certain variables.

Table 6 contains the name of the netCDF variables selected for Sentinel-3A and Sentinel 3B missions.

Table 6: Selected Sentinel-3 variables

To calculate the raw water height (i.e. without corrections), 20 Hz measurements are used (every 1/20 of a second). The geophysical corrections provided for the corresponding averaged measurement are applied to all the instantaneous measurements (these are the only corrections provided).

3.2.2.2.3.2 Output data

For each lake, variables present in Table 5 complete the track data in order to be used in the next step.

3.2.2.2.4. Process description

3.2.2.2.4.1 Function 1: Extraction and selection of useful parameters

Procedure: Reading data for lakes associated to the track which is being processed and extract the variables which will be necessary for all the processing.
Input: NTC/STC measurement netCDF files associated with the satellite track.
Output: Table of measurements for each lake with the observations in the processed track.

3.2.2.2.4.2 Function 2: Editing and computing of the corrected water level.

Procedure: Verification of the measurement validity and computation of i) the raw water levels (without corrections) and (ii) the corrected water levels (including the geophysical corrections).
Input: Data extracted during the Function 1.
Output: Dataset completed with the raw and corrected water levels.

3.2.2.2.5. Quality control and diagnoses

If no measurements are selected at the end of the step 1 for a lake observed for the processed track, a warning will be raised and archived.

3.2.2.3. Step 2: Data selection for a lake and editing

3.2.2.3.1. Theoretical description

The data in the lake polygon is selected by taking the track measurements (from step 1) whose coordinates fall within the polygon defined for each lake in the master file. This method makes it possible to accurately eliminate measurements that do not cover the water surface (banks or islands).

The polygons used for this selection are taken from the intersection between the OLTC footprint of each mission with the polygons defined in the HydroLake database (see Figure 10). The OLTC footprint (purple) and the HydroLake polygons (red) are in shapefile (.shp) format suitable for processing in Geographic Information System (GIS) software. The lake footprints polygons are stored in a shapefile.

Figure 10: Mask of the Lake Biel (Swiss) in red intersected by the OLTC footprint of the Sentinel-3B mission (purple rectangle). The intersection of the two masks (illustrated by the yellow polygons) is used by Hysope to retrieve the water level time series of the Lake Biel (Switzerland).

The polygon representing the area to process in a lake is defined in a GeoJSON file. 

Using this data defined a priori (offline), we test the inclusion of the HF data. Firstly, only the data included in the area defined in the master file is selected. Then their inclusion in the polygon defined in the GeoJSON file (provided that the polygon is present in the file) is tested.

A second part of the step 2 consists of filtering the invalid data. This includes filtering on the basis of i) the measurements with invalid (NaN) geophysical correction, and (ii) the backscatter coefficient (sigma0) in order to eliminate measurements over land.

3.2.2.3.2. Interface

3.2.2.3.2.1 Input data

The input files for step 2 are:

• The master file which indicates for each lake the tracks to be processed. The same master file is used at every stage of the processing chain.
• GeoJSON file of the lake footprints (OLTC and Hydrolakes intersections).
• Altimetry measurements from step 1

3.2.2.3.2.2 Output data

• The file of selected high-frequency altimeter measurements, containing: track number, cycle number, date, time, coordinates (lon, lat) and corrected height.
• A file containing the high-frequency altimeter measurements eliminated in step 2, containing the track number, cycle number, date, time, coordinates (lon, lat) and elimination criterion.
• An execution report giving information on the number of measurements selected.

These files will be useful in the event of execution anomalies for expert appraisal and are kept for a certain period of time, except for the execution report, which can be accumulated for all stages and kept with the history. They are not distributed as part of LWL-S products.

3.2.2.3.3. Process description

3.2.2.3.3.1 Function 1: Geographical selection of the data

Process description: Selection of the track measurement which intersect the lake mask according to their geographical coordinates.
Input: Master file containing the track to process and the polygon file defining the area of interest (AOI) for each lake.
Output: Measurements which are located within the lake AOI intersected by the processed track.

3.2.2.3.3.2 Function 2: Filtering of the invalid data and sigma0 values

Process description:

• NaN: If at least one of the parameters (ionospheric correction, dry tropospheric correction, wet tropospheric correction, altitude, range) is invalid (NaN), all the measurements at 20Hz will be filtered.
• Backscatter coefficient (sigma0): Measurements are considered valid if sigma0 is greater than the threshold value indicated in the master file. As a second step, in case that there are at least four valid points, only a certain percentage of the strongest sigma0 values are retained (among those above the first threshold). This percentage is indicated in the master file.
• Measurements that pass these two criteria are considered valid.

Input: The altimeter measurements from the first step (reading the data).
Output: Data selected after geophysical correction and sigma0 filtering.

3.2.2.3.4. Quality control and diagnostic

If a single value is obtained after filtering process (function 1), it is also edited. The remaining measurements (function 2) are stored in intermediate files only used by experts and not provided to users.

3.2.2.4. Step 3: Timeseries update

3.2.2.4.1. Theoretical description

The main objectives of this step are:

• Filter water levels from step 2 in order to reject outliers coming from, for example, the retracking of another water body close to the studied lake.
• Specific to Jason-3: Changing the elevation model reference to the WGS-84 ellipsoid model. Sentinel-3A, Sentinel-3B and Sentinel-6A are already referenced to the WGS-84 model.

For a given lake, the master file contains two parameters: the mean and the standard deviation of the estimates in the complete time series, calculated using data from previous cycles. These two parameters are called the global mean and the global standard deviation. In the case of a complete reprocessing, it is necessary to define these values beforehand empirically for the first cycle. For LWL-S products, prior water level height is extracted from the HydroLake database.

Instantaneous measurements are eliminated from the current cycle in relation to the global mean and global standard deviation (mean plus or minus 3 standard deviations), using the values given in the master file. This step removes measurements that are probably (very) wrong (on land, for example) so as not to degrade the mean of the points in the cycle.

The Dmax filter, whose application for LWL products is described in section 3.1.2.4.1, is then applied.

Once the outliers are rejected, the change of reference is performed. The height measurements (orbit and ranges) in the input data are referenced to an ellipsoid that is not necessarily the same for all the missions: the WGS84 ellipsoid is used for Sentinel-3A/Sentinel-3B and Sentinel-6A, and 'T/P' for Jason-3 mission. When Jason-3 data are used in conjunction with Sentinel-6A data, a bias per lake is calculated between the data from the two missions when the data overlap.

The last step is to add the geoid height to the water level calculated previously. The mean water height (h') corrected for the geoid height is:

where:
Hg is the geoid height and
h the mean water height calculated in step 3.

The EGM2008 is used as the common geoid for all the missions. At this level of the processing chain, heights are referenced to the WGS84 ellipsoid (international standard). The height of the EGM2008 geoid calculated at the position of the lake must then be added.

The geoid over single-track lakes is considered to be constant. It is obtained from the grid calculated by the National Geospatial Intelligence Agency (NGA) with a step of 1x1 minute (referenced to WGS84), supplied by LEGOS in NetCDF format.

3.2.2.4.2. Process Flow

The procedure of step 3 for the filtering process is as follow:

• Computation for each new cycle of the global mean and the global standard deviation from the water level time series and rejection of the outliers according to the threshold indicated in the master file.
• Rejection of the outliers of the current cycle according to the mean and the standard deviation computed from instantaneous measurements in the cycle. The standard deviation is weighted by a coefficient indicated in the master file.
• Application of the Dmax filter to the water level time series.

The procedure for the change of reference only concerns Jason-3 measurements.

• A first application of Hysope allows, for each lake, the bias between the Jason-3 and Sentinel-6A to be computed. The change of ellipsoid is performed by applying a constant bias (equal to 0.701 m).
• A second application of Hysope allows us to recompute Jason-3 water levels according to the change of ellipsoid and the bias previously computed with the Sentinel-6A data.

Ultimately, the procedure of the geoid application ensures that water height estimates are provided with respect to the geoid EGM2008, instead of the WGS84 ellipsoid.

3.2.2.4.3. Interfaces

3.2.3.4.3.1 Input data

The input files for step 3 are:

• The master file containing the tracks to be processed. It is always the same master file that is used at all stages of the processing chain.
• The file of valid altimetry measurements from step 2.

3.2.3.4.3.2 Output files

For each lake, the output files are:

• The file of valid high-frequency altimeter measurements selected for averaging, after all the filtering in step 3 (track number, cycle number, date, time, coordinates (lon, lat) and water level).
• A file containing the high-frequency altimeter measurements eliminated by all the filtering in step 3, containing the track number, cycle number, date, time, coordinates (lon, lat) and elimination criterion.
• A file containing the updated time series (Level 3) with all the parameters calculated for the lake: cycle number, date and time, mean water level with respect to the ellipsoid and mean water level with respect to geoid EGM2008, median value and standard deviation of selected L2 measurements.

3.2.2.4.4. Process description

3.2.2.4.4.1 Function 1: Filtering and computing of the mean water level height

Process description: Rejection of the outliers according to a filter using the global mean and the global standard deviation of the water level time series and another rejection based on the mean and the standard deviation of the instantaneous measurements of the current cycle (approach included in Step 3 illustrated in Figure 9).
Input: The master file containing the weighting coefficients for the global and local standard deviations.
Output: A file containing Water level time series with valid measurements after filtering, and other file withmeasurements eliminated by the filtering. The latter file is not distributed.

3.2.2.4.4.2 Function 2: Changing of reference

Process description: Change of reference of the Jason-3 measurements when used to compute water level time series.
Input: The master file containing the bias to be applied to the Jason-3 measurements.
Output: Water level time series corrected for Jason-3 measurement bias.

3.2.2.4.4.3 Function 3: Application of the geoid model

Process description: Subtraction of the geoid height from the ellipsoid height previously computed.
Input:

• The master file and the mean water height calculated in Function 2.
• Geoid grid in NetCDF format.

Output: Water level time series corrected from the geoid height.

3.2.2.4.5. Quality control and diagnoses

For a given lake, if the Jason-3/Sentinel-6A bias cannot be estimated, the time series is not provided.

4. Output data

The Product User Guide and Specification (PUGS) [D4] 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. The methodology used (LWL or LWL-S) is indicated in the global attributes. Figures with the lake water level time series for each lake can be generated using the data in these files (see Figure 3 as an example);
2. The processing control data 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 products 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. Users must take these aspects into consideration when using the data.

6. Algorithm Performance Monitoring and Recording

When reading and processing the individual satellite measurements acquired 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 valued as 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.

Cartwright D. E. and Edden Anne C. (1973). Corrected Tables of Tidal Harmonics, Geophysical Journal International, Volume 33, Issue 3, September 1973, Pages 253–264, https://doi.org/10.1111/j.1365-246X.1973.tb03420.x (resource validated 12^th December 2023)

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

Messager, M.L., Lehner, B., Grill, G., Nedeva, I., Schmitt, O. (2016). Estimating the volume and age of water stored in global lakes using a geo-statistical approach. Nature Communications, 7: 13603. https://doi.org/10.1038/ncomms13603 (resource validated 12^th December 2023)

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. (2018). Advances in Space Research. Volume 62, Issue 6, Pages 1203-1225. https://doi.org/10.1016/j.asr.2017.10.051 (resource validated 12^th December 2023)

Wahr, J.M., (1985). Deformation induced by polar motion. Journal of Geophysical Research: Solid Earth, 90(B11), pp.9363-9368

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:
  LWL v5.0 and LWL-S v1.0: Product Quality Assessment Report (PQAR)
• Page:
  LWL v5.0 and LWL-S v1.0: Product User Guide and Specification (PUGS)
• Page:
  Lakes Service version 2023: Target Requirements and Gap Analysis Document (TRGAD)
• Page:
  LWL v5.0 and LWL-S v1.0: Algorithm Theoretical Basis Document (ATBD)
• Page:
  LWL v5.0 and LWL-S v1.0: System Quality Assurance Document (SQAD)