CEO, The Carbon Project
Digital mapping has been the exclusive domain of professional GIS users until recently when Google released a friendly mapping system named “Google Maps”. Google Maps gave Web developers the ability to add mapping to their websites without consulting the mapping specialist. Suddenly GIS was both a cool and indispensable feature of websites. Not to be outdone, Microsoft quickly followed suit with “Virtual Earth” and mapping is now a mandatory component of nearly all Web sites. Though this kind of simple “mash-up” mapping opened new possibilities for developers, it didn’t change the way geospatial software is designed, developed or applied, and it did little to help programmers use the growing number of geospatial content sources like KML, GML, Web Map and Feature Services and others in their desktop applications. However, The Carbon Project, a world leader in geospatial interoperability, responded to this challenge with a software development framework called CarbonTools PRO™.
The “Comfort Zone” of Programmers
The need for this type of interoperability is clear to anyone who has been tasked with creating a software program. This is not the forum to engage in an academic debate over semantics and high level concepts. Let’s just say that to most developers charged with making software that works, this argument is irrelevant. What’s relevant is a realistic path to produce the best software using their limited time and resources. This practical approach of applying a software solution to geospatial interoperability is the core motivation behind CarbonTools PRO™, and a new generation of geospatial interoperability that’s fast becoming reality.
As an example of the role of CarbonTools PRO in software development consider how programmers use a common graphics format found on the Internet, in Word documents, and in digital cameras, the Joint Photographic Experts Group format (better known as JPEG). The JPEG format is far from simple; it uses sophisticated mathematical algorithms to support data compression. Would JPEG be in common usage if a developer needed to regularly refer to instruction manuals about compression techniques? The answer is clearly “No”. It is the ability to develop applications using common tools, such as Visual Studio and frameworks such as Microsoft .NET that have become intuitive to developers, that makes the JPEG format both viable and ubiquitous.
The Carbon Project® developed CarbonTools PRO with this very concept in mind. Looking through the eyes of the developer, the goal was to provide all the tools necessary to add complex geospatial data types and services to their applications using a language that’s in the comfort zone of the programmer rather than the GIS professional – much the same as JPEG is handled by non-mathematicians using the .NET Image class. CarbonTools PRO accomplishes this task by extending the Microsoft .NET framework rather than merely providing a stand-alone toolkit. The concept of extending the framework also means more than just publishing software libraries. It means providing documentation that looks and feels like the mainstream framework user guides programmers are familiar with, providing code samples in popular coding languages and even a licensing structure that doesn’t limit the application developer in distributing their work (Imagine the horror and global outrage if Microsoft demanded a “per-seat” fee on software developed using the popular Visual Studio!).
Handling the many varieties of content found in the geospatial market isn’t as simple as manipulating a JPEG. It is a fact of life that geospatial content and services come in many varieties and formats. A minimal “must interoperate” list then would include:
- Tile-based mapping services (Google Maps, Microsoft Virtual Earth, Yahoo! Maps etc.)
- Region-based mapping services (OGC WMS, WCS etc.)
- Features-based services (OGC WFS, Google's KML network links, Yahoo! Traffic Web Services, GeoRSS feeds etc.)
- Features files (ESRI Shapefiles, Google Earth KML, GML, MIF, DXF etc.)
- Raster files (JPEG, TIFF, GeoTIFF etc.)
- Metadata sources (catalogs, OGC Capabilities etc.)
It’s somewhat daunting that the GIS and mapping community produced such a diverse range of data formats and service types over the years. These varying standards and formats has created a nightmare for the software developer and while there are significant efforts at trying to converge to a unified standard or platform (like the OGC SDI 1.0 specifications) none actually aims to do for geospatial content what the Image class in .NET does for JPEG – allow programmers to spend more time meeting software requirements rather than dealing with the tedious low level details of providing a working system.
A New Architecture
To construct a framework for geospatial interoperability, CarbonTools PRO takes a fresh design approach called the Source-Handler-Data™ architecture. This design makes working with many types of complicated geospatial content a task that can be easily handled by most software developers. For example, if a programmer wants to add maps from a Spatial Data Infrastructure Web Map Service to an application's map control, the C# code snippet will look something like this:
To add features from an OGC Web Feature Service the same Source-Handler-Data™ coding pattern is used. In this example the GML features layer will be a “Hospitals” from a Spatial Data Infrastructure service:
To add a Shapefile layer to the map control we can use the following C# code snippet:
Map tiles from Microsoft Virtual Earth may be added the same way:
What these examples show is one of the principals of true interoperability – that the data format, form or even the way it is served is not as important as the ability to use it in a common software framework. CarbonTools PRO applies this principal to geospatial interoperability with a framework that addresses multiple formats and forms, while exposing a unified language that feels like a natural extension to the Microsoft .NET framework to software developers. But this is just the beginning of geospatial interoperability and where the real fun begins!
CarbonTools PRO makes it easy for software developers to use all types of geospatial content and services in their applications – including WMS, WFS, GML, Shapefiles, Microsoft Virtual Earth and more
More than a Mash-up
So what can developers do with a product like CarbonTools PRO? A good example is CarbonArc PRO, an extension for ESRI’s ArcGIS 9.2 software created with CarbonTools PRO. CarbonArc PRO wraps content and services from OGC SDI 1.0 and Microsoft Virtual Earth into a set of tools that are easy to use right from the ArcGIS desktop. By plugging into ArcGIS, CarbonArc PRO lets people use any OGC SDI 1.0 Web service and Virtual Earth as an integral part of the GIS, including Hillshade Maps, Aerial Maps, Road Maps, WMS, WFS, WFS-T, WCS, Filter Encodings, Gazetteer, GML, GMLsf and Catalog Services (CS-W). CarbonArc PRO eases existing GIS into all these new geospatial content types and services with minimal expense and disruption because it’s based on a software framework for geospatial interoperability – CarbonTools PRO.
CarbonTools PRO not only includes tools for access to new geospatial content types and services it also wraps very complicated standards into tools that are easy for programmers to use. For example, OGC SDI 1.0 has some pretty complicated concepts, like WFS Filters, that would be pretty hard for programmers to figure out without the advances provided by CarbonTools PRO.
WFS Filter is one of the most powerful (and least understood) technologies in OGC. The basic concept of a Filter is to provide a SQL-like spatial and logical language to make advanced data queries possible in a web services environment. Filters do this by employing a series of logical (“AND” this, “OR” that), comparison (is this “Equal To”) and spatial (does that road “Intersect”?) operators. When wrapped up into easy to use tools like CarbonTools PRO, the Filter Encoding (FE) specification lets programmers quickly add complex and powerful geospatial web service queries to their applications. This means is a quantum leap in technology from the days when geospatial content was delivered as files and CDs – and a big step beyond simple “mash-up mapping” like Google Maps.
One example of how Filters and a framework like CarbonTools PRO can be used by programmers to create new applications was demonstrated at the recent Canadian Geospatial Data Infrastructure (CGDI) Interoperability Pilot, viewed by over 500 online attendees, on November 30, 2007. One part of the demo illustrated how emergency analysts would employ OGC Filters, WFS services and data from CGDI – for analysis. The project had the requirement to use a simulated release plume polygon to construct new features such as impacted roads and places. This involved intersecting release plume polygons with impacted areas, but the project wanted to show how the online CGDI service could be used do the analysis, instead of using the traditional approach of doing the analysis on the desktop GIS.
Here's how it worked – we used CarbonTools PRO to quickly create an application to run in the ArcGIS desktop. With this application a user could select an existing GML or Shapefile feature (a release plume polygon), construct an OGC Filter Encoding request using Spatial Operators (in this case it was the Spatial Operator "Intersect"), send it to CubeWerx Web Feature Service, and acquire impacted roads and places from the WFS in GML. Finally, the results were overlaid on top of a CGDI WMS or tiles from Microsoft Virtual Earth. The application was showed working “live” in front of an online audience of 500 people after just a few hours of development with CarbonTools PRO, and it worked flawlessly.
CarbonTools PRO not only includes tools for access to new geospatial content types and services it also wraps very complicated standards, like OGC Filter, into tools that are easy for programmers to use
CarbonTools PRO is already in use around the world and changing the way geospatial software is developed, and helping programmers use the growing number of geospatial content sources like KML, GML, Web Map and Feature Services in their desktop applications. Obviously, there’s a lot more that can be done by innovative programmers but we hope this article has given you a taste of the new generation of geospatial interoperability made possible with CarbonTools PRO (www.CarbonTools.com).
For more information contact: [email protected]