FDO Toolbox v0.9.0

Here's a new release of FDO Toolbox.

New Stuff:

1. Support for "flattening" geometries. Previously when attempting to preview spatial data with Z or M coordinates, it will fail. Now these extra coordinates are stripped away when previewing. Geometry flattening is also a new bulk copy option (regular and express).

2. The ability to see what your geometry WKT looks like. This is used in the Expression Editor.

3. Schemas, Classes and Properties are now alphabetically sorted in the Object Explorer. Makes FDO connections with 100+ class feature schemas easier to sift through.

4. The Save Schema as XML and Save Schema as SDF commands have been replaced with a new schema saving dialog. This dialog allows you to save the full schema or a subset of the Feature Schema by un-ticking the feature classes and properties you don't want saved.

Other Stuff:

1. FDO has been updated to 3.4.1 RC2. This fixes a bug that caused the faster Object Explorer loading to not work at all. Now if you have large feature schemas, they should load faster if the provider supports the enhanced IDescribeSchema command. All previous workarounds implemented up to this point have been removed (you won't notice it really).

2. We are once again using the custom gdal16.dll from the FDO binary distribution. The original motivation for using the offical gdal16.dll was for a more capable OGR provider, but bundling the official dlls turned out to cause conflicts with the PostGIS provider. If you want a more capable OGR provider, follow the instructions here.

3. IronPython has been updated to 2.0.3

Download

Report bugs or feature enhancements

My FOSS4G presentation, recorded and online

For those who could not attend FOSS4G, here's a recording of my FDO Toolbox presentation.



Many thanks to the folks from FOSSLC for recording this presentation (and many others) at FOSS4G 2009

Why not ....

While I was walking home from work today I had a lightbulb moment.

Why isn't there a FDO provider for ... MapGuide!?

Conceptually, there is no impedance mismatch whatsoever, MapGuide builds on FDO so its knows about feature schemas, capabilities, and other FDO terminology. There is a near perfect 1:1 mapping of everything!

A MapGuide FDO provider would allow for roundtripping between a FDO client application and a MapGuide Server that would not have been previously possible.

A MapGuide FDO provider would allow you to easily pull snapshots of data from a MapGuide Server. You could bulk copy data from a MapGuide Feature Source and not care whether that Feature Source points to a SDF file or an Oracle instance, or a WFS server.

A MapGuide FDO provider would allow you to have MapGuide Feature Sources sourcing data from other MapGuide servers.

You could probably do all this through a WFS facade, but that requires configuration from the MapGuide side of things, and you would lose some of the richness of FDO by going through WFS (I know I've had to deal with things like zero-length properties from a WFS data source)

A MapGuide FDO provider wouldn't need such configuration, just feed it the required connection parameters:

• MapAgent URL
• MapGuide username
• MapGuide password
• MapGuide Feature Source Id

And you're off and racing!

There's many new possibilities with a MapGuide FDO provider. Unfortunately, I lack the C++-fu to fully explore this idea :-S

Simple FDO development tip.

When you develop any application in .net in Visual Studio using the FDO API you would normally reference the following dlls from your SDK bin directory.

OSGeo.FDO.dll

OSGeo.FDO.Common.dll

OSGeo.FDO.Geometry.dll

OSGeo.FDO.Spatial.dll

However, when debugging/running the application, you need to have *all* the files from the SDK bin directory in the application's output directory, otherwise things will break.

You could create a post-build event to copy these required files, or alternatively you could do this:

Right click your project and choose Add - Existing Item

Browse to your directory that contains your FDO dlls, select everything and choose Add As Link

Create a "com" directory in your project, and repeat this process for the .sql files in the "com" directory.

Now these linked files are in your project. They should have a shortcut overlay to indicate they are linked files. Select all these linked files, and set the Copy to Output Directory property to Copy Always

Now everytime you build your project (for debugging or deployment), your application and everything in your FDO bin directory are copied to the output directory. No post-build hackery required!

Visualizing textual geometry

Wouldn't be nice to "see" what that gibberish you just typed actually looks like?

Coming in the next release of FDO Toolbox, yes you can!

FDO Toolbox v0.8.8

Here's a short bugfix release. The installer has an updated .net framework detection routine, which should now properly work on Vista and Windows 7.

This release also includes official GDAL dlls missing from the previous release (meaning you now have a more capable OGR provider) and fixes some data preview issues with the Oracle Provider, bringing Oracle support up to a usable level.

Download

Is FDO Toolbox an FME?

Here's a question that was thrown my way during FOSS4G:

"Are you trying to do an FME?"

The answer: Yes and No.

Yes, because like FME, FDO Toolbox can do transformation of data.

But also no, because FDO Toolbox is a multi-purpose tool, of which data transformation is one such purpose. The data transformation of FDO Toolbox is for simple scenarios (converting one data source to another) and I intend to keep it this way. FME does what it does well and can handle whatever complex scenario you throw at it.

If you need to do simple conversion or basic transformation of data, FDO Toolbox is suited for the job. If you need to do complex data transformation/massaging, then use FME which was made to serve this purpose.