You are 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 big deal?

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 membership.

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 it’s 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.