Radius Studio and FDO

In 2006 I spent 3 months conducting some research and development for 1Spatial under a UK Department of Trade and Industry grant. That research was predominantly aimed at investigating methods whereby their flagship product, Radius Studio, could integrate with ESRI GeoDatabase technology in a way that adds value to both company’s products. The research concluded with 3 main recommendations. One of those was the subject of a recent 1Spatial news release wherein they announced that they had integrated the OSGeo’s Feature Data Objects (FDO) technology (thanks to AutoDesk) into Radius Studio.

OK, so how does FDO add value to Radius Studio and how does this integration help with adding value to ESRI GeoDatabase technology?

First one first.

I wrote a blog piece a while ago about Feature Data Objects and have included links on the technology on my home page. In that blog piece I said:

“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.)”

While I would love to see real Spatial SQL based data access drivers around (eg ADO, ODBC, JDBC etc) so that I could, one day, Start>Control Panel>Administrative Tools>Data Sources (ODBC) and select the appropriate driver (eg shapefile, TAB file etc etc) that day has not arrived.

But FDO’s day has.

Radius Studio initially read and wrote Oracle Spatial/Locator and nothing else. To be able to connect to ESRI data-sources, 1Spatial was faced with having to write, from scratch, a data access layer for each of the data sources in the ESRI stable that customers are using to manage their data.

This is a non-trivial task particularly because of the many proprietary formats ESRI provides. And, ESRI customers, use a large range when managing their data:

• Access Personal Geodatabases
• ArcSDE Enterprise Geodatabases
• Shapefiles
• Coverages
• The new 9.2 file-based Geodatabase etc.

Developing one’s own, proprietary, data access layer is also an expensive option because it would require the purchase of ESRI software and, more importantly, 1Spatial would have to dedicate valuable staff time to learning, configuring and programming ESRI’s technology (or AutoDesk’s, MapInfo’s etc etc).

More importantly, these staff would not be able to be used to value-add 1Spatial’s own software through creating new, or enhancing existing, functionality: these staff would be wasting time “reinventing the geodata wheel” by developing low-level data access drivers.

To do this properly, so that the access layer could be reused for other GIS companies’ proprietary geodata formats, would take many, many hours of programming. In fact, once done one would end up wanting to get a return on that investment by trying to sell it in its own right. But who wants to compete with Safe Software? And, from 1Spatial’s perspective, would slow down the time to market for what Radius Studio does best: rules discovery, creation, conformance checking, correction and certification.

A “data access layer” product, would also confuse staff and customers as to what 1Spatial’s real “value add” in the data quality sector actually was!

Fortunately, FDO came along at the right time and, though many disagree as to the merits of (or motives behind) making FDO open source, it provided a number of immediate benefits:

• It came with ArcSDE read/write capability “out of the box”. This capability is “certificated” by AutoDesk to ArcSDE 9.1. There was no other open source project around that could read and safely write to ArcSDE versions above 8.3.
• FDO could read/write ESRI shapefiles.
• A new OGR provider for FDO allows for the reading of geodata stored in Personal GeoDatabases.
• FDO provided access to MySQL, Oracle Spatial, WFS also “out of the box”
• The API is nicely abstracted, portable, and well written.

(Many other providers are being written for FDO as I write.)

A trial integrating FDO into Radius Studio last year was very successful (for minimal effort). Thus, though ONE piece of engineering MULTIPLE benefits could be gained.

Ok, so Radius Studio + FDO provides access to ESRI geodata. So how does this value-add Radius Studio in an ESRI world.

Though a second blog posting I will explain.