reading this because you have some connection to the geospatial
industry. Undoubtedly, you prefer to work as efficiently as possible
and not waste time, and you've likely been in a situation where you've
deemed some problem "too hard" or "too time consuming" or "too costly"
to solve. We've all been there.
Here's a problem that a growing number of geospatial software
developers face: adding support for the Open Geospatial Consortium's
(OGC) OpenGIS Geography Markup Language Encoding Specification (GML).
Simply stated, GML is a standard to encode geometry and attributes
using XML. Once the marketing department and user input confirm that
supporting this standard is worth doing, programmers have to make it
happen. Sure, programmers can do that; they can do anything. What's the
The big deal is that the current GML specification runs 600 pages,
details 1,000 tags (named objects), defines many of the geometries for
describing features on the earth, and also supports the ability to
encode coverages (including imagery), topology, time, metadata and
dynamic features. GML was designed to be very broad and cover many
needs. Recall, too, that to fully implement the specification, the
programmers have to create software that will not only write out data
in this form, but also can read it in.
It's perhaps akin to requesting support for the 64 colors in the big
crayon box. Did you ever watch a child with that box? Some will just
pick out red, blue, green, yellow, black, orange, brown and blue and
get to work. That's enough colors. The eight selected are not
overwhelming and they offer a workable solution for drawing a picture
of the family dog playing in the swimming pool in the back yard.
I do not mean to compare programmers to children, but rather to
highlight the wisdom of both. Sometimes, many choices are simply too
many. It's not worth the effort, time and money to buy and use the big
box, especially when a smaller box, a subset, will solve the problem.
In fact, GML was designed with the idea that smaller boxes with fewer
colors would be created for use. In the standards world, a subset of
specification is known as a profile. A profile defines which colors
(geographic features and what not) go into the smaller box.
Just as the crayon company had to come to agreement on which colors
would be included in the eight-pack, so, too, did those who wanted a
simple profile of GML. In this case, those who created the GML
specification, the membership of the OGC, determined which subset of
the specification would be useful. In point of fact, any individual or
group can create and use a profile of GML. This time it just happened
to be the OGC membership, so the profile was moved through the official
OGC process, making it an open standard after an adoption vote by the
After some discussion, the group decided to include just "simple
features." In essence, only the vocabulary of "simple features" is
supported in the profile. Officially, the profile includes "points,
lines, and polygons (and collections of these), with linear
interpolation between vertices of lines, and planar (flat) surfaces
within polygons." These geometries were chosen in part to support
another specification: the OpenGIS Web Feature Service Implementation
Specification, which defines an interface for sharing and editing
vector data. Total page count of the Simple Feature Profile of GML?
Just 35 pages. (I can hear programmers "high-fiving" around the world.)
Just as its easier to make an eight crayon box than a 64 crayon box,
so, too, is it easier to add support for these roughly five
capabilities, rather than for the entire set defined in the GML
specification. What then, does this profile mean for geospatial
professionals? OGC and its membership created the profile to encourage
software vendors to step up and create software packages that implement
it. That, in turn, will make it easier for encoded data to be shared
back and forth between different packages, regardless of the underlying
code or vendor. That was the goal of GML all along, though its
comprehensiveness precluded its quick uptake in the early days. With
profiles, complexity should no longer be an obstacle.
The GML Simple Feature Profile and other GML profiles that will appear
in the coming months and years offer ways to create the right tool for
the job, thus making everyone's geospatial life not only more
interoperable, but also easier.