A Software Tool for ICESat and ICESat-2 Laser Altimetry Data Processing, Analysis, and Visualization: Description, Features, and Usage

Abstract

This paper presents a web-based software tool designed to process, analyze, and visualize satellite laser altimetry data, specifically from the Ice, Cloud, and land Elevation Satellite (ICESat) mission, which collected data from 2003 to 2009, and ICESat-2, which was launched in 2018 and is currently operational. These data are crucial for studying and understanding changes in Earth’s surface and cryosphere, offering unprecedented accuracy in quantifying such changes. The software tool ICEComb provides the capability to access the available data from both missions, interactively visualize it on a geographic map, locally store the data records, and process, analyze, and explore the data in a detailed, meaningful, and efficient manner. This creates a user-friendly online platform for the analysis, exploration, and interpretation of satellite laser altimetry data. ICEComb was developed using well-known and well-documented technologies, simplifying the addition of new functionalities and extending its applicability to support data from different satellite laser altimetry missions. The tool’s use is illustrated throughout the text by its application to ICESat and ICESat-2 laser altimetry measurements over the Mirim Lagoon region in southern Brazil and Uruguay, which is part of the world’s largest complex of shallow-water coastal lagoons.

1. Introduction

Satellite laser altimetry is an active, non-imaging remote sensing technique for Earth observation that uses precise laser measurements of a satellite’s altitude over Earth’s surface. It is employed to monitor, study, and understand Earth’s surface, coverage, geometric shape, spatial orientation, and gravitational field, as well as how these change over time. This remote sensing technique is also used to study other planets and moons.

Handling, processing, visualizing, and analyzing the massive amounts of data produced by satellite laser altimetry missions are difficult and challenging tasks. Moreover, despite the high precision of laser altimetry measurements and the vast potential applications of satellite laser altimeter data, there is a lack of specific software tools for the integrated execution of such tasks that provide access to data based on geographical location of collection and allow adequate exploration of the enormous volume of collected raw data, particularly that collected by the ICESat [1] and ICESat-2 [2] satellite missions.

The existing HDF5 APIs allow the development of ad hoc tools that can access the raw data contained in the HDF5-formatted ICESat and ICESat-2 data products but do not provide direct access to the data files of these satellite laser altimetry missions. In turn, the visual software tools available to access HDF5 data, despite allowing access to the ICESat and ICESat-2 data products and providing some representation capabilities, are very limited and represent the most basic way of accessing the laser altimetry data from both missions [3].

The National Snow and Ice Data Center’s (NSIDC) custom user interface for accessing remote sensing data from multiple satellites and sensors [4], including ICESat/GLAS [5] and ICESat-2/ATLAS [6], is also quite limited and offers only a few options and services, such as data filtering and subsetting, whereas NASA’s Earthdata Search web application [7], despite having more options and services, is only intended to provide tools for data searching, filtering, and subsetting in order to facilitate the download of satellite data products.

The OpenAltimetry platform [8], developed as part of a NASA-funded project involving multiple institutions and universities, enables the visualization of ICESat and ICESat-2 altimetry data through a web-based interactive interface that overlays the data on a map, showing the precise locations where it was collected [9]. However, by focusing exclusively on laser range measurements, this software tool leaves out access to many other important information and parameters that are also contained in the data products of both satellite laser altimetry missions.

To address this gap, this paper presents ICEComb, a web-based software tool developed to display data from both missions on top of a highly detailed web mapping service based on the geographic location from which data was collected and to present all of the data contained in the data products in a meaningful way. This means that this tool allows to access the raw data within the datasets and present it in a rich, geographically connected environment utilizing visual aids such as graphs, tables, and data conversions. It also permits the selection and processing of laser altimetry data using well-documented methodologies, as well as statistical data analysis and data export, thereby providing an integrated software environment for the analysis and interpretation of satellite laser altimetry data.

This approach simplifies knowledge correlation and the formulation and evaluation of scientific models derived from such data. After all, when working with satellite remote sensing data, the data are only half of the equation, and having the ability to quickly and precisely identify the location and easily characterize its surroundings while having direct access to the data being able to process them is crucial for obtaining valid results and for creating, interpreting, and verifying scientific models based on such data.

The use of the main visualization and data processing capabilities of the ICEComb tool is illustrated throughout the text by its application to satellite laser altimetry measurements over the Mirim Lagoon in South America, shared among Brazil and Uruguay, which is part of the world’s largest complex of shallow-water coastal lagoons [10].

The structure of this paper is as follows. The ICESat and ICESat-2 laser altimetry satellite missions are briefly addressed in Section 2. Section 3 provides a brief synopsis of the software tools available for the processing and visualization of satellite laser altimetry data. The ICEComb tool is presented in Section 4, where its architecture, functionalities, and features are described, and details on the tool’s implementation and evaluation are also presented. Additionally, this section provides illustrative examples of the ICEComb tool’s usage. Finally, the main conclusions are presented in Section 5.

2. The ICESat and ICESat-2 Satellite Altimetry Missions

The experimental scientific satellite ICESat (an acronym for Ice, Cloud, and Land Elevation Satellite) was launched in January 2003 as part of the National Aeronautics and Space Administration’s (NASA’s) Earth Observing System (EOS). The satellite operated for seven years in a 600 km orbit with a 94° inclination [1], two years longer than the original five-year mission goal, and was retired in February 2010 after completing 19 successful laser-operations campaigns [11], with the last valid data collected in October 2009.

The primary instrument onboard the ICESat satellite was the Geoscience Laser Altimeter System (GLAS) [5,12], consisting of three different lasers that operated sequentially throughout the mission, each one at a time, supported by a dual-frequency Global Positioning System (GPS) receiver [13] and a custom star-tracker attitude determination system [14]. This instrument was the first spaceborne laser-ranging (LiDAR) system engineered for continuous, near-global monitoring of the Earth, encompassing latitudes from 86° N to 86° S.

The three GLAS lasers emitted short pulses of 4 ns with a repetition frequency of 40 Hz at wavelengths of 1064 nm (near-infrared light, used for surface altimetry and measurement of dense cloud heights) and 532 nm (visible green light, used for profiling atmospheric clouds and aerosols) [15], and operated intermittently, having been fired only at strategic time periods due to the operational and energy constraints resulting from the premature failure of the first laser and the rapid energy decline of the second [5].

Thanks to the laser’s small footprint (∼70 m), the GLAS altimeter provided high-accuracy Earth surface elevation data with few corrections required. Although the satellite’s primary goal was to continuously monitor ice elevation changes on both Greenland and Antarctica [1], the data obtained have been widely used for purposes other than those originally intended. A variety of application fields such as ice sheet elevation, land topography, cloud and aerosol height distribution, vegetation canopy characteristics and height, surface reflectivity [16], urban environment monitoring [17], and water level monitoring in rivers and natural and artificial lakes [18,19] indicate the breadth of applicability of the ICESat laser altimetry data.

