Straws in the Wind Blog Articles
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:
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:
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:
(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.