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.
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.
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.
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.
From Our Homepage
Saying Farewell to an Amazing Journey
Communicating with Maps
Is There a GIS Career Ladder?
What does it mean to be geospatially smart? Series
Ways Real Estate and Property Developers Utilize Melissa GeoData for Data-Driven Decisions
Unlocking Value From Daily Satellite Imagery and Insights
Maximizing the Value of Your Address Data with Geo Addressing
How Indoor Mapping Enhances the Security of Smart Buildings
Look Ahead: AI, Location Intelligence and Efficiency
Collaboration Takes on Sea Level Rise & Dynamic Technology Environments
Brownies for Brownfields
Has Everything Been Mapped Already?
How Is Data Literacy Changing in an Artificial Intelligence Landscape
Portfolios for GIS Professionals: More Than Just Maps
How to Create a Distance Matrix in QGIS - A Step-by-Step Guide
7 Ideas for Bringing GIS into the K-12 Classroom
The Geography of Movement