Following the groundbreaking success of the first ICESat mission, a follow-up satellite laser altimetry mission, ICESat-2 [2,20], was launched in September 2018. The ICESat-2 satellite orbits the Earth in a sun-synchronous, near-circular, near-polar orbit with a mean altitude of 496 km with a 92° inclination. The satellite’s orbit has a 91-day repeat cycle with a ground-track separation of ∼28.8 km at the equator.

The satellite carries an updated and more capable LIDAR instrument named ATLAS, an acronym for Advanced Topographic Laser Altimeter System [21], which is currently operational. This instrument, consisting of a multibeam 532 nm (green) laser and single-photon-sensitive detectors used for range determination [22], provides a measurement concept different from the LiDAR on ICESat, providing a faster repetition rate of 10 kHz, resulting in a separation of about 0.7 m between data points along the satellite track [23], compared with about 170 m for the previous mission, in addition to using much lower energy pulses [24]. The nominal ground footprint of the laser pulses is ∼17 m in diameter [25], which could increase to about 20 m after the end of the 3-year nominal mission [26] due to the decrease in laser energy.

Each transmitted laser pulse is also split into six separate beams, organized into three pairs separated by about 3.3 km cross-track, each pair consisting of a strong and a weak beam with an interbeam spacing of ∼90 m and an energy ratio of about 4:1 [27]. This configuration provides a multi-beam profiling of the Earth’s surface between 88° N to 88° S, enabling accurate measurement of local cross-track slopes [2] as well as dense spatial sampling along tracks, resulting in more reliable and accurate elevation measurements and improved observations of the changes in the Earth’s surface.

The primary scientific goal of ICESat-2 is to succeed the ICESat mission and continue to quantify changes in Earth’s ice sheets, glaciers, sea ice, and vegetation [20]. Having the first mission as an example, many new scientific results and models will certainly emerge from the utilization of ICESat-2 data. Research carried out in regions with scarce or nearly non-existent in situ measurements, such as remote areas of Africa and the interior of the Amazon, can greatly benefit from the data provided by this near-global satellite mission. An example of this is the potential application of ICESat-2 laser altimetry data for hydrological studies, in particular to study the water-level fluctuations in lakes, reservoirs, and rivers located in remote areas of different continents. Such data could also potentially be used to study dust atmospheric transport and air quality in regions affected by dust storms from the Sahara and Sahel deserts, such as the part of the North Atlantic Ocean corresponding to the biogeographical region of Macaronesia [28], which includes the archipelagos of the Azores and Madeira and the Canary Islands.

When comparing satellite radar and laser altimetry data, it is observed that laser altimetry offers higher precision and accuracy data due to its finer range bin resolution. Over Greenland’s ice sheet, for example, the laser elevation measurements from ICESat/GLAS have a precision of 14 to 59 cm, in comparison with a precision of 28 cm to 2.06 m of the Envisat radar altimeter measurements [29]. Very accurate measurements are also obviously obtained with the ATLAS instrument. Inland water-level measurements provided by ICESat-2, for instance, typically have an RMSE within 6 cm and an R value higher than 0.95 when compared to in situ water level data [22].

Data collected from the ICESat and ICESat-2 missions have been pivotal in numerous scientific studies, significantly advancing understanding of Earth’s cryosphere and other environmental changes [11,30]. For example, data from both missions have been successfully used in various fields such as hydrology and coastal studies (ICESat: [18,19,31,32,33,34,35,36]; ICESat-2: [37,38,39,40,41,42,43,44,45]). Forest biomass estimation studies have also benefited from both missions (ICESat: [46,47]; ICESat-2: [27,48,49,50]). Urban monitoring is another area where these datasets have been valuable (ICESat: [17,51]; ICESat-2: [52,53,54,55]). Additionally, several studies have successfully combined data from both missions (e.g., [56,57,58,59,60]), leveraging the strengths of both datasets to provide a more comprehensive analysis of temporal and spatial changes on Earth’s surface.

3. Related Software Tools

Handling and adequately visualizing the huge volume of data produced by the ICESat and ICESat-2 satellite missions is a challenging task that can benefit from the use of a software tool that allows visual navigation of the data products in a fast and efficient way.

However, while there are some applications and application programming interfaces (APIs) that allow to perform some handling of such data, briefly described below (see also the comprehensive overview and comparison in [3]), there is a clear lack of tools to access, visualize, and appropriately explore the enormous amount of satellite laser altimetry data available, which motivated the development of the software tool described in this paper.

3.1. HDF5 APIs and Visualization Tools

In the latest versions of the ICESat data products, NASA has decided to abandon the distribution of files in binary format and instead adopted the use of HDF (Hierarchical Data Format) version 5—or simply HDF5. This decision was due to the fact that various future satellite missions, including ICESat-2, would also use the HDF5 file format in order to facilitate data interoperability [61,62,63].

HDF files are self-describing, allowing the interpretation of their content without external sources of information, as it is possible to associate metadata with each of the internal structural components [64]. This is an open format that is widely supported by a large community, and its storage mechanism is considered fast, scalable, and versatile.

Even though there are some tools available to access ICESat and ICESat-2 data products, especially the HDF5 files that support them, these tools usually only grant access to the raw data in the files but do not offer any type of visual representation of the data itself (aside from the possibility of generating simple charts, in some cases) or the possibility to view the location where the data was gathered.

This last feature is very important, as having a fast and straightforward way to contextualize the geographic location of the sampled data are an important resource to correctly interpreting, selecting, and validating satellite data.

The official application programming interface (API) for processing HDF5 files is called the HDF5 API (version 1.6). It was developed by the HDF Group [65], a non-profit organization that aims to create scientific data file formats based on architecture-independent software libraries. Acting as a software data layer and exposing a collection of routines to access the data in the HDF5 file, software developers can use this API to create custom software tools that access the ICESat or ICESat-2 data.

The HDFql (Hierarchical Data Format query language) API version 2.5.0 is based on the original HDF5 API [66] and works in the same way, meaning that it is used to interface with the HDF5 data directly. Nonetheless, this API is the first data interface that allows access to HDF5 data through a high-level language and enables data queries using a syntax analogous to SQL (Structured Query Language).

The main goal of HDFql is to lower the complexity associated with processing HDF5 files and their data. Since it utilizes a declarative language, developers can concentrate on what data to get rather than how to get the data. In comparison, the official HDF5 API is a low-level language composed of more than 400 functions, where this complexity has been one of the biggest challenges in creating applications for processing HDF5 data.

On the other hand, the HDFView application version 3.3.2 [67] is a visualization software tool recommended by the National Snow and Ice Data Center (NSIDC) for accessing raw data from ICESat and ICESat-2 data products. It uses the HDF5 API to handle the file access, while allowing users to browse data using a spreadsheet-like presentation and providing the capability to create plots and render images. HDFView requires Java SE Runtime Environment to run and is released under an open source license.

