Evaluating a new open-source, standards-based framework for web portal development in the geosciences

Web portals are one of the principal ways geospatial information can be communicated to the public. A few prominent USGS examples are the Geo Data Portal (http://cida.usgs.gov/gdp/ [URL is accessible with Google Chrome]), EarthExplorer (http://earthexplorer.usgs.gov/), the former Derived Downscaled Climate Projection Portal, the Alaska Portal Map (http://alaska.usgs.gov/portal/), the Coastal Change Hazards Portal (http://marine.usgs.gov/coastalchangehazardsportal/), and The National Map (http://nationalmap.gov/). Currently, web portals are developed at relatively high effort and cost, with web developers working with highly skilled data specialists on custom solutions that meet user needs. To address this issue, the Australian National Government funded the development of an open-source framework for building web portals called TerriaJS, which began in early 2015 (TerriaJS, 2015). TerriaJS takes advantages of capabilities in modern browsers to deliver a browser-only solution that consumes web map services from Esri and Open Geospatial Consortium (OGC), the most commonly used web map service (WMS) standards employed at the USGS and throughout the geoscience community. Because TerriaJS runs completely within the web browser, it is possible to generate custom portals by using simple configuration files that can be located anywhere on the internet. This means that basic portals based on WMSs can be created by non-JavaScript developers such as scientists, environmental managers, and emergency response support personnel. It also means they can be constructed rapidly, in hours or days instead of weeks or months. Finally, TerriaJS could also reduce the development cost of more sophisticated portals by providing a broad framework that covers a wide range of common portal mapping needs.

While TerriaJS appeared promising, we needed to more closely examine its capabilities, potential, and risks to fully understand its value. What are the generic portal needs that can be addressed by the existing framework?  Does the framework architecture allow expansion to address more sophisticated needs beyond basic web service mapping? Does the framework have sufficient documentation and interaction or encouragement from the lead developers to actually function as a community-driven open-source project, or are enhancements only reasonably created by core developers?  The project team planned to address these questions by taking a deep dive into TerriaJS; adding specific enhancements needed to support access to meteorologic, oceanographic, and hydrologic model data; and using the framework to create several web portals using a combination of developer resources from the USGS Office of Water Information and the Australian CSIRO/Data61 team.

Principal Investigator : Richard P Signell
Cooperator/Partner : Christopher Barker, Patricia (Soupy) A Dalyander, Cameron Hunt, Richard Knudsen, Kevin Ring, Jordan I Walker

Accomplishments

Lessons Learned

Visual Representation


























 

Figure 11. Screen capture showing surface currents from the IOOS forecast model for New England, which uses a native triangular grid, but is regridded at varying resolution by ncWMS2.   Shown also are the user controls for selecting the layer, the elevation, and the color range.  The ability to access ncWMS2 endpoints, as well as control the color range, elevation, and style, were all CDI enhancements to TerriaJS.  These enhancements have been merged into the master branch of TerriaJS.

Figure 12. Screen capture showing bird migration from a Cesium Markup Language (CZML) data source superimposed on monthly temperature data from WMS (via a NOAA THREDDS server).   Shown also are the user controls added in this project for selecting the style and color range.  Note that both the CZML file and the JSON configuration for this demo are on GitHub at https://github.com/USGS-CMG/terriajs-dive, and referenced directly in the URL of the portal.  This means that users can create custom portals on their own, without any interaction from the provider of the TerriaJS endpoint, which just serves to deliver the TerriaJS code to the browser.  TerriaJS runs completely within the browser. 


Note:  This description is from the Community for Data Integration 2016 Annual Report.