Feature Data Objects – Either/Or?

I have been doing some Research and Development (R&D) work for company in the UK. As part of that R&D I have been asked to recommend a method whereby their products can access some of the many proprietary geospatial formats that exist in geospatial-land.

I had seen the announcements on the open source verison of MapServer MapGuide and its related Feature Data Objects (FDO) technology. But other than a cursory look at early release documentation, I had not had a really good look.

But this R&D project forced me to have a deeper read. I am impressed by what I read. Enough to recommend the integration of FDO into the UK company’s products and into my friend, Val MacDuff’s, excellent and totally unknown, enterprise geospatial access and collaboration product IntraGIS (www.intragis.com.au). In fact, I have downloaded the FDO source code and am currently trying to work out how to compile it in Microsoft’s Visual C++ 2005 Express Edition so that I can give Val some guidance as to an interop layer for IntraGIS.

So what’s special about FDO?

First off it is production quality code that if AutoDesk had not released to the public domain would have remained hidden within their product range.

Bouquet to AutoDesk for having done this!

Secondly it provides a standardised interface that programmers can use to access a range of existing geospatial data formats, not just one. The lack of a production quality standardised access API for the myriad of geospatial formats that exist, has been one of the great anchors on the good boat GIS for too many years. (That is not to say that Safe Software haven’t done a good job of making spatial data more accessible.)

Again, thanks to AutoDesk for having done this.

However, there are brickbats.

Firstly, my database experience seems to coincide with what most of the IT (as against GIS) developers have asked me for over the years when I have tried to help them access geospatial data within their business-computing domain. They have asked for JDBC/ADO/OLEDB/ODBC drivers which hide the physical (proprietary) implementation details of any one format enabling abstract access via SQL.

This is a different interface to a pure abstract API: and it is one that is still missing in the geospatial industry. It is also a different interface to one that exposes geospatial data via web services through use of OpenGIS standards like GML and WFS etc. The latter is, generally, about access to external data while the former is, generally, about access to internal data.

We should also ask ourselves how stable APIs are over time.

I have also observed, over the years, that APIs change a lot. For example, ESRI’s ArcSDE API has changed a lot since SDE 2.0; Oracle’s Spatial Java API has changed between 8i and 10g; the current GeoTools API (2.2) is about to change; etc etc. When I think of the expression common to Windows COM programmers – “DLL Hell” – it would appear that my experience corresponds with a certain amount of reality!

Last week I heard Gary Lang, Vice President of Engineering for the Infrastructure Solutions Division, give a presentation at a conference in the UK that included reference to FDO (he announced that an OGR provider had been written for FDO and would be made publically available very soon). I also heard Ron Lake, Chief Executive Officer, Galdos Systems Inc talk about a new Spatial Data Infrastructure based on GML and OGC web service offerings. At the end, I asked them about the instability of APIs and whether the FDO API would pass this test. I also asked them to comment what my IT developers had asked me for in SQL style access though ADO etc drivers. The answer from both was that XML and associated standardised access technologies had removed API stability as an issue and would provide the abstract access that my developers wanted.

Au contraire!

XML is not a logical language that everyday “domain experts” – Engineers, Foresters, Planners etc – use. XML etc might be “enabling technologies” for web services and familiar territory to developers, but they are not an expressive, everyday language in which end-users (my “domain experts”) express what it is that they want in an implementation independent manner. Many of these people, as I (a database expert) do, use SQL everyday. I argue that it is much easier for an end-user to express, and test, his information needs in a declarative language like SQL, than an alternative method based on XML. How does a user express his needs in pure XML? For example, I have yet to see one start sqlplus (for Oracle), and start typing in an XML document to express his information needs: SQL is used.

So how about a more inclusive argument based on a collection of technologies. For it is about time that the geospatial and database communities obliged by giving us Spatial SQL access to data regardless as to file format.

In summary, the argument for data access APIs is a “Both And” argument and not an “Either Or”.