Other software tools provide data access and presentation functionalities similar to HDF5View, such as Panoply Data Viewer version 5.4.0 [68], HDF Explorer version 1.4.033 [69], and ViTables version 3.0.2 [70].

The HDF5 data visualization software tools previously addressed are the most basic form of accessing data collected by ICESat and ICESat-2. They allow to access the original data of each mission’s data product, including its metadata, but these tools only provide a limited set of general features, such as data search, filtering, subsetting, and simple data visualization, lacking the offer of specific features for handling satellite data.

3.2. NASA’s Earthdata Search Client and NSIDC UI

The National Ice and Snow Data Center (NSIDC) is an information, storage, and distribution center for various scientific data about the polar regions and the cryosphere [71]. NSIDC is part of the Cooperative Institute for Research in Environmental Sciences (CIRES) at the University of Colorado Boulder and serves as one of NASA’s Distributed Active Archive Centers (DAAC), responsible for archiving and distributing data from old and current satellite missions [72]. The main remote sensing data served by NSIDC DAAC comes from sensors present on polar orbiting satellites [73], including ICESat and ICESat-2.

Access to the satellite data products is done through a custom user interface labeled NSIDC Data Access UI, which provides satellite data products filtering options such as by date range, spatial boundaries, and polygonal map overlay selection, and other services such as data product subsetting. There is no option to access the data in the data products.

NASA’s Earth Observing System Data and Information System (EOSDIS) [74] is a core function of the Earth Science Data System (ESDS) program for managing and distributing data from Earth observation satellite missions. Some of its core services consist of data management, archiving, and distribution, in addition to user support.

The NSIDC DAAC is a key component of EOSDIS and collaborates with eleven other distinct DAACs, each responsible for archiving and distributing data related to different Earth science disciplines.

EOSDIS utilizes a web-based client called Earthdata Search (version 24.3.3-6) [7], which allows users to access a wide range of datasets from diverse sources, including ground-based platforms, aircraft, and satellites, notably featuring the ICESat and ICESat-2 laser altimetry datasets. Some of the services provided include a powerful data search and filtering system, access to detailed descriptions of data products, visualization of ground tracks on an interactive geographic map, and data ordering and downloading.

The EOSDIS Worldview client software version 4.30.0, also from NASA [75], is a complementary tool to the Earth Data Search web application. This software tool can be used to explore and retrieve high-resolution remote sensing imagery from a large number of satellite imagery products available through NASA’s Global Imagery Browse Services (GIBS) [76,77].

Regarding the availability of laser satellite altimetry data, EODIS Worldview only provides access to information about the spatial coverage of the ICESat-2 satellite, such as satellite ground tracks and overpass time, and forwards any data product downloads to the Earthdata Search site.

The primary purpose of the NSIDC UI and the Earthdata Search application is to provide users with access to advanced filtering, searching, and subsetting tools in order to enable data discovery and allow geographic/spatial filtering with a view to facilitating the downloading of data products.

Both tools provide some sort of data visualization but are limited to showing general geographic data representing only the satellite’s spatial coverage. Earthdata Search is more advanced than the NSIDC UI and allows access to the granules’ metadata and the data that allows representing the terrestrial projection of the satellite’s orbit on a map. However, as the data collected by satellite instrumentation cannot be accessed by these tools, tasks such as data processing or analysis cannot be performed directly.

3.3. OpenAltimetry Platform

The OpenAltimetry platform version 3.2 [8,9] is a web-based interface that overlays altimetry-specific data from the ICESat and ICESat-2 missions onto an interactive geographic map. This platform was created as part of a collaborative project, funded by NASA, that involved the National Snow and Ice Data Center, Scripps Institution of Oceanography, UNAVCO Consortium, and San Diego Supercomputer Center [8].

The purpose of this tool is to simplify the visualization and discovery of ICESat and ICESat-2 elevation data in an engaging way through its geographic location [8,78], without relying on external tools or having to process multiple and scattered data product files. Originally, it only supported data products from the ICESat satellite mission but later included support for ICESat-2 data.

Users who are unfamiliar with the structure of the data products from ICESat and ICESat-2 may find it difficult to navigate the different datasets. The OpenAltimetry platform made it possible to overcome this difficulty and facilitate access to data products while using an interactive geographic map as a visual environment to reference and display data.

This tool also provides some data analysis functions by offering access to some data related to the altimetric information and presenting it as plots, for example.

However, since OpenAltimetry only focuses on certain altimetry-specific data, it excludes access to many other significant parameters contained in the ICESat and ICESat-2 data products, including data on vertical atmospheric segments, cloud layers and aerosols, backscatter and reflectivity, optical depth, planetary boundary layer height, altimetry corrections, and other auxiliary parameters.

Thus, in order to have access to these data, users must use third-party software tools, which work outside the scope of the platform, thus losing one of the main advantages of the OpenAltimetry platform, which is allowing access to information and overlaying and visualizing data on an interactive map.

3.4. Other Software Tools

Some software tools designed for processing and analyzing ICESat and ICESat-2 altimetry data for hydrological applications are briefly described below. These tools offer distinct capabilities and functionalities, ranging from data extraction and visualization to water level time series analysis and water surface slope estimation.

3.4.1. ICESatProcessor

The ICESatProcessor (Initial Release) [34,79] is a MATLAB-based tool for extracting and visualizing ICESat altimetry data over inland water bodies. It processes the GLAH14 [80] data product from the ICESat mission to estimate water levels. The tool requires manual input for study area limits, third-party software for region delineation, and pre-determination of satellite pass dates. Its visualization is limited to the predefined study area, and it outputs data in plain text format.

Nevertheless, the ICESatProcessor tool has limitations, including lack of access to raw data, restricted visualization capabilities, and dependence on external tools for comprehensive analysis. Despite these constraints, it can be useful for specific hydrological studies where traditional in situ measurements are unavailable or scarce.

3.4.2. WT4I2 Tool

The WT4I2 tool version 0.1 [81] is an R-based application to extract river water level time series from the ICESat-2 ATL13 [82] data product. It processes ATL13 segments within river boundaries, using cloud flags to remove invalid observations and median values to improve the accuracy of water level estimations.

The tool automates data extraction from multiple HDF5 files within the R environment, ensuring efficient data handling. It handles a large number of parameters present in ATL13 HDF5 files, allowing user-defined selection and filtering. While effective, it necessitates a certain level of technical proficiency in the R programming language for optimal use.

3.4.3. IceSat2R Package

IceSat2R version 1.0.5 [83] is an R package that interfaces with the OpenAltimetry API to access and process ICESat-2 altimeter data. It supports multiple data products, including ATL03 [84], ATL06 [85], ATL07 [86], ATL08 [87], ATL10 [88], ATL12 [89], and ATL13. The package includes functions to retrieve Reference Ground Tracks (RGTs), orbit information, and actual altimeter data for user-defined areas of interest and time periods.

