Argovis: A Web Application for Fast Delivery, Visualization, and Analysis of Argo Data (2024)

Keywords: Ocean; Algorithms; Data processing; Databases; Profilers, oceanic

1. Introduction

For the first time in history, the Argo network of profiling floats provides real-time data of temperature T, salinity S, and pressure P for the global ocean to a depth of 2000 dbar, with Deep Argo floats going down to 6000-dbar depth. Argo floats have been deployed since the early 2000s and reached the expected spatial distribution in 2007 (Roemmich et al. 2009). Nearly 4000 floats are currently operating in the global ocean and provide a profile every 10 days, that is, measurements from a vertical column of the ocean as a single float ascends to the surface. The four-dimensional (4D) space–time Argo data have many scientific and technological advantages, two of which are 1) unprecedented spatial and temporal resolution over the global ocean, and 2) no seasonal bias (Roemmich et al. 2009).

More than two million T/S/P profiles have been collected through the Argo Program. Datasets as complex and large as Argo raise data delivery and visualization challenges. Users need to extract relevant subsets without necessarily having the expertise and familiarity with data formatting practices or programming knowledge.

The International Argo Program, plus the national programs that contribute to it, makes Argo data available online to anyone, with global data assembly centers (GDACs; for convenience, the acronyms and abbreviations used in this paper are also defined in Table 1) storing the data online. Users download either single profiles or all of the profiles taken from a single float over its entire history of deployment. With little option of space–time or metadata selection, this method is inefficient for many scientific and/or technical applications and discourages use by laypeople and policy makers.

