3D Web-mapping - 01/01/2008
Integrating Marine Data into Google Earth
Google Earth has become a popular 3D web-mapping viewer, mainly due to the richness of satellite imagery in its primary database. However, the database contains very limited marine data. While the addition of marine data would be welcome, this article explores the use of Web Map Service (WMS) and Keyhole Markup Language (KML) to overlay large-scale multi-beam imagery datasets from the Irish National Seabed Survey into the Google Earth viewer.
Over the last seven years the Irish National Seabed Survey (INSS) has returned many terabytes of multi-beam sonar and ancillary data, providing detailed bathymetry data and knowledge of seabed characteristics. This survey is funded by the Irish Government and is managed in partnership by the Geological Survey of Ireland (GSI) and the Marine Institute.
In recognition of the massive size of the INSS dataset, the 'MarineGrid' research project has undertaken to create a high-performance computing infrastructure to help support spatial analysis and modelling activities using the INNS as a base layer. MarineGrid is funded by the Irish Higher Education Authority (HEA) and involves researchers from the National University of Ireland, Galway and the Coast-al and Marine Resources Centre in University College Cork (UCC). A key project activity concerns researching web-based data exchange and visual-isation techniques for the INSS. The geospatial interoperability standards that play a central role in this research activity are the focus of this article. Here we will introduce some basic aspects of these standards and explore how they enable web-based visualisation systems to operate. We then present a detailed technical description of how multi-beam imagery can be integrated for visualisation within the Google Earth viewer.
Geospatial interoper-ability standards are fundamental in facilitating sharing and exchange of geospatial data. An analogy is communication between people. If two people (two computers) cannot speak a common language (data exchange format) then effective communication between them is not possible. Geospatial interoperability standards are playing a vital role in underpinning the development of Spatial Data Infrastructures (SDIs). A major advantage of SDI is the avoidance of data duplication and associated maintenance overheads. Instead, a single geospatial database can be maintained and served in real-time to diverse GIS applications, thereby creating a fertile environment for the creation of innovative GIS solutions.
Using a consensus approach, the Open Geospatial Consortium (OGC) is actively developing 'OpenGIS' specifications, which enable standardised data exchange between GIS applications, geospatial web services and data repositories. These specifications play an important role in the building of SDIs. Important OpenGIS specifications include Web Map Service (WMS), Web Feature Service (WFS) and Web Coverage Service (WCS). The WMS standard facilitates web-based dissemination of map imagery, while the WFS and WCS standards facilitate the dissemination of raw vector and coverage/raster data, respectively. In the case of WFS, geographic data is exchanged using the Geography Markup Language (GML) standard.
Dublin Bay Server
As part of the MarineGrid project, a prototype OGC WMS server was developed using open-source technologies: Linux, Apache HTTP Server, UMN Mapserver and PHP. Cleaned Caris files from the 2004 Dublin Bay multi-beam survey were provided by the Geological Survey of Ireland. This dataset was exported as GeoTiff imagery using Caris Hips and Sips and imported into the WMS server. The main WMS parameters include the data layer name(s), bounding box, and image size/format. When submitted, a high-resolution shaded relief image of Dublin Bay is returned from the WMS server into a pop-up window. Integrating WMS technology into 3D web-mapping viewers, such as Google Earth, can help improve access to visualisation of multi-terabyte imagery datasets.
Google Earth is the most widely known and popular 3D web-mapping viewer. Originally developed by Keyhole, it was acquired by Google in 2004, who re-branded and re-launched the system in June 2005. The free version of the viewer has enabled mass-public access, though commercial users must pay an annual license fee. To date, Google Earth has been principally aimed at terrestrial markets such as estate agents, media, national security, engineering and advertising.
Google Earthâ€™s primary database consists of terabytes of high-resolution satellite/aerial imagery stored in combination with land terrain, business address and road network datasets. At present there is very limited marine data in the primary database, nor does Google Earth currently support 3D-seabed terrain visualisation. Instead, seabed terrain visualisation is limited to a 2D low-resolution global bathymetry image. Data contributions to the primary database involve signing mutual agreements with Google. While some agreements are clearly linked to advertising, others are linked to the wider adoption of the viewer. For example, the non-profit National Geographic Society has provided isolated high-resolution aerial imagery for parts of Africa ('Africa Megaflyover'). Could Google Earth be even more widely adopted by adding marine datasets to the primary database?
One of Google Earth's key attributes is speed. This is made possible because only small portions of data corresponding to a user's virtual view are downloaded. The system achieves this by using a hierarchical nesting technique, automatically downloading regional low-resolution data, then medium-resolution data and finally local high-resolution data for any given area. This data is cached on local disk, thus improving response time by minimising data that is streamed. Data is streamed from the primary database via Google Earth servers using proprietary technologies (rather than OGC-compliant technologies). This means that it is not possible to disseminate data from the primary database into alternative OGC-compliant web-mapping viewers. Likewise, it is not possible to directly import data into the Google Earth viewer from OGC compliant servers. What is possible, however, is to import data into the Google Earth viewer using KML.
KML (Keyhole Markup Language) is an XML data exchange format for storing vector and raster data for display in Google Earth. The KML specification is controlled by Google. It has similarities to the OGC GML standard in the sense that both store geographic data, and whilst KML is not an OGC standard, it has been widely adopted as a de-facto standard owing to its simplicity and the sheer popularity of Google Earth. KML files can be posted to the Google Earth community website or shared via independent websites, where they can be downloaded and displayed. KML can directly load data from a local computer or from websites through URL links. The ability to access remote imagery through URLs is useful as it enables access to both pre-processed imagery files and dynamic image web services such as WMS. Therefore, as part of the MarineGrid project, research was conducted to explore the potential of connecting the Google Earth viewer with WMS servers via KML.
The KML NetworkLink tag, available in Google Earth version 3, is powerful as it can provide web services with the geographic bounding box co-ordinates of the user's current view extent. However, the NetworkLink can only load KML files and not WMS imagery directly. Therefore, a solution to this problem is to use a simple wrapper web service. This service embeds a WMS request URL, using the supplied bounding box coordinates, and wraps the resulting URL into a KML file that Network-Link can load. Such a service has been implemented for the MarineGrid project. Every time the user navigates to a new area, a new NetworkLink request is made (either automatically or manually). However, the main problem with this technique is that the previously loaded image segment is not cached and is discarded, thus navigation of the image dataset is not smooth.
The new Region tag, available in Google Earth version 4, has functionality supporting more efficient data streaming and temporary caching of very large datasets. Each Region, which has predetermined bounding box coordinates, can be associated with a WMS request URL. This is different from the previously outlined version-3 method, which uses on-the-fly bounding box coordinate requests based on the user's view extent. Instead, data is only downloaded if the user's view intersects the Region's
predetermined bounding box extent. Hierarchical Region nestings are also supported, where a global Region contains low-resolution data and nested Regions contain local high-resolution data. Therefore it is now feasible to overlay a complete and large imagery dataset served from a WMS server. This technique has also been used in the MarineGrid project. It is a better technique, as streamed data is temporarily saved in memory cache, so that navigation of the image dataset is smoother. However, the cached data is discarded when the viewer is closed.
KML and Elevation Data
A shortcoming of KML is the fact that it does not currently support elevation data overlay. While it is possible to overlay imagery, it is not possible to overlay a custom elevation model. Because of this, all the illustrated shaded relief images imported into Google Earth are draped over the primary database elevation model, which is fixed at zero metres for marine areas.
This article has shown that it is possible to integrate large-scale multi-beam imagery datasets into the Google Earth viewer using a combination of WMS and KML technologies. From a hydrographic and marine-science perspective, based on our findings, we believe that Google Earth has the potential to become a far more useful and widely adopted 3D web-mapping viewer. Specifically, the addition of the following features could provide the basis for achieving this aim. Firstly, the addition of 3D-seabed terrain and other marine datasets (including true volumetric data) into the primary database. Secondly, direct support for OGC standards, including WMS. Thirdly, support for a high-resolution elevation overlay feature and, finally, support for disk caching for streamed KML data.