The tool provides both programmatic and interactive methods for selecting study areas, with options to use predefined global grids or custom boundaries. It includes functions for verifying RGTs, extracting data for specific dates or time intervals, and visualizing results. IceSat2R requires a geospatial R setup and offers flexibility in handling the OpenAltimetry API’s spatial constraints through its built-in Shiny application, allowing users to efficiently manage and analyze ICESat-2 data within the R environment.

3.4.4. ICE2WSS Package

ICE2WSS (ICESat-2 Water Surface Slopes) version 1.0 [90] is an R package that estimate river water surface slopes (WSS) using ICESat-2 ATL13 water surface elevation (WSE) data. The tool processes ICESat-2 data by assigning WSE measurements to the nearest river nodes from the SWOT River Database (SWORD), filtering out outliers, and performing linear regression to estimate slopes along the river centerlines. ICE2WSS allows users to specify multiple settings to customize the processing, making it suitable for a variety of hydrological applications. The package facilitates automated processing of large datasets, significantly reducing the time required to derive WSS estimates from satellite altimetry measurements.

The ICE2WSS tool can handle rivers wider than 50 m and water surface slopes greater than 0.6 cm/km. However, it has limitations due to cloud coverage and the update frequency of the SWOT database, which affect data availability and accuracy. Despite these limitations, the tool is reliable, providing useful slope data that can be used to improve hydrological models and support a variety of water-related studies.

3.4.5. Giovanni System

Giovanni (Goddard Earth Sciences Data and Information Services Center Interactive Online Visualization and Analysis Infrastructure) version 4.40 [91] is a web-based application designed for the visualization, analysis, and access of Earth science remote sensing data. The tool features a user-friendly interface that supports the visualization of a wide array of satellite-derived datasets, including atmospheric, oceanic, land, hydrologic, cryospheric, and other environmental data. Users can create custom data processing and visualizations, such as maps, time-series plots, animations, and other graphical representations, to explore spatial and temporal patterns within the data.

The Giovanni system enables researchers to interactively analyze data from various sources, enhancing their ability to study complex environmental processes. While the tool leverages data products from climate models, ground-based observations, and a wide range of NASA Earth-observing missions, it does not explicitly indicate support for direct access to data from the ICESat or ICESat-2 missions.

4. The ICEComb Tool

The ICEComb tool version 1.1.2 [92] is primarily a data processing, analysis, and visualization tool for the laser altimeter data originated from the ICESat and ICESat-2 missions. However, it can be expanded to handle data from other satellite laser altimetry missions.

This tool provides a rich web-based visual environment based on the Google Maps API [93] graphical component, so users can access updated satellite imagery, high-detailed aerial photography, and high-resolution low-altitude images—in some areas down to the street level—and at the same time providing high performance. These factors are essential for discovering and interpreting data obtained through satellites.

4.1. Tool Description and Architecture

The design and implementation of the ICEComb tool were elaborated using standardized languages and open-source software to facilitate updates and the possibility of expansion, such as the integration of new models that, coupled with the ICESat and ICESat-2 data, enrich the context of studies.

The ICEComb tool’s architecture is composed of two main components: a Data Server that handles the data query and access, and a Web Engine that interacts with the user via a Web Browser, as shown in Figure 1. This client/server approach [94] allows for the sharing of processing requirements and grants better overall performance.

The Data Server actions are limited to data file handling operations such as filtering, querying, and gathering data, while all other activities related to the handling of data requests and responses and data presentation and analysis, as well as other user interface tasks, are completely offloaded to the client side of the application.

The Data Server was designed with the RESTful architecture pattern [95] in mind, so requests are made through the use of JavaScript URI libraries, payloads are formatted in JSON (JavaScript Object Notation), and the server does not maintain the client’s state information. The ICESat and ICESat-2 data files are stored in the original HDF5 format, simplifying the data update and server’s deployment since no additional database is used.

The fact that the HDFql API implements a syntax that is similar to SQL, a high-level declarative language and a standard for query languages, made this the chosen API to handle the data files instead of the official HDF5 API, mainly due to its low level of abstraction. This choice was also intended to simplify the future development of the application. Additionally, at its core, the HDFql API does not implement new low-level methods for accessing the HDF5 files; instead, it is based on the official HDF5 API, so it natively offers very high compatibility and performance levels.

The ICEComb server was developed using C# language in the .NET Framework version 4.8 and in the x64-bit architecture.

Figure 2 illustrates the ICEComb Client user interface, which is composed of two main areas, the map on the left and the input controls on the right, grouped in three tabs with information and options about the ‘Data selection’, client ‘Options’, and ‘Data Processor’.

By having the ICEComb Client developed in JavaScript, a core technology for the web, the ICEComb solution is able to offload some computation to the client side. This approach relegates all data access and processing operations to the data provider (server), leaving the client portion of the system responsible to handle all user interface aspects, such as data requests, aggregation, map display, and data representation.

4.2. Tool Functionality, Features, and Implementation

This subsection provides a detailed overview of the ICEComb tool’s core functionalities, key features, and underlying implementation. It aims to elucidate the tool’s operation, benefits, and technical aspects.

4.2.1. Geospatial Visualization Area

Using the Google Maps API on the client side offered the possibility to use different map view formats, such as Google Earth satellite images and a geographic map featuring elevation contour lines, and access to a set of other tools in the form of Google Client Libraries with APIs such as Distance Matrix and Elevation. The first one allows to calculate the distance between geographic coordinates, while the second provides elevation data for the Earth’s surface and depth for the ocean floor. When the exact elevation is not available for a given location, the Elevation service interpolates data from four nearest locations and returns its average. The functionality is also available anywhere in the map by simply clicking on a location, and the tool displays its elevation and the corresponding latitude and longitude coordinate, as shown on Figure 3.

Additionally, compared with other map libraries, the Google Maps API provides enhanced location tags (such as country, capital, ocean, and lake names), national border outlines, road information, and search capabilities—all this without relying on external third-party libraries.

Figure 3 also highlights a very useful functionality available on the ICEComb interface that is the possibility to search and jump to any locations in the world map. This allows to execute general searches, such as for countries, capitals, regions, and streets, but also more specific elements, such as watercourses, lakes, basins, oceans, mountains, etc.

As visible in Figure 2, the first tab is the Data Selection tab and contains the data selection and filtering options. Users start by selecting the data product to display (i.e., the satellite mission and desired dataset) and optionally a date interval filter.

Then there is the Data Granules Management system that allows users to set the allocation of the amount of data granules that are processed each time. Granule files can be browsed either in batches or all at once. The parameters defined here have a high impact on performance.

The Options Tab, visible in Figure 4, contains the general UI options for the ICEComb Client that are common to both satellite missions and all datasets. In this area, users can control the behavior of the user interface, the marked elements on the map, as well as view and define various parameters related to the data handling, map parameters, and tool behavior.

