Summary

In 2008, the Open Geospatial Consortium, Inc. (OGC) approved the OpenGIS KML (formerly Keyhole Markup Language) Encoding Standard (OGC KML). The purpose of this document is to recommend OGC KML for adoption as a NASA Earth Science Data Systems (ESDS) community standard with which to code and share visual geographic content in web-based outline maps and 3D geospatial browsers, such as Google Earth. Other projects (including Marbles) have developed KML support.

This recommendation is for version 2.2 of the OGC KML Encoding Standard. Future installations should consider use of the most recent version.

Status

KML is an approved standard recommended for use in NASA Earth Science Data Systems in March 2014.

NASA Earth Science Community Recommendations for Use

Strengths

KML makes Earth science data easily accessible to a wide range of end-users, many of whom might not ever have been able to access and view this kind of data before. In fact, given that it emerged as a de-facto standard before being pulled into the OGC, many Earth Science data producers have already elected to support this format.

Its pervasiveness is based on widespread use in many fields beyond Earth science, openly available data streams, and tools which are easy to use and allow overlaying of information (e.g. Google Earth^TM).

The KML format enhances the user experience by allowing one to visualize the location and availability of data and providing a platform to distribute metadata and link back to existing data systems. Furthermore, many responders indicated that KML products enhanced the user experience much in the way browse products have in the past.

The tool set available for producing and consuming KML is quite diverse and is supported by the open source community and proprietary solutions making it a fairly easy format to pick up and adopt. Many of the responders reported their KML was being served by turning on a feature within the services they already had deployed. Others reported that building custom solutions was in most cases fairly easy as the support for the format includes a large toolset.

While this recommendation does not aim to directly speak towards supporting Google Earth^TM and its accompanying browser plugin it should be noted that the adoption of KML has been readily driven by the ease of use and prevalence of these tools and has driven producers to generate KML as it is consumer-friendly.

Finally KML provides a mechanism for easy browsing of high-resolution data, with scaling controlled by the end user. Network linking provides the ability to deliver access to further detail without having to bundle everything into one data file. Respondents did indicate in the case of large datasets that one needed to be careful with implementation details.

Weaknesses

Based on the responses we received, there are a wide variety of internal processing workflows in use. Some responders, while positive about KML in terms of user-friendliness, reported challenges in developing their processing workflows. Other responders seem to have no trouble. This suggests that information exchange among implementers would be beneficial.

Moreover, it is possible to construct KML files or data streams that are simply too large to be consumed by tools such as Google Earth^TM. Given only a few participants presented ways to work around the issue this suggests a need to capture a set of best practices.

Generally, there was some disagreement about interoperability in terms of machine-to-machine interfaces when consuming KML, given the ability to encode data and metadata in several different ways. This suggests the need to work on a set of conventions for capturing metadata (e.g., akin to CF in NetCDF-CF) and a mapping of standard NASA HDF/HDF-EOS products to KML where applicable.

Finally, the OGC specification does not cover compressed KML (KMZ) to the extent needed. A change request has been submitted to OGC to add this in a future version of the specification.

Applicability

KML is primarily a publishing format that lends itself towards easy end-user visualization. Thus it works well as a means of delivering browse-level data (e.g., granule images) or small amounts of vector data (e.g., sensor paths, region boundaries).

KML and KMZ are routinely distributed over HTTP although some respondents reported using other mechanisms.

Limitations

The flexibility afforded by the specification means that different data providers will package content in different ways. While this may not be a big limitation for end-users wanting to visualize data, it makes it very difficult to use KML as a data interchange format.

KML is not well suited or understood as a means of delivering large quantities of raster or vector data in the same way as HDF or NetCDF would be. It is at this level where complexity creeps in and a set of best practices should be investigated and shared amongst NASA data providers. Some respondents indicated the ability to handle said cases but at this point this should be considered knowledge that needs to be shared amongst data providers.

KML supports only geographic coordinates (i.e., unprojected latitude/longitude), which can limit its usability in GIS environments where projected coordinate systems are used. The ubiquitous tool (i.e., Google Earth^TM) for viewing KML supports only a cylindrical projection that makes data viewing in the polar regions problematic.