An ongoing effort has been made within the Argo community to improve visualization and delivery of Argo data and their derivative products to scientists, policy makers, and the general public. Some visualization tools are currently available online. For example, the Joint Technical Commission for Oceanography and Marine Meteorology In Situ Observations Programme Support Centre (JCOMMOPS) includes an interactive map (at http://argo.jcommops.org) that prompts users to query floats by program (Core Argo, Biogeochemical Argo, Deep Argo, etc.), nation, float type, last position, transmission type, and so on (JCOMMOPS 2019). The most recent profile of the selected floats appears on the interactive map with the option to show all positions of profiles within a size limit. The Argo-France group offers a product (at http://map.argo-france.fr/) that shows profile locations for the past 7 days with the option to click on individual profiles and see a plot of the data and previous locations for that float (Argo France 2019). Also, the Euro-Argo group offers a similar Argo visualization application (at https://fleetmonitoring.euro-argo.eu/dashboard).

There are data delivery tools (for data other than Argo) whose design the Argo Program can borrow for their own application. The Web-Based Reanalyses Intercomparison Tools (WRIT) (at https://www.esrl.noaa.gov/psd/data/writ/) (Smith et al. 2014) allow users to create customized plots and retrieve climate data from these plots. WRIT addresses how to store and distribute large climate datasets, and helps to overcome data selection and delivery for scientists. The complex tabular WRIT interface is for scientists and professionals and not for the general public or, for example, high-school students.

A similar application is owned by NASA GES DISC. Giovanni (at https://giovanni.gsfc.nasa.gov/giovanni/), uses a dedicated server to create images, Keyhole Markup Language (KML) files used by Google Maps, and Network Common Data Form (netCDF) files. Giovanni depends on a server to handle WorldWide Web (hereinafter the “web”) traffic, which requires hardware and maintenance. Alternatively, using the user’s browser to generate plots and maps significantly reduces computational loads, thereby reducing the resources needed to host a data delivery web application.

The Four-Dimensional Visual Delivery (4DVD) technology (at http://4dvd.sdsu.edu/) (Pierret and Shen 2017) is one such tool: it combines data visualization and delivery while also having the user’s computer create customized charts and maps. 4DVD displays gridded data and time series on an interactive globe for Global Precipitation Climatology Project (GPCP) data and NOAA CIRES reanalysis fields. Users make selections on a menu such as depth and date, to display data dynamically. Visualization elements such as charts and maps are rendered using the user’s central processing unit (CPU) and graphics processing unit (GPU). This allows the webserver to focus on sending data quickly, requiring little computation power and ultimately improving its performance (Pierret and Shen 2017).

Following the ideas of the 4DVD technology, we created Argovis (at https://argovis.colorado.edu), a modern and efficient web application that combines web browser, webserver, and database technologies to navigate the Argo dataset in space and time. This web application provides two services: 1) visualizing Argo data and its gridded products with charts and maps and 2) delivering Argo data to the user. Through basic web browser navigation, Argovis enables a wide variety of users to use a world map of Argo floats, a depth range, and a time range to request, visualize, and analyze the 4D Argo data stored in an optimized database. The fast Argovis database enables users to receive JavaScript Object Notation (JSON) or comma-separated value (CSV) formatted data and Hypertext Markup Language (HTML) figures almost instantly. More advanced users can also query Argovis from other programming environments, such as Python, R, and MATLAB.

Argovis improves on other tools for Argo data access by allowing interactive querying and visualizing of curated profiles on the basis of a 4D spatial–temporal data selection (e.g., retrieving upper-ocean data in the tropical eastern Pacific Ocean during a period of interest). In addition, metadata database queries and additional specialized aggregation queries are under development.

The guiding philosophy of our Argovis development includes visualization with minimal effort, fast delivery, and wide availability for everyone. We referenced the ideas of an interactive and responsive interface for children, making Argovis attractive, self-explainable, and 4D. Argovis is different from the traditional data service technologies, such as file transfer protocol (FTP) and download that passively feed digital data to a user or consume the server’s computing resources to generate and push figures (e.g., the NASA Giovanni application). The Argovis system is an active technology instead, displaying data dynamically. The user requests data that are used to render pages on the browser.

For data science experts, our architecture allows for statistical analysis such as optimal interpolation (also known as objective mapping or statistical interpolation), for example, to calculate sea surface height anomalies using Argo temperature and salinity profile data as in Kuragano et al. (2015). Kuragano et al.’s (2015) model depends on fitting a local 3D Gaussian function regulated by small scales, and can represent an anisotropic spatial scale, time scale, and propagation feature of oceanographic variability. The data used to calculate parameters scales for the Gaussian function are gridded (¼° latitude × longitude × 3 days), requiring hundreds of thousands of data queries. Argovis’s application programming interface (API) querying tool can be very helpful in this instance. In more general terms, Argovis’s API makes the process of selecting Argo data flexible and customizable to the needs of each model or researcher. As an interface to a database, the API is designed for such queries, so that data manipulation time is reduced while simultaneously relieving the researcher of the task of optimizing data input or output. The API can also be used for data extraction to create gridded products using other methods, for example, objective mapping in Roemmich and Gilson (2009) or Kuusela and Stein (2018) or spectral optimal gridding in Shen et al. (2017). More of this will be covered in the space–time query section described in section 6c. For users interested, instead, in analyzing profiles locations, dates, DACs, positioning systems, and so on, we have provided a metadata API, whose details and example applications are explained in section 6d.

In the following sections, we recapitulate the Argo network and its data in section 2 and provide an overview of the web application in section 3. Design practices relevant to Argovis are covered in section 4. Section 5 provides technical details of Argovis, addressing how the database is structured (section 5a), how datasets are added to the database (section 5a), and how the database is connected (section 5b). Section 6 describes how Argovis data are accessed both through the interface for the website (https://argovis.colorado.edu) and through the API. Section 7 presents the summary and conclusions. As supplementary materials to this paper, Argovis tutorials have been developed and are freely available via the tutorial link on the Argovis home page.

Argovis current uniform resource locator (URL) (https://argovis.colorado.edu) is referenced in this paper. Future changes to the application domain name will be mentioned in the “README” file of the Argovis GitHub repository (https://github.com/tylertucker202/argo-database). Up-to-date URLs for Argovis API can be found via the tutorial link on the Argovis home page.

2. The Argo data network

Most Argo floats drift at a parking depth of 1000 dbar and make T/S/P measurements every 10 days while rising to the surface (from a profiling depth of 2000 dbar). A limited number of floats include biogeochemical observations (Claustre et al. 2010; Gruber et al. 2010) and or measure deeper than 2000 dbar (e.g., to depths of 6000 dbar). Once at the surface, Argo floats transmit profile data to national data assembly centers (DACs). These raw measurements undergo automated quality control (QC) tests and adjustments before being sent as netCDF files to the GDACs where they are served on FTP servers. Servers are frequently updated to include additional QC checks by a float’s primary investigator. Profile data that undergo automatic QC are known as real-time-mode profiles. Profiles that are inspected by oceanographic experts and passed through an adjustment algorithm (described in Owens and Wong 2009), are known as delayed-mode profiles. The observational cycle of an Argo float produces a data profile. More than two million profiles have been collected through the Argo Program since 2000, and navigating through the large and complex Argo dataset can be challenging. For instance, accessing Argo netCDF files on the GDACs involves parsing through a remote or local archive of files, selecting relevant files, opening the files, and performing analysis. As an alternative, Argovis takes profile data from the GDACs and stores them on a database that is coupled with a front-end interface for charting and data delivery.

3. Web application overview

The Argovis main web page, shown in Fig. 1, consists of an interactive map and sidebar with controls, allowing users an intuitive way to navigate through profiles, either by a space–time query or by entering a float’s World Meteorological Organization (WMO) number. Argovis home page shows the interactive map, along with the locations of profiles in a 3-day window (whose latest date defaults to “yesterday” and can be changed in the side panel). The interactive map is created using the Leaflet.js library, that is, a tiled web map generator that includes plugin extensions for shapes and images to be displayed on web maps. Clicking and dragging the map pans the view, and zooming can be done by double clicking a spot on the map.

Toggle elements are included in the sidebar, allowing a quick filter for special types of profiles, such as “Biogeochemical” (BGC) or “Deep” floats. Note that these types of floats appear as different colors. BGC floats are displayed as green, and Deep floats are displayed in dark blue, in contrast to the standard yellow profiles. A button on the side panel clears the page from all the profile locations (i.e., all the dots), if needed (e.g., before a selection).

The pop-up window that appears when a dot is clicked contains the latitude and longitude coordinates, the profile’s measurement date, and a button that will show the float’s previous profile locations (see the pop-up in Fig. 2a). Links to either the profile page (shown in Fig. 3a) or the entire float history (shown in Fig. 2b) are included as well. BGC floats have links to their own page displaying additional parameters. Another way to view a float’s trajectory is by typing in the platform’s WMO number on the side panel, revealing the platform’s history as seen in Fig. 2a.

Different map projections are available by clicking the name of the desired projection near the top of the sidebar. Currently, web Mercator, northern stereographic, and southern stereographic are the only projections available. Only web Mercator uses map tiles; the latter two use a JSON shapefile to show land outlines (see Fig. 2a for a southern stereographic projection map).

In each projection, the map includes a drawing plug-in that allows users to create, edit, and delete a polygonal region of interest. When a polygon is created by drawing it on the map, the application queries the database for profiles falling within the region bounded by the polygon, along with the date and pressure ranges selected on the side panel. If the query is not too large, the application clears the map of profiles and displays profiles that match the temporal–spatial query returned by the database (Fig. 4a). If the query is too large, a message warns the user, with a suggestion to explore API options. The completed shape (e.g., Fig. 4a) will also have a pop-up window with two buttons that open web pages with T/S/P plots for the region and period of interest, with or without the pressure selection (Fig. 4b). The T/S/P plots are interactive and when you click on one profile, a new web page opens showing the T/S/P plots for that single profile (Fig. 3a) and a link to plots for the platform history (Fig. 2b).

Below the T/S/P plots for a drawn section or a platform, there is a table and several buttons for data or table downloading (Fig. 4b). The columns in Fig. 4c are sorted by latitude, longitude, data center, data mode, positioning system, and so on. To access the same region frequently, a user can simply copy the URL of the selection region and reuse it as desired. The date can be changed in the URL link for a different time period.

4. Overview of the Argovis web application design

Modern web framework design and practices pair well with large climate and oceanographic data. Argovis only uses free and open sourced software that are actively developed and maintained by a community of developers.

The tools used to create the Argovis interface as shown in Fig. 1 came from a standard web application design. Web pages are built with HTML and styled with Cascading Style Sheets (CSS). Together these languages display images, buttons, tables, pop-up windows, and so on but do not address event handling such as clicking or scrolling. Logic and event handling are done with JavaScript, which handles the position and zoom level of the map global view. Users import and run HTML, CSS, and JavaScript on their browser as the front end, using their own computing resources.

Complex web applications such as Argovis use front-end frameworks, which are prewritten standardized libraries (i.e., React.js, Vue.js, and Angular). Argovis uses Angular libraries as the front end, which are written in TypeScript (i.e., a type-based language that compiles into JavaScript). HTML, CSS, and JavaScript needed to be organized around these libraries to address event handling, requests, and page rendering. When the user makes a selection on Argovis, the front end requests the 4D data, which are delivered in the JSON format via HTTP by Argovis’s back end.

Argovis’s back end comprises a server, database, and its interface code. Most modern applications such as YouTube or Amazon populate their pages with content stored in databases, allowing users fast and easy access to vast amounts of data such as videos or shopping catalogs. Argovis’s profile dataset is stored in a Mongo database (MongoDB). A remote server runs the database and sends HTML, CSS, and JavaScript via HTTP to users. Code that handles databases and web content has evolved into several specialized libraries known as web frameworks (e.g., Django, Express.js, Flask, and Ruby on Rails). We chose the Express.js framework to handle Argovis page views, URL routing, and database interface.

5. Argovis development

6. Accessing the Argovis database through the API

There are two ways to access the Argovis database: through the front-end web application (described in section 3) and through the back-end API calls (described in this section). The front end of Argovis for the general public is intuitive, simple and attractive, but can be confining for automated tasks. While our design allows for more visualization features to be added, this is at the expense of additional development cost and maintainability. The back-end API calls allow for fast access to the Argovis database within the users’ preferred programming environment and the ability to create additional plots not featured in the front-end web application.

The definition of API is somewhat nebulous; in this context an API is the access to the Argovis database without the need of a browser. RESTfully designed applications (i.e., Representational State Transfer–compliant web applications), such as Argovis, allow custom code to retrieve data. This code can be a process running a plotting script, a data archive service, or another website. Hence scientists can access any information in the Argovis database (and even make selections in space and time) using a script in their preferred language by including HTTP requests in their code.

There are four main API calls for Argovis, which can be used to import Argo data in the programming environment of choice, such as Python, R, and MATLAB. Three calls are for accessing profiles: individual profiles, all profiles from one platform, and all profiles in a region, time and pressure range. The fourth call is for accessing metadata associated with the Argovis dataset for the month and year of choice. Table 2 summarizes the input needed for each call and the information that is returned. There is a 16-megabyte size limit for data retrieval per API call, so users are advised to break the calls into chunks of data. Suggestions of how to do this are provided below and on the Argovis tutorial link on the main Argovis page, along with sample Argovis API code.

7. Summary and conclusions

Argovis is a modern web tool for cutting-edge oceanographic applications of data visualization and delivery, featuring an ease-of-use interface and flexible ways of providing a curated set of Argo observations.

Argovis requires little to no training other than the basic “point and click” computer proficiency. Support from the general public and the broader scientific community is helpful for scientific programs such as Argo to thrive. Open web applications such as Argovis allow nonscientists to visualize government funding at work to bolster their support for such funding. Public kiosks at museums or ocean science centers around the world can display Argovis. Secondary-education schools may use Argovis in their science education, which may even motivate some students to “adopt” a float by following the float’s data and broadcasting the float’s records.

Improvements to Argovis’s ergonomic and convenient design encourages use also by scientifically inclined users, ultimately favoring discoveries by increasing the number of studies that analyze Argo observations. Temperature and salinity measurements are needed not only by physical oceanographers, but also by biologists, engineers, climate scientists, and even the general public. Such a diverse group of users undoubtedly have preferred computing tools and programming languages. The API for Argovis tailors to the needs of the Argo community. The API calls described in section 6 and on the tutorial page of Argovis (via the tutorial link on the Argovis home page) show just how simple hooking up to Argovis can be. Float data can be extracted in JSON format and parsed into a tabular format like CSV or ASCII in a few lines of code. It is our thought that Argo scientists will write (and share) the four functions described in this manuscript, in a language of their own preference such as R and Julia. Also, automation through the API ensures scientists can spend more time on the nontrivial statistical analysis and mathematical modeling rather than obtaining data through a browser or FTP, and then decoding and selecting the data with appropriate QC flags.

Existing and continuing collaboration with the community will further add to the value of Argovis, improving the work flow for scientists already familiar with Argo observations and serving those not yet using these data. In the future, Argovis will be extended to include other datasets, leveraging the web application’s architecture toward a comprehensive data display and delivery system for geosciences. Also, visualization tools for gridded fields are under development, which will replace the static global images of different Argo products currently shown on the gridded climatology section of the website. Included in this development is a tool that displays float trajectory probability fields. Its most recent version is available online (at https://argovis.colorado.edu/ng/covar).