A New Web-Based Software Tool for Icesat and Icesat-2 Laser Altimetry Data Processing and Visualization
Total Page:16
File Type:pdf, Size:1020Kb
A NEW WEB-BASED SOFTWARE TOOL FOR ICESAT AND ICESAT-2 LASER ALTIMETRY DATA PROCESSING AND VISUALIZATION Bruno Silva1, Luiz Guerreiro Lopes2, Pedro Campos2;3 1 Graduate Program in Informatics Engineering, University of Madeira, Funchal, Portugal 2 Faculty of Exact Sciences and Engineering, University of Madeira, Penteada Campus, 9020-105 Funchal, Madeira Is., Portugal 3 Interactive Technologies Institute (ITI/LARSyS), 9020-105 Funchal, Portugal ABSTRACT using these data. After all, when dealing with satellite data, the data itself is only half of the equation, and having the abil- The purpose of this paper is to present and briefly describe ity to quickly and precisely identify the location and easily a web-based tool for processing and visualizing in a suitable characterize its surroundings according to the research objec- way the available data from satellite laser altimetry missions, tives is crucial for the interpretation of the results obtained in particular data from ICESat and ICESat-2. This new tool, from such data. called ICEComb, allows to access all data contained within each data granule of the datasets of both missions, visual- ize the data interactively on a geographic map, store data lo- 2. THE ICECOMB TOOL cally, and process and explore data in an efficient, detailed and meaningful way, thus providing an easy-to-use environment 2.1. Tool architecture, design and implementation for satellite laser altimetry data analysis and interpretation. In order to create a richer visual environment while accessing Index Terms— Laser altimetry, ICESat/GLAS, ICESat-2/ data from both the ICESat and ICESat-2 missions, a web in- ATLAS, software tool design, data visualization terface based on the graphical component of the Google Maps API was chosen. This mapping API was chosen since its a scalable and modern web platform that provides user access 1. INTRODUCTION to updated satellite imagery, high-resolution aerial photogra- phy and high-detail low altitude images, while offering high Handling the large volume of data from satellite laser altime- performance. try missions is challenging. A reference project for visualiz- In addition, the Google Maps API offers the possibility ing ICESat and ICESat-2 data is the OpenAltimetry platform to use different map view formats, such as Google Earth [1], which was created as a tool to provide altimetry-specific satellite images and a physical map based on terrain informa- data from ICESat and ICESat-2 missions with a web-based tion, and to access a set of other tools in the form of Client interactive interface. However, by only focusing on altimetric Libraries with APIs such as Distance Matrix and Elevation, laser data, that tool leaves out many other useful and impor- which allow, respectively, to calculate the distance between tant information present in the data products of both missions. geographic coordinates and provide elevation data for the In view of that, the aim of this paper is to present a new Earth’s surface and depth for the ocean floor. tool, called ICEComb, to process and visualize data from both The new web-based software tool has an architecture the ICESat and ICESat-2 missions in a meaningfully way on composed of two main components, a Data Server and a Web top of a highly detailed web mapping service, with basis on Engine that interfaces with the user through a Web Browser. the geographic location from where data was collected. This Client/Server approach, represented in a simplified way The ICEComb tool offers the possibility to browse the raw in Figure 1, permits sharing the processing demands and data contained in the datasets, represented using visual aids allows for better overall performance. like graphs, tables and data conversions, in a rich geographic The developed tool was built using standard languages related environment in order to facilitate data interpretation and well-known and well-documented web technologies in and discoverability. This approach simplifies knowledge cor- order to facilitate the incorporation of new functionalities and relation and the conception and validation of scientific models features to it and to extend its applicability to data from other satellite laser altimetry missions. This allows data mash-up This work was partially supported by the Portuguese Foundation for Sci- ence and Technology (FCT) through LARSyS – FCT Pluriannual funding and opens the possibility of expanding the context of studies 2020–2023. developed from the integration of these data. Figure 2, from an ongoing study using laser measure- ments on the world’s largest coastal lagoon, illustrates the client user interface, which is composed of two main areas, the map on the left and the input controls on the right. Fig. 1. ICEComb tool architecture. 2.2. ICEComb data server Fig. 2. ICEComb data selection. Data Server actions are limited to data file handling operations The map area is the main element of the user interface such as filtering, querying and gathering information, and all as it is where all data are presented to the user. Firstly, the other activities related to data presentation for the end user, real ground tracks are drawn, allowing the view of the pro- handling of data requests and responses, and other interface jection of the satellite’s data acquisition path on the Earth’s tasks are then offloaded to the client side. surface, and then the data points are marked along the tracks The Data Server was designed with the RESTful archi- using the coordinates of the locations from which the data tecture pattern in mind, so requests are made through the use was collected. Since ICESat/GLAS data was gathered at dif- of JavaScript URI libraries, payloads are formatted in JSON ferent rates, this causes different data point types, intervals (JavaScript Object Notation), and the server does not main- and available data by data point. tain the client’s state information. The area on the right of the user interface is separated in ICESat and ICESat-2 data files are stored using the HDF5 two tabs. The first one, visible on the right side of Figure 2, format, which was designed to manage very large numerical represents the options of the general data filtering system. data collections. However, applications using HDF (Hierar- Users start by selecting the data product to display (i.e., the chical Data Format) and HDF5 data manipulation APIs tend satellite mission and the dataset) and also may set a date in- to be hard to implement due to their low level of abstraction. terval filter. There is also a system for the management of data The API chosen for data access was the HDFql (Hierar- granules that allows users to set the allocation of the number chical Data Format query language), which is made available of data granules are processed each time, either all data files free of charge and royalty-free, and is the first data interface or by small chunks at a time. to allow HDF5 data access through a high-level language with Data quality can be set in the “Dataset Measured Parame- a syntax similar to SQL (Structured Query Language), that is ters” area, that uses QA (quality assessment) information spe- the standard for query languages and Web applications. cific to each dataset, obtained from the granule metadata files. These files contain the evaluation of the instruments and geo- 2.3. ICEComb client physical parameters expressed in the data, as well as specific test assessment flags. By having the user interface developed in JavaScript, the de- The second tab, visible on the right in Figure 3 (from the veloped solution is able to offload some computation to the same study in the Patos Lagoon), contains the general options client. This approach relegates all data access and processing for the ICEComb Client that are common to all datasets. In operations to the data providers, leaving the clients responsi- this area, the users can control the behavior of the user inter- ble to handle all user interface aspects, such as data requests face, the elements marked on the map, as well as to view and and aggregation, map display and data drawing. define various parameters related to data and the map. size, version, etc.), the Granule Measured Parameters (QA information from the metadata file) and the Granule Data Quality Analysis data (built-in imagery with data summary, history, QA analysis, and other parameters). After that, the gathered data is presented and organized by data rate. Figure 4 represents part of the data view from a granule of the GLAH10 (GLAS/ ICESat L2 Global Aerosol Vertical Structure Data) dataset and illustrates some mechanisms used to represent data in a most meaningful way. Data is converted to graphs, tables or simply shown as data lines, very long val- ues are converted to scientific notation or metric prefixes, and flag-type values are translated to their meaning, all this to fa- cilitate the data interpretation. Fig. 3. ICEComb real ground tracks and coordinates points. One part of the mechanism created to limit the amount of data sent by the ICEComb server, therefore the amount of data processed on the client, is called Map Bounds (or map bounding area). This works by defining two geographical lo- cations, the southwest and the northeast location points (with latitudinal and longitudinal values) that are used to instruct the ICEComb Server to filter any data point outside those two locations. The default geographic bound mechanism (“Map Bounds”) is based on the limits of the displayed map area, but users can set these bounds manually by changing the bound mechanism to “Shape Bounds” and draw a shape on the map Fig. 4. ICEComb data view. that defines the map area that data will be processed.