Hands-on on an OGC API

By
Nuke Goldstein

In my last article (Common
Pitfalls When Analyzing WMS/WFS Capabilities, Oct.29 2004) I
described some of the complexities a developer may encounter when
approaching Open Geospatial Consortium (OGC) web services.By examining
the web service capabilities, that article illustrated not only
difficulties developers who are already involved with the GIS community
face, but also how hard it is to introduce newcomers to interoperable
open-geospatial solutions.Many highly talented software engineers and
project managers have only a vague idea of what GIS is.Some will
respond with "gesundheit" if you say "geospatial" to them.However, if
you are one of those folks and made it this far, I have some good news
for you.There are now tools that can handle open-geospatial
specifications by OGC and others.CarbonTools, a free software toolkit
for .NET developers, makes open-geospatial interoperability programming
a very manageable task, even for developers who are not GIS-savvy.

Unlike the previous article which shied away from source-code examples,
this and future ones will use samples based on the free and available
CarbonTools 2.This toolkit
is designed to provide .NET developers with an
open-geospatial Application Program Interface (API) suitable to experts as well as beginners.With this
open geospatial development toolkit it is now possible to move past
specifications and multi-vendor interoperability issues and approach
more complex topics, such as Geography Markup Language (GML) handling, in a hands-on way.

The Benefits of Using an API
Let's start where the previous article left off, OGC capabilities.
Without a toolkit implementing an open-geospatial API, the task of
developing software that can read OGC capabilities will generally look
something like this.

Source: The
Carbon Project.Click image for larger view.

Notice that implementing this process requires that the developer have
a good grasp of using Internet services, multi-threaded operations, Extensible Markup Language (XML)
parsing as well as a good understanding of the OGC specifications
regarding the capabilities XML.In order to "process the Capabilities
XML," the developer may need to read the Web Map Service (WMS), Web Feature Service (WFS) or other relevant
specifications, understand the issue, select an XML parser, deal with
bugs and finally validate against many vendors to find if all issues
are handled and covered.That is a lot of work.Now, here is how the
same process will look with a toolkit for open-geospatial development
like CarbonTools.

Source: The Carbon Project.Click image for larger view.

Notice that service interaction and XML parsing are handled behind the
scenes.A task of hundreds of lines of code (I'll spare you the
example) is now possible with just a few.To illustrate this, the
following source code shows how this is implemented.Notice the
code snippets are written in C#, however any .NET supporting language
will look very similar.

Source: The Carbon Project.Click image for larger view.

Easy as pie.What was a complicated and messy process is now readable
and easy to use.Furthermore, the data parsed by the toolkit is
detailed and accessible through a similarly developer friendly API.
Here's how the Capabilities data can be accessed, this example will
list all the layers received from the previous code to a console.

Source: The Carbon Project.Click image for larger view.

The Capabilities XML also contains data about the service itself (e.g.
each type of operation may describe a dedicated online resource).
Finding the correct address for an operation in the XML requires work.
With CarbonTools, on the other hand, this task is simple.For example,
let's assume we need to get the address on which the service supports
the GetFeature operation.The code will look like this.

Source: The Carbon Project.Click image for larger view.

Visual Programming with OGC
To make things even easier for open-geospatial developers, CarbonTools
offers a set of .NET controls.These straightforward components provide
drag and drop type development in a visual programming environment.C#
and VB.NET
programmers are familiar with this type of development.A new Form is a
slate into
which buttons, labels and many other types of controls can be dragged.
CarbonTools 2 currently adds two new controls; the first is
PictureBoxOGC, which extends the PictureBox .NET control to access any
WMS or WFS and display the data in an image.This control also offers
embedded map tools such as zoom and pan.The second control,
TreeViewOGCCapabilities, offers Capabilities analysis and displays the
layer items in a tree-view.The following illustrates how this control
works.

Step
one: Start new form.

Step 2 - Drag
TreeViewOGCCapabilities control to form

Step 3 - Fill in
URL, service type and version properties then update the control.

Source: The Carbon Project.Click images for larger view.

Notice that with three simple steps and no actual programming, we
managed to read, parse and display capabilities in a tree-view.The
point is to make OGC services part of the development environment and
process rather than dealing with the OGC specifications.

Future Features
The simple code samples shown in this article illustrate the point that
by trivializing open geospatial service handling, an API can expand the
range of open-geospatial developers from a select few to a large
evolving community.Where can we go from here? Here are a couple of
topics I will try to better detail in future articles.

WFS and GML
The Web Feature Service and the Geography Markup Language are powerful
specifications and technologies and we have not even scratched the
surface of their potential.Users have one common complaint about GML -
it is very hard to read and understand.The GML 3 specifications, which
are over 500 pages long, deter a lot of developers from investing the
time and effort in it.With CarbonTools, there is no real need for a
deep understanding of WFS or GML.Sophisticated parsers and a simple
API should finally break the specifications barrier.

Transactional Services
Another powerful specification by OGC is the Web Features
Service (WFS-T).This type of user-side interaction with a geospatial
web service, has a limitless potential.Allowing users to access and
alter information on the server side could revolutionize GIS as well as
commercial web services.If done right, this technology could be the
holy grail of crossing into the realm of everyday commercial use.For
that to happen, the market needs to evolve by producing better, faster
and more usable services as well as be accessible to the productive
forces out there.

Information about a training course involving CarbonTools is available.