4.2.2. Map Navigation Boundary System

One part of the mechanism created to limit, and thus optimize, the amount of data sent by the ICEComb server and therefore the quantity of data processed by the ICEComb client is called Map Bounds (or map bounding area). This works by defining two geographical locations, the southwest and the northeast location points (with latitudinal and longitudinal values), and those are used to instruct the ICEComb Server to exclude any data point outside the area defined by those two locations.

The default geographic bound mechanism is the ‘Map Bounds’, meaning that the southwest and northeast points are automatically determined from the map. But users can also manually set both the bound points by changing the Bound Mechanism to ’Shape Bounds’ and then draw a rectangle on the map to define the valid area for location coordinates. The process is analogous to the Map Bounds system, that is, is also based in the area defined by the southwest and the northeast points, but this time obtained from the drawn shape.

When selected the ‘Shape Bounds’ option, a set of controls are displayed in a toolbar on the top-center area of the map (replacing the ‘Search Places’ text box) and allow the execution of three actions: moving the shape (hand icon), drawing the shape (square icon), and eliminating the shape (‘X’ icon), as presented in Figure 4. After the shape is drawn, in addition to being able to move it around the map, the user can also change its size by dragging on one of the circle controls in the shape’s limits.

4.2.3. Ground Track Representation

The ground track representation in ICEComb is defined by the coordinates of the granule data (i.e., the coordinates of the collected data) rather than by an estimated satellite path. This means that the represented ground tracks represent the actual laser’s track. Each track is depicted in a distinct color, with one color assigned to each data granule. This technique was adopted so that the ICEComb tool had a visual representation approach centered on the collected data, meaning that users can quickly identify, at any time, the surface data path and the granule file that originated it.

Other options available for the ground tracks include the possibility to toggle on and off the display of the tracks and an option to show the track direction. When this option is active, arrows indicating the direction are added along the track based on the satellite heading for that specific granule.

To help characterize the ground elevation underneath a track, the ICEComb tool can produce a 256-sample ground elevation plot, as shown on Figure 5 below the map area, by simply clicking on the desired track line. The plotted track is marked with a thicker blue line indicating the plotted direction, which is also based on the satellite heading for that track. Data for this functionality are obtained from the Google Elevation Service.

The ground track representation mechanism is identical for both ICESat and ICESat-2 data products. The main distinction is that each data product from the ICESat mission contains data for a single ground track, while the split of the laser beam in the ATLAS altimeter in the ICESat-2 mission generates three or six ground tracks, depending on the data product.

The ATL04 [97], ATL09 [98], and ATL11 [99] will generate three tracks due to the profiling nature of these datasets—that combine the weak and strong data in one profile track or just use one beam for the profile—while the remaining datasets will generate the expected six tracks (three beams split in weak and strong pairs), as shown in Figure 6.

On ICESat-2, the ground tracks are identified from left to right—along the direction of the satellite—with the letters ‘GT’, meaning ground track, followed by the beam number (from 1 to 3) and the indication of the weak beam with the letter ‘L’ (left beam) and strong beam with the letter ‘R’ (right beam), as shown in

Table 1. ICESat-2 ATLAS ground track pattern.

Beam 1		Beam 2		Beam 3
Weak GT1L	Strong GT1R	Weak GT2L	Strong GT2R	Weak GT3L	Strong GT3R

.

4.2.4. Coordinate Data Points

Coordinate Data Points are discrete sampling locations along a satellite’s orbit, each defined by a unique latitude and longitude pair. In line with specific satellite mission parameters and data product specifications, each type of sampling point is represented by a distinct icon, visually delineating the data collection path.

On the ICESat mission, five different coordinate points were identified, four based on the sampling rate of the laser pulses (see

Table 2. ICESat data sampling rates by dataset.

Dataset	0.0625 Hz (16 s)	0.25 Hz (4 s)	1 Hz	4 Hz	5 Hz	10 Hz	40 Hz
GLAH01 [96]			✕				✕
GLAH02 [100]			✕		✕		✕
GLAH03 [101]	✕	✕	✕	✕			✕
GLAH04 [102]			✕			✕	✕
GLAH05 [103]			✕				✕
GLAH06 [104]			✕				✕
GLAH07 [105]			✕		✕		✕
GLAH08 [106]		✕	✕		✕
GLAH09 [107]		✕	✕		✕		✕
GLAH10 [108]		✕	✕
GLAH11 [109]		✕	✕				✕
GLAH12 [110]			✕				✕
GLAH13 [111]			✕				✕
GLAH14 [80]			✕				✕
GLAH15 [112]			✕				✕

) and one that was added to identify the last 1 Hz point of the ground track and used to avoid gaps to the ground track representations (the last 1 Hz point of a granule corresponds to the first 1 Hz point of the following granule). This last marker has a shape like a 1 Hz pin but is tilted to the right with a ‘P’ character in the center, which represents a predicted location (calculated by the ICEComb tool by assuming satellite nadir position).

There is a parameter called ‘Data Granularity’ used to define the number of Coordinate Points the client receives for each granule. This parameter is applied to both the ICESat and ICESat-2 data products and functions as a data divisor. To increase the number of geolocations received by the client, the value of the parameter must decrease, and vice versa.

For example, if the value is set to 1, the server will return the total number of Coordinate Points available to a given geolocation data (the same as sending the data in steps of 1); if the parameter is set to 2, the server will return about half of the valid Coordinate Points (the same as sending the data in steps of 2); and so on. This parameter uses integer values, and there is an automatic internal mechanism to adapt its value accordingly to the map zoom level and the characteristics of the data product, but it also can be set manually by the user.

The GLAH03 [101] and GLAH04 [102] datasets are not represented on the ICEComb tool because these granules do not contain any surface or atmosphere data but rather ‘Global Engineering Data’ (satellite housekeeping data used to calibrate data values) and ‘Global Laser Pointing Data’ (data from the spacecraft star-tracker, laser reference system, and additional spacecraft instrument data to calculate precise laser pointing), respectively. Consequently, since the 0.0625 Hz, 4 Hz, and 10 Hz data rates are limited to those specific datasets, they are not contemplated in the ICEComb tool.

The 1 Hz data rate coordinates are used as a reference to draw the satellite ground tracks and have a pin-shaped marker/icon. The other data rate markers are represented in

Table 3. ICESat data products marker icons and their meaning.

0.25 Hz	1 Hz	Last 1 Hz marker	5 Hz	40 Hz

.

The markers below the 1 Hz are referred to as ‘intermediate markers’ and they are only displayed when the map zoom level is lower or equal to 12. This not only offers performance advantages on the server side by lowering the number of data transferred to clients, but also on the client side by minimizing the number of markers displayed on the map at once, thereby reducing the graphical processing demands.

