Time for something slightly different…
Feature Data Objects (FDO) is an open source C++ based spatial data abstraction library, allowing potential access to a large amount of spatial functionality including advanced items like rasters, complex geometry and long transactions. This plugs into a lot of different formats using a common API, and managed (.Net) and unmanaged interfaces are provided.
FDO was originally authored by Autodesk for inclusion in the Map 3D product, and then granted to the Open Source Geospatial Foundation (OSGeo) as a sub-project of MapGuide Open Source. For more history of FDO, please check out the osgeo.org FDO History page. While three providers (Oracle, MSSQL, and Raster) contained proprietary Autodesk technology and were not open sourced, many providers were. The initial providers included in the fdo.osgeo.org repositories included providers for SDF, ESRI SHP, MySQL, ESRI ArcSDE, ODBC, OGC WFS, and OGC WMS.
One of the main reasons that I’m writing about this now is that this fledgling open source project really seems to be picking up some steam. Since the initial release, Autodesk (Traian) has added a basic FDO provider for OGR, and Frank Warmerdam seems to be getting close to completion of the GDAL-based open source raster provider. Refractions Research (Mateusz Loskot) has been working under contract to my employer, the City of Nanaimo, to create a high-function PostGIS provider. And, just today, Haris Kurtagic announced on the MapGuide Users mailing list that the SL-KING Oracle provider would be moving into the OSGeo FDO project as an open source provider. This is great news for users that want to use MapGuide with Oracle XE, since this platform is not supported by the Autodesk Oracle provider. Now all we need is for someone to write an FDO Provider for the open source MS SQL Spatial package, and all of the common databases will be covered.
On a somewhat different front, FDO is already being supported in a limited extent by Safe Software it its FME product, as this is what is allowing them to write to the new SDF format. A little bird told me that this support would be extended by providing an FDO provider for FME (think of it as an open API for reading over 100 formats) and, in the longer term, a generic FDO reader/writer for FME, allowing for you to write your data out in an optimal format for the FDO providers.
My fondest wish is that other GIS application vendors take advantage of this data abstraction library and integrate it into their products. Imagine having full access to all of these formats for free. Access to SDF alone is a great benefit as it allows you to have a highly capable local geodata store, which supports rich geometry, multiple tables, and spatial indexing all in a single file. Did I mention that it’s free? :)
There is a slight downside. While most of the providers, including the OGR and King.Oracle providers, are available for the current release of MapGuide, the PostGIS and GDAL providers will only be avaliable once MapGuide is built to work with FDO version 3.2. If you’re ambitious, you can always download and compile the latest versions of FDO and MapGuide yourself. (it’s not that bad…), otherwise you’ll have to wait a bit.
-J
#1 by Chris Tweedie on September 28, 2006 - 7:44 am
I agree Jason that the FDO stuff needs more of a push.
The whole idea of an easy to use abstraction library is awsome. Like most things FOSS, once things start cranking up – they will come. The issue you mentioned with versioning is probably the biggest negative from my pov
One of these days i’ll have a crack at improving the WMS/WFS stuff … it could do with some improvements.
#2 by Alexandre Leroux on September 29, 2006 - 11:08 am
Hi :-)
What’s the relation between GEOS (http://geos.refractions.net/) and FDO?
Thanks!
#3 by Jason Birch on September 29, 2006 - 10:31 pm
Hi Alexandre,
DISJOINT :)
I am certainly not an expert on FDO, but I don’t believe that there is any code-level relationship between GEOS and FDO.
One of the things that interests me most about FDO is that it is comprehensive, but allows the individual providers to decide what functionality they will expose. Case in point, many of the open source providers only support a subset of the Egenhofer relationships. These could likely be enhanced with the use of the GEOS library. Spatial querying is only a subset of what FDO does though. It also supports standard attribute queries, user management, data creation, etc.
Jason
#4 by Ricardo Stuven on October 4, 2006 - 1:22 am
Hi, I’m one of the developers of MsSqlSpatial. I’ll be happy to collaborate with anyone willing to implement the FDO provider to this data source. You can contact me in the project forums at CodePlex.
#5 by Frank Warmerdam on October 4, 2006 - 11:16 am
Alexandre,
Skimming the code it seems that FDO does not use GEOS, but MapGuide does. I’m a bit surprised, since I had assumed FDO offered various spatial query predicates and that some of these were implemented using GEOS. But it seems that isn’t part of FDO itself.
PS. I think Jason is being a bit optimistic when he says building fdo and mapguide from source isn’t all that bad a task. I think I have succeeded but it was hard on me.
#6 by Jason Birch on October 4, 2006 - 1:52 pm
Frank,
I would wager that when FDO was started it was as a properietary project. I do think that rolling GEOS in would make it a lot easier to implement some of the missing functionality from non-RDBMS formats such as SHP, SDF, etc.
Maybe I should have qualified my assessment of the build process as “it’s big, but fairly easy to do on Windows”. The FDO compile was a lot better documented than the MapGuide one, but even using the old documentation for MapGuide it only took me about a day to figure out a repeatable build process (update my local svn repository, export to a build area, build fdo, install fdo into the mapguide build tree, build mapguide), and then I think it takes a couple hours to run the build — I haven’t timed it.
#7 by Bernard on January 9, 2007 - 10:48 am
Jason, I’m confused. What the is relation between FDO abstraction layer and GML which (from what I understood) was meant to define open standard for GIS data? Is GML thought as another data source for FDO? I’m kinda newbie to GIS world, and I’m overwhelmed by zillions of data storage standards. I thought the idea behind GML was to provide a base language to describe data and remove need for ESRI shapes, VMAPs and so on, and so on. What is the current direction GIS community is going in the area of data interoperability?
If I were to create GIS environment to view/edit/store maps what data storage format should I use for greater compatibility and interoperability with OSS/propertiary tools? I would choose GeoTiff for raster date, but what about vector data?
#8 by Jason Birch on January 18, 2007 - 4:27 am
Bernard,
Sorry for the late response.
GML is primarily a data exchange format. FDO is a data abstraction layer (similar in concept to ODBC) that allows applications to access spatial data through a common set of functions regardless of the underlying format.
FDO (and similar projects like GDAL/OGR, also at OSGeo) strive to make your choice of data storage format less important. We typically believe that you should be able to store your data in the format that makes the most sense to you.
That said, the format you will actually use depends on many factors. If you are using proprietary tools in a mix with open source tools, you will likely want to stay with something like shapefiles (these seem to be the lowest common denominator). Depending on your needs, you may be able to go with a different storage format while giving up the ability to edit in some of the tools.
To discuss this further and get the experts’ opinion, I’d strongly encourage you to join the osgeo-discuss list at http://lists.osgeo.org/ and ask the question there.
Jason