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

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?

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.

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.

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

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.