Because data are recorded differently for the ICESat-2 data products, the marker system is simpler (i.e., uses fewer marker icons) when compared with the ICESat data. The internal data are not grouped by data rates but rather is stored by its availability, meaning that data are only recorded if it is collected with a degree of certainty instead of being recorded at an expected and fixed rate. The only exception is the ATL09 data product that has its data grouped at 1 Hz and 25 Hz (see

Table 4. ICESat-2 data products marker icons and their meaning.

General marker/25 Hz	1 Hz

), while all the other data products use a general marker (pin icon).

Coordinate Point Information Window

By simply clicking on any marker icon, users can view the collected data in a pop-up window entitled ‘Coordinate Point Information’ (Figure 2), which also shows the surface elevation provided by the Google Elevation service as supplementary information. The window contents, as represented in Figure 7, are organized in five distinct sections: the title (I), information about the geolocation (II), information about the coordinate point (III), source granule file data (IV), and finally the recorded data for that location (V). A bloated view of a Coordinate Point Information window can be observed in Figure 8.

In the ‘Granule Data Quality Analysis’ section of the Coordinate Point Information window (Figure 8) studies are presented that were produced by the Science Team responsible for generating the data products. The type of test executed varies by dataset (see Figure 9), and in the ICESat data products, these images are available inside of the granule files (and extracted by the ICEComb server), while in the case of the ICESat-2, the images are external to the granule files and have to be downloaded separately. The ICEComb Client has a visualization gallery for this section that allows users to easily browse the image collection, zoom in to view images in detail, and download them.

Several data presentation components have been created to present data in the most meaningful way possible, ranging from simple single data entries represented by the data identifier, its value, and units to more complex structures such as tables and charts, as well as data translation or conversion mechanisms.

Table headers are chosen to maximize the interpretation; values are presented with their respective units, and if the data have an associated translation list, these are converted before being presented. Boolean data values are also resolved into symbols in order to facilitate their readability. These features are visible in Figure 10.

Charts are graphical representations that allow data to be summarized and quickly interpreted. In the ICEComb tool, there are two essential chart types: the line chart and the histogram (Figure 11). These elements were also optimized for use with satellite altimetry data by implementing numerical data conventions (e.g., resorting to scientific notation or metric prefixes), but most importantly, they are able to handle infinite numbers or invalid values.

Users can also view detailed information about the HDF data records that were used to generate the displayed data, such as the HDF data paths, the HDF dataset, the long name, the units, valid maximum and minimum values, and the data description, as is displayed in Figure 12. This information is accessible by clicking on the button with the label ‘Data Info.’ located at the end of each data element presented in the Recorded Data section, as shown in Figure 10.

4.2.5. Data Processor

The ICEComb Data Processor (Figure 13) allows the study of geographic areas utilizing altimetry data from both the ICESat and ICESat-2 missions. The process consists of selecting the Coordinate Points that will be part of the study area (i.e., the sample), then the tool extracts relevant elevation data—which is dataset-dependent—to then perform statistical studies and employ algorithms to remove the observations considered outliers within the sample.

The selection of Coordinate Points can be performed using one of two methods: Single Point Selection or Interval Selection. In Single Point Selection, points are selected individually, allowing for precise control over the process. In contrast, Interval Selection enables users to specify a range by indicating the first and last points of the track under study. Once Interval Selection mode is activated, the user must click on two points—the initial and final points of the desired track. This process is illustrated in Figure 13. Selecting the Coordinate Point labeled ‘1’ (index number 20,078) followed by the Coordinate Point labeled ‘2’ (index number 20,081) prompts the tool to automatically identify and include all intermediate points (from the GLAH14 [80] data product) within this range in the selection table on the right. This method facilitates the efficient selection of multiple points along a specified trajectory.

Figure 14 depicts the data extracted from the selected coordinate points. In this example, the data were sourced from a GLAH14 data product of the ICESat mission. The extracted data are organized into the table labeled ‘Elevation Data’, which includes various columns detailing specific attributes of the collected data points. The exception is the column labeled ‘Calculated Elevation (wrt WGS84–EGM08)’, which was determined by the Data Processor tool and represents the calculated elevation values referenced to the World Geodetic System 1984 (WGS84) and the Earth Gravitational Model 2008 (EGM2008) datum. This particular elevation measurement ensures consistency and accuracy in geospatial analyses, as it incorporates variations in the Earth’s gravitational field. The calculation of this elevation is performed using the following equation:

$$Elev.WGS84–EGM08=SurfaceElev.-Geoid-DeltaEllipsoid.$$

(1)

The extracted data are subsequently analyzed statistically to determine elements such as the count, sum, minimum, maximum, range, mean, median, mode, variance, standard deviation, quartiles, and interquartile range.

A plot for each data element presented in the table ‘Elevation Data’ is produced and available in the ‘Extracted Data Statistics’ section, as exemplified by Figure 15. A similar section is also created to analyze the final data after processing the outliers.

The Data Processor offers four distinct outlier removal algorithms: the Interquartile Range (IQR) outliers, the Sigma Rejection Criteria, the Residual and Standard Deviation Fence, and the RANdom SAmple Consensus algorithm (RANSAC).

Interquartile Range Outliers

In the Interquartile Range (IQR) method, possible outliers are values that are above the Upper Fence (i.e., outside of the third quartile) or below the Lower Fence (i.e., outside of the first quartile) of the sample data. This is determined in the following way:

$$IQR=Q3-Q1.$$

(2)

