From Legos to Varieties of GML Lite

By
Sam Bacharach

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.

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.

GML Profiles
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.

Commonality Among "Information Communities"
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.

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.