Surveying, Mapping and GIS

I came across a post on a blog called Geoweb- the site appears to have a lot of discussion of Geography Markup Language (GML) and OGC standards. Of interest was a particular discussion about if GML is a "format". There were a number of philosophical points and comments by others, some of which were to the point of "GML is not a format" and "convert from GML and convert from GML is meaningless".

This post was very interesting, and I had a number of mixed reactions to it, mainly from the standpoint of having actually developed an OGC-compliant Web Feature Service (WFS) service from the ground up earlier this year. What we found was that there were a lot of people talking about GML and WFS, with no lack of detailed technical and philosophical discussions, but where the rubber meets the road, in terms of actual applications, they were precious few. A lot of vaporware abounded, so it seems. It also gave me a lot of appreciation for all of the hard work that people at OGC, The Carbon Project, Juan Chu Chow at Safe Software, and others had been putting in on making GML and WFS a reality.

In terms of our own reality, we rapidly came to the conclusion that a subset of GML, containing the essential data we were conveying was adequate and appropriate. The full GML schemas tend to include a lot of items that, while great to consider, aren't always appropriate for all data, and the schemas were complex, with multiple hierarchical and interlinked subschemas, to the extent of even arriving at one unified schema became difficult using the tools we had. So ultimately we took the dataset elements that we had and mapped them to a new unified schema that mapped as a subset to the full GML schemas. So in a sense we did "convert to GML". But WHAT GML? This again is where it becomes essential to have a schema...

From here it becomes a much simpler matter- making this GML data available to the client, and enter Web Feature Service (WFS). A basic (nontransactional) Web Feature Service has three basic methods: GetCapabilities, which provides the client with basic information about the service- in our instance we were performing a dynamic query of an Oracle database and presenting the matching feature services as WFS "layers", which would then be listed for selection by the user within the client. Next comes a call to the DescribeFeatureType method, which simply presents the schema to the client for validation. Finally, we have the query itself, the GetFeature method, which accepts the query parameters and returns the GML for the matching features. The proof of concept for our WFS, believe it or not, was coded, along with two test harnesses in one morning in .NET...

Initially we didn't have access to any existing tools for testing this service- we quickly latched on to the Carbon Project tools: CarbonViewer and Gaia... Here we began to notice that WFS and GML implementations were a little different, even between CarbonViewer and Gaia. The primary enterprise GIS tool in this instance was ESRI - ArcGIS and ArcIMS, and a few, myself included, felt that with all the buzz about GML and interoperability, getting the GML into ArcGIS would be no problem. Well, yes and no... The first snag was that Data Interoperability Extension is not, by default, included in the ESRI Enterprise License Agreement- partly due to their internal arrangements with Safe Software, who provides the engine that Data Interoperability Extension runs on. But ultimately this too was resolved, bringing us to the the next issue- subtleties between how FME and Data Interop Extension handle GML and WFS, and nested tags within the GML, as compared to the Carbon products. This also was ultimately resolved, the temporary but surprisingly effective quick fix being an XSLT transform on the fly within the service.

So ultimately, IS GML a format, or is it not? Even having been there, I would still say, yes and no. GML ultimately will probably never be a form for native storage of data, but will continue to exist as a format for transmission and interoperability of data, and in doing so, data does take the shape of GML- however as we are still finding that GML vaporware still outnumbers the small, but increasing number of real-world solutions, it may be that people will at least for a little while consider it to be more of just a specification or guideline, subject to interpretation. I however think its a good and workable start. There are hurdles, but it is very real and very workable.

At the recent EPA Environmental Symposium in Las Vegas I had occasion to bump into Sam Bacharach from OGC to report to him that the project was a success- I had last seen Sam in the spring at the Pennsylvania Digital Government Summit, prior to beginning the project- we had also opportunity to use the fruits of our labor to help out with Hurricane Katrina recovery efforts, as our WFS service allowed some measure of dynamic drilldown, not otherwise available in the available map services.

The limitations that we did encounter were unfortunately beyond our control, limitations in the Oracle database backend structure, which created too much spatial granularity (we couldn't query large geographic areas effectively), and on the other hand not enough granularity to allow drilldowns to very specific facility types, such as querying by NAICS/SIC codes.

In the end, we were pleased and honored to have been able to do our part for Hurricane Katrina relief in terms of applications support, along with our GIS analysts serving in the EPA Emergency Operations Center in Washington, DC to provide maps for presidential and congressional briefings and support for development of the Enviromapper for 2005 Hurricanes application. We still have that database backend redesign slated, and at some point would like to discuss the possibility of OGC certification. Currently our partner on this contract, Lockheed-Martin is listed as an OGC partner, and Sam Bacharach tells me OGC has been working very closely with LM of late.