INTRODUCTION
Since the 1990s, satellite altimetry has been successfully used to continuously monitor the open oceans. Starting with ERS-1 and TOPEX in 1991 and 1992, there have always been at least two missions operating simultaneously. Since then, more than 15 other altimeter missions have followed, each equipped with altimeter sensors using different measurement techniques.
This extensive data collection provides great opportunities to monitor the Earth's water surfaces over a 30-year period. By combining data from multiple missions, good spatial and temporal resolution can be achieved. However, meaningful combination requires the availability of consistent and harmonized data. This means that the data must be standardized in terms of format, corrections and underlying reference systems before they can be combined. Calibration is also required to compensate for any systematic instrumental errors.
In order to provide a reliable data base for numerous long-term applications, DGFI-TUM has established the Open Altimeter Database (OpenADB), an easy-to-use database that provides consistent, harmonized and calibrated observations from current and historical altimeter missions. The OpenADB web portal provides users with derived scientific data products. General information on satellite altimetry missions and their observational configuration is also available. Internally, OpenADB is based on a data management called Multi-Version Altimetry (MVA). The MVA data structure allows for a fast user-defined extraction of altimeter mission data and science products. Similar concepts underlie the widely used Radar Altimeter Database System of the Delft University of Technology (; Naeije et al., 2000) and the Altimeter Database and Processing System ADS of the German Research Centre for Geosciences (GFZ; ). OpenADB differs from these data bases in the openly released data, as well as in the number of available altimeter missions, applied corrections and data processing.
A fundamental processing step within the data harmonization and calibration is a global multi-mission crossover analysis (called MMXO) following an approach developed at DGFI-TUM (Bosch et al., 2014). The MMXO estimates time- and location-dependent range corrections that compensate for systematic radial orbit errors of different altimeter missions.
In general, altimeter data can be classified into different processing levels.
- L(evel) 0 is the raw telemetered data processed by the space agencies, which is usually not available to the public.
- L(evel) 1A is the L0 data which is corrected for instrumental and geometric effects.
- L(evel) 1B data contains waveforms after the processing of L1A data.
- L(evel) 2 data are geolocated L1 data that includes additional parameters, such as geophysical corrections or models, as well as parameters derived from the retracking of altimeter waveforms, such as altimeter ranges, significant wave heights or backscatter coefficients.
- L(evel) 3 data are value-added along-track products derived from L2 data, such as sea level anomalies or sea surface heights.
- L(evel) 4 data are gridded products, based on along-track L3 data.
OpenADB's underlying MVA data base incorporates original Level 1/1B and Level 2 data which is used to compute value-added Level 3 data that are also stored in the system. These L3 data are made available to the public via the OpenADB web portal. Due to existing licence rights, the L1/L2 data in the MVA data set are not publicly available. Currently, all OpenADB products are provided as 1 Hz along-track measurements only. High-frequency data can be provided upon request. Gridded Level 4 products are also derived from MVA data. However, they are provided outside of OpenADB through various sources which are linked on the OpenADB web pages.
This paper describes OpenADB and its underlying MVA data holding. Section 2 presents the data management and the altimeter missions included in the system. Section 3 describes the science data products available in OpenADB, and Section 4 introduces the OpenADB web portal and user access to the data. A summary is provided in Section 5.
DATA MANAGEMENT
After describing the different altimeter missions and their data, we present the MVA data management developed at DGFI-TUM. It allows a uniform storage, a fast access and a fast update of the altimeter data.
Altimeter missions
For more than three decades, satellite altimetry has been used to monitor the Earth‘s surface waters, primarily the oceans, but also coastal zones and inland waters (International Altimetry Team, 2021). Over time, the number of active altimeter satellites has continued to increase and the quality of the altimeter sensors and their measurements has improved. Figure 1 shows the timeline of all altimeter missions launched since 1985. All missions for which OpenADB data are currently available are highlighted in blue. Altimeter missions marked in grey are not (yet) processed or made available due to limitations in data access (e.g. HY-2C), data quality (e.g. HY-2A), data storage (e.g. ICESat-2, SWOT) or delays in the integration process.
[IMAGE OMITTED. SEE PDF]
Altimeter missions are operated by different space agencies, and their data are disseminated through different sources (e.g. Copernicus Online Data Access, PO.DAAC, AVISO, Copernicus Services Data Hub, etc.). Due to different data formats as well as different standards, conventions and corrections applied to the data this results in inhomogeneous data sets. When integrating into MVA, these differences are taken into account and handled so that the data can later be merged consistently.
The Table 1 gives an overview of the altimeter missions and their individual characteristics.
TABLE 1 Altimeter missions currently available within OpenADB (State: October 2023).
Mission (data set) | Phase | Period | Repeat cycle (days) | Cycles | Passes | Ref |
Cryosat-2a (Baseline-D/Baseline-E) |
Nominal | 2010/07–2020/07 | 369b | 004–138 | 840/724 | ESA (2019), ESA (2020) |
Drifting | 2020/08–2023/06 | 25 | 001–043 | 722 | ||
Envisat (SGDR v2.1/SGDRv3.0) |
Nominal | 2002/05–2010/10 | 35 | 006–094 | 1002 | ESA (2018) |
Drifting | 2010/10–2012/04 | ~30 | 095–113 | 862 | ||
ERS-1 (SGDR/REAPER) |
Phase A | 1991/08–1991/12 | 3 | 002–046 | 86 | ESA (2014) |
Phase B | 1991/12–1992/03 | 3 | 047–081 | 86 | ||
Phase C | 1992/03–1993/12 | 35 | 082–101 | 1002 | ||
Phase D | 1993/12–1994/04 | 3 | 103–138 | 86 | ||
Phase E | 1994/04–1994/09 | 168 | 139–140 | n.a. | ||
Phase F | 1994/09–1995/03 | 168 | 141–143 | n.a. | ||
Phase G | 1995/03–1996/04 | 35 | 144–156 | 1002 | ||
ERS-2 (SGDR/REAPER) |
Nominal | 1995/05–2003/07 | 35 | 000–085 | 1002 | ESA (2014) |
Geosat (GDR) |
Geodetic | 1985/03–1986/09 | 23 | 001–025 | 660 | NOAA, NAVY (1991) |
Nominal | 1986/11–1989/12 | 17 | 001–068 | 488 | ||
GFO (GDR) |
Nominal | 2000/01–2008/11 | 17 | 037–222 | 488 | NOAA (2002) |
ICESat-1 (Version 34) | Nominal | 2003/10–2009/10 | 91 | 005–062 | 2709 | Zwally et al. (2014) |
Jason-1 (SGDR-E) |
Nominal | 2002/01–2009/01 | 10 | 001–259 | 254 | CNES, JPL (2016) |
Interleaved | 2009/02–2012/03 | 10 | 262–374 | 254 | ||
Geodetic | 2012/05–2013/06 | 406c | 500–537 | 280 | ||
Jason-2 (SGDR-D) |
Nominal | 2008/07–2016/10 | 10 | 000–303 | 254 | CNES, EUMETSET, JPL, NOAA (2016) |
Interleaved | 2016/10–2017/05 | 10 | 305–327 | 254 | ||
Geodetic | 2017/07–2018/07 | 17 | 001–023 | 434 | ||
Geodetic | 2018/07–2019/10 | 17 | 001–027 | 434 | ||
Jason-3a (SGDR-T/SGDR-F) |
Nominal | 2016/02–2022/04 | 10 | 000–226 | 254 | CNES (2020) |
Interleaved | 2022/04–2023/08 | 10 | 300–347 | 254 | ||
SARALa (SGDR-T/SGDR-F) |
Nominal | 2013/03–2016/07 | 35 | 001–035 | 1002 | CNES, ISRO (2021) |
Drifting | 2016/07–2023/08 | ~35 | 100–173 | 1002 | ||
Sentinel-3Aa (NTC) | Nominal | 2016/12–2023/09 | 27 | 012–103 | 770 | EU, ESA, EUMETSAT (2017) |
Sentinel-3Ba (NTC) |
Nominal | 2018/11–2023/09 | 27 | 019–084 | 770 | EU, ESA, EUMETSAT (2017) |
Sentinel-6Aa (NTC, LR/HR) |
Nominal | 2020/12–2023/02 | 10 | 004–083 | 254 | EUMETSAT (2022) |
Topex/Poseidon (GDR) |
Nominal | 1992/09–2002/08 | 10 | 001–365 | 254 | PO.DAAC (1993) |
Interleaved | 2002/09–2005/10 | 10 | 368–481 | 254 |
The measurements extracted from the original data files of the different providers are stored internally in the MVA data holding after the data have been standardized. Altimeter measurements are stored as averaged 1 Hz data, mainly used for ocean applications, and as high-frequency data, mainly used for coastal, polar and inland applications. MVA is the basis for all products provided to the public (see Section 3), but also for DGFI-TUM's Database for Hydrological Time Series of Inland Waters (DAHITI; Schwatke et al., 2015). The following section describes the MVA data structure in detail and explains how fast data access or data updating is realized.
Data structure
The MVA data structure is based purely on directories and binary files, without the need for additional software. This is essential for long-term operation and reduces dependence on external software to zero. The data structure was first implemented in the 1990s and has not been changed since then.
Before describing the details of the MVA data structure, some basic terms are introduced:
- mission (name): The mission name describes not only the name of the altimeter mission but can also provide additional information about the orbit phase, the version of the original data set and the frequency of the altimeter measurements. For example, jason3_em_f_hf contains the mission name at the beginning followed by the orbit phase em (which stands for extended mission, in this case for the interleaved orbit phase). Alternative orbit phases are gm (geodetic mission) or dp (drifting phase). This is followed by the data set version, in this case f, which stands for SGDR-F and describes the data version or processing baseline.
- cycle (number): The orbits of most Earth observation satellites have a fixed repeat cycle, for example an integer number of days after which the satellite passes over the same ground track. For altimeter missions, this can vary from 3 days to 406 days, as shown in Table 1. A cycle is completed when the satellite ground track is repeated. In this case the cycle number is incremented. For missions with long-repeat cycles or non-repeat cycles (drifting orbits), the data are stored in sub-cycles.
- pass (number): Within a cycle, the satellite orbits the Earth a certain number of times, depending on the altitude and inclination of the satellite. A pass is half a revolution, either ascending (with increasing ground latitude) or descending (with decreasing ground latitude). The pass number is incremented each time the ground latitude reaches a maximum or minimum. The maximum number of passes in a cycle for each satellite can be found in Table 1. The pass number is even for descending passes and odd for ascending passes.
The MVA data structure organizes altimeter measurements sequentially, which means that they follow the hierarchical structure of mission (name) cycle (number) pass (number). For each pass, the mission data contains numerous parameters for each individual measurement, which can be several hundred parameters depending on the mission. Instead of storing all measurements of a pass into one file, MVA stores the measurement parameters in small groups, called record files, which usually contain only a few parameters. Figure 2 shows an example of the MVA data structure and its data format. The mission (name) and cycle (number) are directories where the pass information is split and stored in record-dependent binary files. All filenames stored in the cycles directory consist of four parts (e.g. 001_002orbit.00), such as cycle number (001), pass number (002), record type (orbit) and record version (00). Splitting the information into different files is one basic idea behind the MVA concept. The major advantage is that it allows individual record parameters to be added or replaced quickly, but also allows relevant data to be read quickly without having to process large files containing irrelevant information. The MVA data structure also allows external data to be added in addition to altimeter data, such as different geoid models, sea ice classification/concentration, distance to coast information, etc.
[IMAGE OMITTED. SEE PDF]
The format and content of record files is described by so-called record maps. For example, the orbit.rmp shown in Figure 2 contains four parameters, namely longitude, latitude, height of the satellite above the reference ellipsoid and an orbit flag. All parameters can be stored as signed or unsigned integer values with a size of 1 byte, 2 bytes or 4 bytes. To reduce the hard disk storage requirements, parameters are not stored as floats or doubles. However, this requires the definition of an additional scaling factor for each parameter that must be applied when reading the data. Additionally, the unit for each parameter is specified in the record map, which is achieved by applying the scaling factor. For example, the parameter hsat has a defined scaling factor of −3 and the unit m, which means that the 4-byte unsigned integer has to be multiplied by in order to get the final height of the satellite in m as a float value.
The version numbering of each record allows the storage of different parameter versions, for example different orbit versions processed in different reference frames for orbit.rmp. The versioning of the records was eponymous for MVA and is especially useful for geophysical corrections. Often there are several versions, because not all models are applicable everywhere, or the standards have evolved. For example, the older missions like ERS-1 have different correction models for the wet troposphere than, say, Sentinel-6. For long-term analysis, such as global sea level change, consistent geophysical corrections are indispensable. Within the MVA data structure external models can easily be applied to all missions. Table 2 shows all available versions of the wet tropospheric record map tropw.rmp for Jason-3. The versions 00 and 01 are taken directly from the original SGDR-F data, while versions 05, 06 and 07 are added to MVA from external sources. The versioning of different parameters allows easy switching between models when creating derived products.
TABLE 2 Available versions for the wet troposphere record map tropw.rmp of Jason-3.
Record map | Description | Reference |
tropw.00 | rad_wet_tropo_cor from the original Jason-3 (SGDR-F) data | CNES (2020) |
tropw.01 | model_wet_tropo_cor_zero_altitude from the original Jason-3 (SGDR-F) data | CNES (2020) |
tropw.05 | Vienna Mapping Function 1 (VMF1) | Boehm et al. (2009) |
tropw.06 | Vienna Mapping Function 3 (VMF3) | Landskron and Böhm (2019) |
tropw.07 | GNSS-derived Path Delay Plus (GPD+) | Fernandes et al. (2015), Fernandes and Lázaro (2016) |
Currently, there are more than 80 record maps defined in MVA. An overview of the most commonly used record maps is given in Table 3. New record maps can easily be created for individual data sets, making the MVA data structure very flexible and extensible.
TABLE 3 Most common record maps.
Name of RMP | Description | |||||
Orbit.rmp | 000 | 4 | 13 | Orbit.rmp | ||
001 | +4 | −6 | deg | glon | Longitude of satellite footprint | |
002 | 4 | -6 | deg | glat | Geodetic latitude of satellite footprint | |
003 | +4 | −3 | m | hsat | Satellite height above ellipsoid | |
004 | +1 | 0 | - | oflags | Orbit status and quality flags | |
instr.rmp | 000 | 9 | 22 | instr.rmp | ||
001 | +4 | 0 | sec | isec | Integer seconds elapsed since epoch | |
002 | +4 | -6 | sec | msec | Microseconds, fractional part of isec | |
003 | +4 | −3 | m | ralt | Altimeter range (instrument corrected) | |
004 | +2 | -3 | m | stdalt | Standard deviation of ralt | |
005 | 2 | −2 | m | swh | Significant wave height | |
006 | +2 | −2 | m | stdswh | Standard dev. of significant wave height | |
007 | +2 | −2 | db | sigma0 | Backscatter coefficient | |
008 | +1 | −1 | m/s | windsp | Wind speed intensity | |
009 | +1 | 0 | - | iflags | Instrument status and quality flags | |
geoh.rmp | 000 | 1 | 4 | geoh.rmp | ||
001 | 4 | −3 | m | geoh | Geoid height | |
tropw.rmp | 000 | 1 | 2 | tropd.rmp | ||
001 | 2 | −3 | m | wtrop | Wet tropospheric correction | |
tropd.rmp | 000 | 1 | 2 | tropd.rmp | ||
001 | 2 | −3 | m | dtrop | Dry tropospheric correction | |
ionos.rmp | 000 | 1 | 2 | ionos.rmp | ||
001 | 2 | −3 | m | ionos | Ionospheric correction | |
tides.rmp | 000 | 1 | 4 | tides.rmp | ||
001 | 4 | −6 | m | etide | Solid Earth tide correction | |
tidep.rmp | 000 | 1 | 4 | tidep.rmp | ||
001 | 4 | −6 | m | ptide | Pole tide correction | |
tideo.rmp | 000 | 2 | 4 | tideo.rmp | ||
001 | 2 | −3 | m | otide | Ocean tide correction | |
002 | 2 | −3 | m | ltide | Ocean load tide correction |
Data reference
As mentioned, the goal of the MVA data structure is to homogenize the various space agency data sets and their parameters. A major discrepancy is the use of different location and time references for the data. Therefore, a transformation of the reference ellipsoid and, if necessary, a conversion of the reference epoch are performed.
In the original files, the coordinates of the satellites are referred to different reference ellipsoids, such as WGS84 (a = 6,378,137.0 m, f = 1.0/298.257223563) for CryoSat-2 or the Topex ellipsoid (a = 6,378,136.3 m, f = 1.0/298.257) for Jason-3. Neglecting this difference would result in a discrepancy of sea surface heights of up to 0.7 m. The MVA data structure uses the Topex ellipsoid by default and converts all locations to it. This applies to the satellite coordinates as well as to all corrections, for example the geoid.
Another inconsistency is due to the time reference epochs in the original data sets. For example, for Jason-3 or CryoSat-2 the time is given as seconds since 2000-01-01 00:00:00, for ERS-1/ERS-2 the time is given as seconds since 1990-01-01 00:00:00, and for Topex/Poseidon, the time is counted relative to the epoch 1958-01-01 00:00:00. In addition, leap seconds are handled differently for the individual missions. To homogenize the measurement time in MVA, it is stored as a continuous time (without leap seconds) since 1985-01-01 00:00:00. This reference date was chosen because Geosat is the earliest mission in MVA (Seasat, GEOS or GEOS-3 are not included). For some derived products, the time is also given in Julian days since 2000-01-01 12:00:00.
SCIENCE DATA PRODUCTS
Based on the internal MVA data structure, numerous derived L3 along-track data products are generated and made available to users via the OpenADB web portal (see Section 4.2). All products are provided as consistent along-track data in NetCDF format with all measurements already corrected using the latest geophysical models (e.g. tides and atmospheric delays). The data sets can be used without expert knowledge. Moreover, since the data from all missions have been carefully harmonized and cross-calibrated in advance (Bosch et al., 2014), it is possible to merge and combine data from different missions to improve spatial and temporal resolution. OpenADB currently provides the following six L3 products for which different versions are available.
- Sea surface heights (SSH)
- Sea level anomalies (SLA)
- Instantaneous dynamic ocean topography (iDOT)
- Empirical ocean tide model (EOT)
- Vertical total electron content (VTEC)
- ALES sea surface heights (SSH_ALES)
Different product versions may be available in case of new missions, reprocessed altimeter data from space agencies, new geophysical corrections or new models. All products are regularly updated when new altimeter missions are launched, reprocessed data becomes available, or new correction models are released.
Sea surface heights (SSH)
Sea surface heights describe the height of sea level above the reference ellipsoid. They are the basic satellite altimetry quantity for ocean applications and are calculated as follows:
The satellite height is defined as the altitude of the altimeter above the reference ellipsoid. In OpenADB, all SSH data are referenced to the TOPEX ellipsoid. The altimeter range is derived from the measured radar waveforms using dedicated retracking algorithms. The SSH product of OpenADB uses the official Level-2 altimeter ocean ranges provided by the space agencies, such as MLE4 (Dinardo et al., 2015; Gommenginger et al., 2011) and others.
Since the radar signal passes the Earth‘s atmosphere, its propagation is delayed and must be corrected. The applied geophysical corrections used in Equation 1 may vary depending on application and product version. The corrections comprise wet troposphere , dry troposphere , ionosphere , solid Earth tide , pole tide , ocean tide , loading tide , inverse barometer effect and range bias . The sources of the corrections for each SSH version can be accessed directly from the SSH product page. In general, the same geophysical corrections and models are used for all missions.
The SSH product includes the parameters shown in Table 4. Location and time of each altimeter measurement are defined by the parameters glon, glat and jday (in Julian Day 2000). The key parameter of the product is ssh, which describes the value of the sea surface height with respect to the Topex ellipsoid. In addition, three quality flags are provided for user-defined data screening. They are related to the geophysical corrections (e.g. outlier limits of applied corrections), satellite orbit (e.g. surface type or bathymetry) and instrument (e.g. quality of range and significant wave height or number of valid measurements).
TABLE 4 Parameters in the sea surface heights (SSH) product.
Parameter | Unit | Description |
glon | deg | Longitude |
glat | deg | Latitude |
jday | d | Julian Day 2000 |
ssh | m | Sea Surface Heights |
sflag | – | Geophysical Corrections Quality Flags |
oflags | – | Orbit Status and Quality Flags |
iflags | – | Instrument Status and Quality Flags |
Sea level anomalies (
Sea level anomalies describe the difference between observed SSHs and a mean sea surface height (MSSH):
SLAs are derived directly from SSHs and thus they are already fully corrected and calibrated. The MSSH model used as a reference may be different from version to version.
The data format of the SLA product includes the parameters shown in Table 5. Like above, it comprises glon, glat and jday as well as the three quality flags for geophysical corrections, satellite orbit and instrument for user-defined data screening. Parameter sla is the value of the sea level anomaly with respect to the MSSH.
TABLE 5 Parameters in the Sea level anomalies (SLA) product.
Parameter | Unit | Description |
glon | deg | Longitude |
glat | deg | Latitude |
jday | d | Julian Day 2000 |
sla | m | Sea Level Anomalies w.r.t. Mean Sea urface |
gflags | – | Geophysical Corrections Quality Flags |
oflags | – | Orbit Status and Quality Flags |
iflags | – | Instrument Status and Quality Flags |
Instantaneous dynamic ocean topography (iDOT)
The instantaneous dynamic ocean topography (iDOT), also known as absolute dynamic topography (ADT), is the along-track deviation between the instantaneous SSH and the geoid N:
The iDOT is derived using the so-called ‘profile approach’ (Bosch et al., 2013), which aims at a consistent treatment of SSH and gravity information characterized by different spectral resolutions.
Both SSH and N are consistently filtered by a Gaussian filter (Jekeli-Wahr (Jekeli, 1981)) with a half-width of about 69 km. The applied filter size depends on the maximum degree of the gravity model used. The iDOT profiles are thus smoothed snapshots of the ocean topography and characterize the temporal evolution of the DOT since late 1992. Due to the 69 km filter length, the iDOT profiles carry signatures of mesoscale ocean features and allow for analysing the evolution and kinematics of eddies and geostrophic currents. These data are already cross-calibrated and can be combined between different missions without further steps.
Table 6 shows the data format of the instantaneous dynamic ocean topography (iDOT) product. Besides glon, glat, jday and the three quality flags it provides dot as the value of the iDOT.
TABLE 6 Parameters in the instantaneous dynamic ocean topography (iDOT) product.
Parameter | Unit | Description |
glon | deg | Longitude |
glat | deg | Latitude |
jday | d | Julian Day 2000 |
dot | m | Instantaneous Dynamic Ocean Topography |
gflags | – | Geophysical Corrections Quality Flags |
oflags | – | Orbit Status and Quality Flags |
iflags | – | Instrument Status and Quality Flags |
Empirical ocean tide model (EOT)
The long time series of precise and nearly global altimeter measurements by missions with different sampling characteristics allow a comprehensive and very accurate empirical modelling of ocean tides. For many years, DGFI-TUM has been creating a series of the well-known EOT using altimetry data.
The EOT models are global solutions and include amplitudes and phases of the main tidal constituents. The latest EOT version is EOT20 (Hart-Davis et al., 2021a), published in 2021. It has been computed from TOPEX, TOPEX (EM), ERS-1C/G, ERS-2, ENVISAT, Jason-1/−2/−3 and Jason-1/−2 (EM) data acquired between September 1992 and January 2018. Particular attention has been paid to improve the modelling of the coastal regions by using special retracking methods (ALES (Passaro et al., 2014; Passaro et al., 2018)) and adapting the geophysical corrections to this region. In EOT20, the 17 tidal constituents considered and calculated are , , , , , , , , , , , , , , , and . The models were obtained by means of residual harmonic analysis of multi-mission altimeter data with respect to FES2014 (Lyard et al., 2021). The ocean tide and load tide atlases are provided with a spatial resolution of 0.125 × 0.125 degrees.
Along-track ocean tide and load tide corrections are derived from the EOT grids and are provided in OpenADB for all available satellite altimeter missions. In addition, the Level-4 grids for the tidal constituents of EOT11a and EOT20 are available via PANGAEA (Savcenko et al., 2012) and SEANOE (Hart-Davis et al., 2021b), respectively. A spherical harmonic representation is also available and can be provided on request.
Table 7 shows the data format of the OpenADB Level-3 empirical Ocean Tide Model (EOT) product. It contains glon, glat and jday of the altimeter measurements, followed by the ocean tide correction otide and the ocean load tide correction ltide from the EOT model. Additionally, orbit status and quality flags oflags are provided.
TABLE 7 Parameters in the empirical ocean tide model (EOT) product.
Parameter | Unit | Description |
glon | deg | Longitude |
glat | deg | Latitude |
jday | d | Julian Day 2000 |
otide | m | Ocean Tide Correction |
ltide | m | Ocean Load Tide Correction |
oflags | – | Orbit Status and Quality Flags |
Vertical total electron content (VTEC)
On their way through the Earth's atmosphere, the radar signals of the altimeters are delayed by free electrons in the ionosphere. By determining the signal delay, information about the electron content in the ionosphere can be derived.
Since the ionosphere is a dispersive medium, the ionospheric delay can be calculated by combining measurements at two frequencies. To reduce the measurement noise, a 20 s median filter is applied in order to smooth the ionospheric delay along the profiles. The vertical total electron content (VTEC) below the satellite is proportional to this delay (Dettmering et al., 2011). VTEC describes the number of electrons per square meter below the satellite and is given in TEC units (TECU).
The OpenADB along-track VTEC product is provided for all altimeter missions equipped with dual-frequency altimeters, namely Envisat, which is equipped with Ku-band (13.6 GHz) and S-band (3.2 GHz) altimeters, and Topex and Jason-1/-2/-3 and Sentinel-3A/B, which are all equipped with Ku-band (13.6 GHz) and C-band (5.3 GHz) altimeters.
Table 8 describes the data format of the VTEC product. Besides the geographic location (glon, glat), the geomagnetic latitude gmlat is also provided. Unlike other OpenADB products, the time is not given in Julian days, but in local time tloc. The radial ionospheric correction ionos is given in units of , and the converted values of the Vertical Total Electron Content vtec in TECU. Finally, orbit status oflags and instrument status iflags are provided, both with quality flags.
TABLE 8 Parameters in the vertical total electron content (
Parameter | Unit | Description |
glon | deg | Longitude |
glat | deg | Latitude |
gmlat | deg | Geomagnetic Latitude |
tloc | h | Local Time |
ionos | m | Ionospheric Correction |
vtec | TECU | Vertical Total Electron Content |
oflags | – | Orbit Status and Quality Flags |
iflags | – | Instrument Status and Quality Flags |
ALES sea surface heights (SSH_ALES) is a modified version of the sea surface heights product described in Section 3.1. However, unlike SSH, the altimeter range is calculated using the ALES retracker (Passaro et al., 2014). Also the sea state bias correction is updated to be consistent with the retracker applied (Passaro et al., 2018).
The Adaptive Leading Edge Subwaveform (ALES) retracker (Passaro et al., 2014) is a fitting algorithm used to improve coastal sea level estimates from satellite altimetry. For SAR altimeter missions such as Sentinel-3A/-3B, a special version of the ALES retracker called ALES+SAR (Passaro et al., 2022) is used. For ALES+SAR; however, the significant wave height is not available because the empirical retracker does not provide estimates for it. While the greatest improvement is in the coastal zones, the sea level data are also reliable in the open ocean and improve the current standards in terms of noise content.
Sea surface height data are provided at a posting rate of 1-Hz (one measurement every 7km along the track) for single missions in their nominal phase. All relevant geophysical corrections were considered to derive the SSH, including ocean tides using the EOT model (Section 3.4). However, the tidal predictions are also provided in this product in addition so that a different tidal model may be applied. The same is true for the Mean Sea Surface data from the DTU15 model (Andersen et al., 2016) to allow the derivation of SLA.
The data from all missions were cross-calibrated in advance. Since TOPEX is not included in the data set, the reference for the MMXO is Jason-1. Thus, it is possible to merge and combine the SSH of any mission in order to improve the spatial and temporal resolution. However, due to the differences in the reference for calibration and in the applied corrections, the ALES SSH should not be combined with the OpenADB SSH product (Section 3.1).
The data format of the ALES sea surface height (SSH_ALES) product is shown in Table 9. Location and time of the altimeter measurements are provided by glon, glat and jday. The key parameter of this product is the value of the sea surface height ssh, that is the ellipsoidal height with respect to the Topex ellipsoid. Other retracking parameters are the ALES normalized leading edge fitting error stdalt and the significant wave height swh. In addition, the parameters mean sea surface mssh, ocean tide correction otide and ocean load tide correction ltide are provided to enable their exchange. Since the ALES retracker was developed for coastal applications and is mainly used in these areas, the distance to the coast distance is also provided for each altimeter measurement. In addition, three quality flags for geophysical corrections, satellite orbit and instrument are provided.
TABLE 9 Parameters in the
Parameter | Unit | Description |
glon | deg | Longitude |
glat | deg | Latitude |
jday | d | Julian Day 2000 |
ssh | m | Sea Surface Heights |
stdalt | pow | Fitting Error on the Normalized Leading Edge |
swh | m | Significant Wave Height |
mssh | m | Mean Sea Surface |
otide | m | Ocean Tide Correction |
ltide | m | Ocean Load Tide Correction |
distance | km | Distance to Coast |
sflags | – | Geophysical Corrections Quality Flags |
oflags | - | Orbit Status and Quality Flags |
iflags | - | Instrument Status and Quality Flags |
DATA SUPPLY
This chapter describes the OpenADB web portal at (Section 4.1), which provides a data extraction tool and information on altimetry missions and ground tracks. Furthermore, an overview of the latest OpenADB product versions and their availability for individual altimeter missions is provided (Section 4.2) as well as the corresponding data format (Section 4.3).
The OpenADB web portal enables quick and easy user access to the data. The starting page () is displayed in Figure 3. All OpenADB data are available for free after registration.
[IMAGE OMITTED. SEE PDF]
In addition to the various L3 products, OpenADB also provides other information for users. For example, details of past, present and future altimeter missions and their orbital phases are provided. It is also possible to view the positions of all altimeter tracks and their pass numbers on an interactive map called ‘Pass Locator’. Besides the along-track products (see Section 4.2), information on global and regional sea level change is provided ().
Users can order along-track products in three steps through an interactive map shown in Figure 4. The first step is to select the desired product. Then the area of interest is selected as a rectangle or polygon on the map. Finally, the user has the possibility to define filters, such as start date, end date, pass number or cycle number. All available records are then visually displayed on the map, where the user has the option to add the selected records to the shopping cart and finally submit the order. The new order is then listed under ‘My Jobs’ where it can be downloaded after a few minutes of processing time. Completed orders are automatically deleted after 30 days.
[IMAGE OMITTED. SEE PDF]
As described in Section 3, currently six different L3 products (SSH, SLA, EOT, iDOT, VTEC, SSH_ALES) are provided through OpenADB. Not every product, however, is available for all missions. For one thing, some parameters can only be calculated for certain altimeter systems. VTEC information, for example, can only be derived from dual-frequency altimeters, and ALES retracking is not possible for all measurement systems. Second, product updates for the latest missions are successive, and not all are available immediately. For example, products such as EOT or VTEC can be delivered within days of altimeter data being provided by the space agencies. However, products such as SLA or SSH require data from other altimeter missions used for cross-calibration and external geophysical corrections, which can take weeks to months until processed and updated. Especially when a complete mission has been reprocessed by the space agencies. Geosat data cannot be cross-calibrated due to the lack of parallel missions, so only tidal information is available for this satellite. Table 10 summarizes the latest available OpenADB products by mission.
TABLE 10 Overview of the latest available OpenADB products by mission.
Mission | SSH (v40) | SLA (v40) | iDOT (v33) | EOT20 | VTEC (v06) | SSH_ALES (v55) |
Cryosat-2 | ✓ | ✓ | ✓ | ✓ | - | - |
Cryosat-2 (EM) | ✓ | ✓ | - | ✓ | - | - |
Envisat | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Envisat (EM) | ✓ | ✓ | ✓ | ✓ | - | - |
ERS-1A | - | - | - | ✓ | - | - |
ERS-1B | - | - | - | ✓ | - | - |
ERS-1C | ✓ | ✓ | ✓ | ✓ | - | - |
ERS-1D | ✓ | ✓ | ✓ | ✓ | - | - |
ERS-1E | ✓ | ✓ | ✓ | ✓ | - | - |
ERS-1F | ✓ | ✓ | ✓ | ✓ | - | - |
ERS-1G | ✓ | ✓ | ✓ | ✓ | - | - |
ERS-2 | ✓ | ✓ | ✓ | ✓ | - | - |
Geosat (GM) | - | - | - | ✓ | - | - |
Geosat | - | - | - | ✓ | - | - |
GFO | ✓ | ✓ | ✓ | ✓ | - | - |
ICESat-1 | - | - | - | ✓ | - | - |
Jason-1 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Jason-1 (EM) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Jason-1 (GM) | ✓ | ✓ | - | ✓ | ✓ | ✓ |
Jason-2 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Jason-2 (EM) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Jason-2 (GM1) | ✓ | ✓ | - | ✓ | ✓ | - |
Jason-2 (GM2) | ✓ | ✓ | - | ✓ | ✓ | - |
Jason-3 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Jason-3 (EM) | - | - | - | ✓ | - | - |
Poseidon | ✓ | ✓ | ✓ | ✓ | - | - |
SARAL | ✓ | ✓ | ✓ | ✓ | - | ✓ |
SARAL (DP) | - | ✓ | - | ✓ | - | ✓ |
Sentinel-3A | ✓ | ✓ | - | ✓ | ✓ | ✓ |
Sentinel-3B | ✓ | ✓ | - | ✓ | ✓ | ✓ |
Sentinel-6A (LR) | - | - | - | ✓ | - | - |
Sentinel-6A (HR) | - | - | - | ✓ | - | - |
Topex | ✓ | ✓ | ✓ | ✓ | ✓ | - |
Topex (EM) | ✓ | ✓ | ✓ | ✓ | ✓ | - |
Format description
The custom data extracts are provided for download as compressed tar.gz archives. The filename of each job contains the job_id, mission, product name and product version (e.g. 004686_jason2_sla_33.tar.gz). The data in the archive is stored in a hierarchical order, containing directories for each cycle and the associated pass files within them. The file structure is shown in Figure 5. The extracted altimeter data from each pass file is provided in NetCDF
[IMAGE OMITTED. SEE PDF]
The general structure of all NetCDF files is identical. They differ only in the number and type of product-dependent parameters. First, the NetCDF has an attribute dimension that indicates the number of altimeter observations in the file. Then, each parameter is stored in a variable with additional attributes such as unit, description, etc. Mission, cycle number and pass number are also stored as global attributes. Figure 6 shows an example of an SLA product file.
[IMAGE OMITTED. SEE PDF]
SUMMARY
DGFI-TUM's Open Altimeter Database OpenADB disseminates various along-track L3 altimetry products. These are consistently calculated, harmonized and cross-calibrated. This article presented the underlying internal Multi-Version Altimetry (MVA) data holding as well as the OpenADB webpage and the data sets available there, including their formats and access options.
Currently, OpenADB provides the following data sets: sea surface heights (SSH, Section 3.1), sea level anomalies (SLA, Section 3.2), instantaneous dynamic ocean topography (iDOT, Section 3.3), empirical ocean tide model (EOT, Section 3.4), vertical total election content (VTEC, Section 3.5) and ALES sea surface heights (SSH_ALES, Section 3.6).
Custom data extraction of OpenADB L3 data can be performed through an interactive map that allows users to filter searches by area and time. The expertise built into the products makes the database a valuable tool for providing easy access to altimeter data for users with little background knowledge in satellite altimetry.
The efficient data management within the MVA allows files to be added and extracted quickly and easily. It provides flexible data access for internal and external use, as well as regular updates and upgrades of data and products.
OpenADB is available at . The OpenADB products are updated on a regular basis as reprocessed data, new geophysical corrections or new models become available. New missions are integrated successively as data become available.
ACKNOWLEDGEMENTS
All products are computed based on altimetry missions operated by NASA/CNES (TOPEX, Jason-1), ESA (ERS-1/2, Envisat, Cryosat-2), USNavy (Geosat, GFO), CNES/NASA/EUMETSAT/NOAA (Jason-2, Jason-3), ISRO/CNES (SARAL), EUMETSAT (Sentinel-3A/-3B) and NASA/EUMETSAT (Sentinel-6A). The original data are disseminated by AVISO, ESA, EUMETSAT, NOAA and PO.DAAC. Open Access funding enabled and organized by Projekt DEAL.
FUNDING INFORMATION
Open access funding enabled and organized by Projekt DEAL.
OPEN RESEARCH BADGES
This article has been awarded Open Data Badge for making publicly available the digitally-shareable data necessary to reproduce the reported results. Data is available at ().
DATA AVAILABILITY STATEMENT
All OpenADB products related to this work are freely available on the OpenADB web portal ().
Andersen, O.B., Stenseng, L., Piccioni, G. & Knudsen, P. (2016) The DTU15 MSS (mean sea surface) and DTU15LAT (lowest astronomical tide) reference surface. ESA living planet symposium 2016, Prague, Czech Republic, 9–13 May 2016.
Boehm, J., Kouba, J. & Schuh, H. (2009) Forecast Vienna mapping functions 1 for real‐time analysis of space geodetic observations. Journal of Geodesy, 83(5), 397–401. Available from: [DOI: https://dx.doi.org/10.1007/s00190-008-0216-y]
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer
© 2024. This work is published under http://creativecommons.org/licenses/by/4.0/ (the "License"). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.
Abstract
For more than three decades, satellite altimetry has provided valuable measurement data for the monitoring and analysis of ocean and inland water surfaces. Since 1992, there have always been at least two simultaneous missions providing continuous measurement data, starting with TOPEX/Poseidon and ERS‐1 in the early 1990s and continuing with about 10 satellites active today, including ICESat‐2, Sentinel‐6A and SWOT. Most mission data are freely available, but in different formats, processing levels and with respect to different references (e.g. ellipsoid or time), making common multi‐mission applications difficult. In addition, the derivation of ready‐to‐use and high‐quality scientific products requires expertise that not every user is willing to acquire. Over the years, DGFI‐TUM has developed and maintained an Open Altimeter Database (OpenADB) that allows consistent data management and combination. It consists of the internal Multi‐Version Altimetry (MVA) data repository and the OpenADB web portal. OpenADB provides user‐friendly access to derived along‐track products, such as sea surface heights and ocean tides. It also provides general information about the satellite altimetry missions, their observing configurations and about the data provided in the database. All products are freely available on the OpenADB web portal (
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer
Details








1 Department of Aerospace & Geodesy, School of Engineering & Design, Deutsches Geodätisches Forschungsinstitut (DGFI‐TUM), Technical University of Munich, München, Germany