$$\mathrm{OUTLIERS}\left\{\begin{array}{ccc}\mathrm{height}\mathrm{data}\hfill & <& Q1-(1.5\times IQR);\hfill \\ \mathrm{height}\mathrm{data}\hfill & >& Q3+(1.5\times IQR).\hfill \end{array}\right.$$

(3)

Outlier values are classified as mild when they fall between $1.5\times$ and $3.0\times$ the interquartile range, and as extreme when they exceed $3.0\times$ the interquartile range (either below the first quartile or above the third quartile).

This method was applied with success to ICESat-2 data to remove outliers before averaging the data used to determine reliable lake surface heights (LSH) for several lakes in China [37].

Sigma Rejection Criteria

The two-sigma rejection criteria serve as a heuristic for identifying values that fall within two standard deviations ($\sigma$) of the mean, with those outside this range considered outliers. In other words, values outside the range of the mean plus or minus two standard deviations are classified as outliers. The key formulas employed by this approach are presented below:

$$\sigma =\sqrt{{\displaystyle \frac{1}{N-1}}\sum _{i=1}^N{(x_i-\overline{x})}^2}.$$

(4)

$$\mathrm{OUTLIERS}:\left\{\begin{array}{ccc}\mathrm{height}\mathrm{data}\hfill & <& mean-(2\times \sigma );\hfill \\ \mathrm{height}\mathrm{data}\hfill & >& mean+(2\times \sigma ).\hfill \end{array}\right.$$

(5)

This was one of the methods used to remove spurious observations in data originated in the ICESat mission over inland water surfaces [33], as well as to remove outliers when comparing results between radar and satellite altimetry in a study about lake and reservoir volume variations [36].

Residual and Standard Deviation Fence

This method excludes values (outliers) whose absolute residuals (deviations of the values from the mean) exceed 2.5 times the standard deviation (StD) of the residuals. It is an iterative process that will only stop when all the residuals fulfill the premise. The pseudocode for this approach is presented in Algorithm 1.

The residual and standard deviation fence method has been successfully employed to determine water-level fluctuations and trends in large lakes using ICESat data [32].

RANSAC Algorithm

The RANdom SAmple Consensus (RANSAC) algorithm utilizes random sampling to classify data elements as either outliers or inliers. The pseudocode for RANSAC is shown in Algorithm 2. This algorithm repeatedly fits a line through random pairs of points in the dataset, following a specified fit threshold, a fit points ratio, and a given maximum number of iterations [113]. In this context, the model used is 2D line fitting, ensuring that the estimated line is determined using only the inliers, thereby avoiding contamination by outliers.

Algorithm 1 Residual and standard deviation fence pseudocode

Input        data—Set of observations Output        filteredData—Observations without outliers   1: mean← calculate data set mean   2: outlierFound← true   3: while outlierFound = true do   4:    outlierFound ← false   5:    residuals ← calculated residuals   6:    residualsStD ← calculate residuals standard deviation   7:    for each residual in residuals do   8:      if absolute residual > 2.5 × residualsStD then   9:         outlierFound ← true {Outlier found} 10:         filteredData ← data without outlier 11:      end if 12:    end for 13: end while 14: return filteredData

Algorithm 2 RANSAC pseudocode

Input        data—Set of observations        model—Fitting model        n—Minimum number of points to estimate model parameters        k—Maximum number of iterations        t—Inlier threshold        d—Minimum number of inliers required for a good fit Output        bestFit—Model parameters that best fit the data (or null if none)   1: iterations← 0   2: bestFit← null   3: bestErr←∞   4: while iterations < k do   5:    maybeInliers ← n randomly selected values from data   6:    maybeModel ← model parameters fitted to maybeInliers   7:    inliers ← empty set   8:    for every point in data not in maybeInliers do   9:      if point fits maybeModel with error < t then 10:         add point to inliers 11:      end if 12:    end for 13:    if inliers count > d then 14:      betterModel ← model parameters fitted to all maybeInliers and inliers points 15:      err ← assessment of the fit of betterModel to these points 16:      if err < bestErr then 17:         bestFit ← betterModel 18:         bestErr ← err 19:      end if 20:    end if 21:    iterations ← iterations + 1 22: end while 23: return bestFit

There have been several applications of this method to remove data outliers with different error threshold (maximum deviation) parameters. In a study using ICESat data to derive elevation changes of Tibetan lakes, an error threshold of 15 cm was used [31], corresponding to the GLAS vertical accuracy, while in a study of water-level variations in the Hulun (or Dalai) Lake, in China’s autonomous region of Inner Mongolia, an error threshold of 10 cm was applied [35], corresponding to the accuracy of ICESat measurements over water.

4.2.6. Data Processor Application Example

Figure 16 illustrates the resulting application of the ICEComb Data Processor to the ICESat water level observations over Mirim Lagoon (Lagoa Mirim in Portuguese and Laguna Merín in Spanish), specifically specifically highlighting the observation segment shown in Figure 13 and the corresponding information provided in Figure 14 and Figure 15.

Mirim Lagoon is a large, shallow, transboundary water body on the Atlantic coast of South America, shared between Brazil and Uruguay [114]. This lagoon is part of the Patos–Mirim–Mangueira lagoonal complex [115], the world’s largest shallow coastal lagoon system, with a total water area of about 15,000 km² and an extension of nearly 500 km along the relatively flat and low-lying coastal plain of southern Brazil [10,114].

The RANSAC algorithm was used to discard outliers by applying a 2D line fitting model with a 10 cm threshold, equivalent to the accuracy of ICESat measurements over water, a fit points ratio of 70%, and was limited to 30 iterations. As a result, 25 data points were identified as outliers and subsequently excluded. The surface elevation of the lake segment under study, relative to WGS84–EGM08, ranged from 0.554 m to 0.777 m, with a mean of 0.649 m (SD = 0.052 m) and a median of 0.642 m.

4.3. Tool Performance Evaluation

In order to evaluate the performance in handling large volumes of data, two deployment scenarios were examined. In the first test scenario, the server and client applications operate on the same computer system. In the second, the server and client applications run on separate systems.

The primary system was equipped with an AMD Ryzen 9 5950X desktop CPU, featuring 16 cores and 32 threads, with 16 GB of Random-Access Memory (RAM) and NVMe Solid State Drive (SSD) storage. This system was used in the first test scenario to run both the client and server applications of ICEComb, and in the second test scenario to run the server application. The system used to run the ICEComb client in the second test scenario was equipped with an Intel Core i7-5700HQ CPU, featuring four cores and eight threads, and 16 GB of RAM. In both test scenarios, the operating system used was Windows 10, and Mozilla Firefox was utilized as the web browser to run the client.

The ICESat GLAH06 [104] Level-1B Global Elevation dataset was employed for testing. The ICEComb client was set to a zoom level of 5, with the map location centered at zero degrees latitude and zero degrees longitude. Three datasets were utilized: the first 1000 granules, the first 10,000 granules, and the entire ICESat GLAH06 dataset, which consists of 34,208 granules, totaling 68,416 files (half H5 files and half XML files).

The average client loading times from 11 individual runs of non-concurrent usage patterns for the combinations of test scenarios and datasets are detailed in

Table 5. ICEComb response times: Test scenario 1 (collocated server and client applications) and Test scenario 2 (distributed server and client applications).

Dataset			Client Input		Client Load Time (Time/Granule) (s)
Granules	Files	Data Size	Lines	Points	Test Scenario 1	Test Scenario 2
1000	2000	3.95 GB	69	2294	5.53 (0.0055)	2.72 (0.0027)
10,000	20,000	36.50 GB	694	23,408	29.60 (0.0030)	29.45 (0.0029)
34,208	68,416	122.00 GB	2384	79,977	82.51 (0.0024)	97.36 (0.0028)

, which includes information about the dataset sizes and the corresponding number of track lines and coordinate points managed by the client application. Additional information about the loading time per granule is presented in parentheses.

As expected for applications handling large volumes of data, one of the most demanding tasks in the performance of the ICEComb tool is data access management. This involves efficiently retrieving, filtering, and processing data to ensure optimal functionality and responsiveness. This characteristic was evident in the test results, where each scenario showed that larger datasets led to longer client loading times. Interestingly, when comparing the client loading time against the number of granules, it was observed that in test scenario 1, smaller datasets took longer to load than larger datasets. This discrepancy can be attributed to the shared resources when the server and client applications run on the same computer, potentially causing performance bottlenecks due to shared CPU, memory, and disk usage. Conversely, in test scenario 2, the ratio between client loading time and the number of processed granules scaled almost linearly.

As the satellite data are composed of thousands of granule files, proper data access management is essential, as it directly impacts the speed, reliability, and overall user experience of the software. This task is further complicated by the necessity to efficiently index, search, and retrieve relevant granule files, highlighting the critical role of disk IOPS (input/output operations per second) in the software’s performance.

Data also indicate that another critical factor affecting loading time is CPU speed. Analysis of the results reveals that when loading the full GLAH06 dataset, the faster loading time was achieved in test scenario 1, where both the server and client applications ran on the same system. This outcome can be attributed to the higher core count and faster clock speed of the AMD CPU (3.4 GHz base and 4.9 GHz boost, compared to 2.7 GHz base and 3.5 GHz boost of the Intel CPU), enabling a loading time approximately 18% faster, primarily due to its enhanced capability in updating the client graphical interface (i.e., handling and drawing the larger number of coordinate points and track lines).

Despite the optimal scenario for running the ICEComb tool being to have the client and server applications on separate systems, the results demonstrate that the tool is perfectly capable of running efficiently on a single system, at least in the context of single-user usage. This underscores the effectiveness of the optimizations implemented in both the server and client applications. The tool not only performs adequately but also achieves very satisfactory performance levels when operated on a single system without necessitating additional hardware.

5. Conclusions

Both ICESat and ICESat-2 missions provided many important insights into the value of satellite laser altimetry and demonstrated that it is a very useful tool for examining and understanding changes on the Earth’s surface and cryosphere. These missions made it possible to quantify the seasonal and annual contributions of the ice sheets to sea level rise, the rate of mass balance changes, the amount of global biomass, and monitor other parameters of environmental interest with unprecedented accuracy and on a global scale.

Handling the enormous data volume produced by satellite altimetry missions is challenging. Moreover, the fact that data are directly coupled to the gathered location information with a visual reference of the satellite track and the possibility to evaluate the characteristics of that location is a fundamental feature to produce and understand new scientific models derived from such data. Producing a viable solution that offers both ease of use and performance requires the development of tools that are based on well-known and user-friendly platforms, as well as the creation of processes based on programming models that accommodate some level of parallelism.

The necessity to create a new tool to navigate the ICESat and ICESat-2 data products arises primarily from the fact that the existing solutions only offer access to a limited amount of the dataset’s information and because the feature set offered by the mapping tool, used to represent the world map, has an important role in the data interpretation since the characterization of the geographic location of the data origin is sometimes vital.

NASA’s Earthdata Search, NASA’s WorldView, and the OpenAltimetry project are some examples of tools that use a map as an interface to data from the ICESat missions. The NASA Earthdata Search is a web-based client for managing and distributing data from multiple Earth-observing satellite missions; therefore, its focus is on advanced data filtering and subsetting, on which the main objective is the data granules download, using a geographical map as a reference. NASA’s WorldView is a tool that offers end-users access to view and download NASA remote sensing imagery [76]. Both of these NASA tools only offer access to the spatial coverage of the ICESat missions but not to the presentation of data values.

In contrast, the OpenAltimetry project [8] was specifically created to allow the visualization of altimetry data by geographical location on a map-based interface using the OpenLayers mapping library. The tool initially supported data from the ICESat mission but was later expanded to include ICESat-2 data; however, it still has limitations, as the ICESat and ICESat-2 datasets contain more than altimetry data. Data from atmosphere segments, cloud layers, backscatter, aerosols, elevation flags, reflectivity information, optical depth, waveform parameters, and geophysical and planetary boundary layers are some examples of data that are not possible to view on the OpenAltimetry platform but are visible by the ICEComb tool.

The ICEComb tool offers a ready-to-use system to rapidly access the raw collected data in a visually engaging way without needing prior knowledge of the format, parameters, or structure of the data products, and is intended to be mainly used by researchers and scientists to aid their work using ICESat and ICESat-2 laser altimetry data.

The tool’s architecture and implementation—in particular the development of its visualization engine—was made using standardized languages and open source software in order to facilitate the expansion of its capabilities and features. This allows, for example, the incorporation of data from other satellite missions and the integration of new models that are compatible and can be coupled with the ICESat and ICESat-2 data, thus expanding and enriching the context of studies developed from such data. As an example, data from satellite radar altimetry missions, such as Envisat, SARAL/AltiKa, and Sentinel-3, could be integrated in the ICEComb tool by implementing a compatible data query engine in the ICEComb Server and mapping the corresponding data on the client side for presentation.

Furthermore, the fact that the ICEComb solution has only two main elements, namely a server program and a web client, makes it that it can be almost viewed as a self-contained application that allows it to be easily deployed in a single computer for quick access to data without the need for the allocation of high-performance server hardware, which is not always available, although the data storage required for storing both missions’ data products is quite large.

These types of integrated tools offer a high degree of versatility and have the potential to make significant contributions to various scientific applications, enabling users to conduct comprehensive analyses within a single platform and significantly reducing the time and effort required to prepare data for scientific investigation. Applications such as Earth surface monitoring and change detection, hydrology and water resource management, geophysical studies, environmental monitoring and climate change research, and urban planning and infrastructure development can greatly benefit from the ICEComb tool’s ability to streamline data processing, enhance visualization, and facilitate the integration of diverse datasets, ultimately leading to more efficient and accurate scientific outcomes.

Although the ICEComb tool fulfills the requirements to act as a capable visual tool to explore the ICESat and ICESat-2 data, scientific data can always be manipulated, analyzed, and viewed in numerous ways. The fact that the technology used to develop the ICEComb tool is scalable and well documented opens the possibility to effortlessly expand the scope of the application and offer new functionalities such as:

• Add a ‘map area selector’ functionality that would allow to display data from all data products, allowing users to have immediate access to a broader information set complied with all available data from that sector (i.e., simultaneous view of multiple datasets). Also, this option could eventually aggregate both missions, allowing to mix ICESat and ICESat-2 data but at the cost of losing the data acquired time line.
• At the moment, granule data are presented individually, but relations between data of different granules do exist. Connecting data from different products would allow to complement information of a specific granule and offer a richer data presentation, and thus, an enhanced interpretation of the study area.
• Create a function to subset and extract data automatically from a given map area. This would allow the possibility to have access to a subset of data limited to the study location that can be directly applied to external tools that would not need to implement an additional coordinate filter system.
• Provide additional data processing capabilities to the ICEComb tool by implementing other scientific models developed in research works about the ICESat and ICESat-2 datasets.
• Implement a data mashup approach by aggregating data from other data sources, thus moving towards a multi-source learning tool (learning simultaneously from multiple sources describing a common phenomenon) and allowing researchers to have additional points of view on a case study. Having the possibility to mashup related data accessible under a single tool greatly simplifies data access and sharing, eases the effort on data manipulation, and allows users to only focus on data interpretation.