Lincoln Logs, Erector Sets and more recently, Legos are examples of toys that work because they provide standardized components that can be assembled to make most anything a child’s mind can imagine. Geospatial software, though much more complex, benefits from the same modular approach. This article, by the OGC’s Sam Bacharach, explains how.
These children's toys were developed over decades while the use of interoperable geoprocessing software has emerged as reality in the last few years. The standards work of the OGC has produced a suite of interface and encoding specifications - OpenGIS Specifications for Web Mapping Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS), etc. - and encoding languages such as SensorML and Geography Markup Language (GML). GML is defined as a single, integrated standard, not as a series of individual components. Sometimes the overall complexity argues for a complete system that can then be deconstructed into components.
Deconstructing GML into easier-to-use components has been a main theme in the GML world since the OpenGIS Geography Markup Language Encoding Specification (GML) v3 was approved by the OGC Membership. (The ISO version is about a third shorter than the original Version 3 document.) Few application developers will master the entire GML standard. Many more will use and implement simpler profiles of GML. And because GML is open, based on XML, quite complete in what geographic features and properties can be encoded, vendor-neutral, and designed for using geospatial data in Web-based computing, there is a strong demand for those simple components.
A "Profile" vs. a "Standard"
The components that help people deal with GML's complexity are called "profiles." Think of the Lego automobile kit as all of GML - its components were shaped into a car when you bought it, but those same pieces can be used to assemble hundreds of other things too. So it is with GML and the OGC standards; we manage them as cars' or some other unit that serves our needs, but users all over the world are assembling those components to satisfy their own needs.
A profile is a restricted subset of a standard. Every profile is tailored to address applications that fall within a limited and well-defined scope. Profiles simplify development, produce more compact data and ensure interoperability. Development is simplified because there are fewer geometry types, features, metadata, topology, observations, coverages, time, measurements, presentations, etc. to encode. Data are more compact because there are fewer "empty" schemas and schema elements occupying space on storage media or making their way across the network. Interoperability is improved because profiles reduce the number of options that various developers might implement differently.
Below are GML profiles that have been developed in the OGC's consensus process and one developed outside of the OGC.
- The specification for the GML Point Profile (pdf) includes only points. Most location-based services (LBS) applications work with just a coordinate pair that identifies the location of a device. Such devices are typically small and are expected to receive and send data quickly, so the data need to be as compact as possible. The GML Point Feature Profile is currently an OGC Discussion Paper.
- The OpenGIS GML Simple Feature Profile (GML SF) specification, approved in 2006, only allows encoding of simple feature geometries: points, lines, polygons and a few others. This subset is particularly useful for applications that intend to use the OpenGIS Web Feature Service Implementation Specification (WFS) to define an interface for sharing and editing vector data.
- GML in JPEG 2000 for Geographic Imagery Encoding Specification provides information related to an image, including image location. ISO, under whose auspices the JPEG 2000 Specification was developed, left a "box" available for storing such information. Encoding information about an image in GML provides a standard way for applications to find and use the image.
- The GML Profile for GeoRSS specifies how to store four geometry types - point, line, polygon and box - in RSS XML documents. RSS (Really Simple Syndication or Rich Site Summary) is a tool that enables Web users to subscribe to information updates from Web servers. GeoRSS was developed through consensus of a number of interested geospatial and IT professionals and is not currently an approved OGC specification.
Over time, many "Information Communities" will develop GML "application profiles," some of which will be based on the general purpose GML profiles described above. Many of these communities will simply insert these and other existing GML "micro profiles" into their own XML schemas. An Information Community is a group of people who share a common geospatial feature data dictionary and a common metadata schema. Wildlife biologists, hydrologists, surveyors and security camera vendors, for example, are Information Communities that might develop application profiles so that they can take advantage of XML tools and XML capabilities plus the flexibility, interoperability and "future-proofing" of GML and the OGC Web Services (OWS) suite of standards.
Each GML application profile will be used to build a GML "application schema" that defines the data elements in a domain-specific application. Each application schema is a fit-for-purpose data model that doesn't require GML expertise to understand and use. Information Communities need to come to agreement on the application schemas and "business rules" that determine the services they need. At least a few experts in each information community need to understand GML and related standards from the ISO TC/211 standards organization.
Information communities can publish their application profiles on the open GML developer's site. Contact the webmaster for permission to post content there.
The GML 3 specification includes a profiling tool (a pair of XSLT scripts) that enables the automatic generation of a profile.
Most Information Communities have already done much of the work that goes into developing their application schemas and application profiles. In their metadata standards groups, most Information Communities have already described data and service resources in a consistent way. If their standard conforms to the ISO TC/211 Metadata Standard 19115, they will find that creating a GML 3 application profile is not nearly as difficult as they may have anticipated.