February 15, 2007
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.
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.
|
Your Comments Post a comment All comments provided in this section are those of the individual who has created the post. These are not the opinions of Directions Media, its editors, staff or owners unless otherwise noted. Directions Media retains the right to edit or delete any comments posted herein.
|
|
||||||
| I have found that the profile approach can sometimes be problematic. I created an application schema that was built on-top of the 'full' GML as well at the DODs DDMS standard, version 1.0 (which had no GML dependency). Everything was fine until I updated to DDMS version 3, which incorporated a DDMS-specific profile of GML. Then there were definition collisions since all the profiles share the same namespace with the 'full' GML. I couldn't find a clean workaround, so I had to modify the DDMS schema to just import the full GML schema. At a DOD metadata working group, others were reporting similar difficulties, and action items were created for people to go off and think through the various schema usage scenarios. The basic problem is the management of the profile intersections as more and more application schemas are created that have non-trivial schema dependency trees. If the profiling approach is envisioned to be the long-term solution for componentized use of GML, rather than just biting the bullet and moving to a modularized version of the schema (ok, revealing my bias here :) ), it might be useful to have a best practices document describing the situations where it does or doesn't work well, so the situation I described above can be avoided. -Oliver |
||||||
