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.This article will describe how CarbonTools, a free .NET geospatial development toolkit, can make open-geospatial programming a manageable task.—Article by Nuke Goldstein, founder of The Carbon Project.
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.
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.
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.
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.
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.
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.
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.
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.
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.