Thursday, 5 November 2009

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

Wednesday, 4 November 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

Friday, 30 October 2009

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!





Tuesday, 27 October 2009

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.

Thursday, 22 October 2009

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.

Wednesday, 21 October 2009

FDO Toolbox 0.8.7 (Fresh from FOSS4G)

Here's a new release of FDO Toolbox, fresh from the FOSS4G 2009 conference. This was the exact build I was demonstrating during the presentation, which went better than I expected.

Being my first presentation (ever!), I had been frantically practising the night before just to get the content and pacing right. I guess it all paid off at the end, as the presentation went quite smoothly, with none of the stuttering and loss of words that I had during my test runs :-)

The new main features include:

Enhanced Bulk Copy

The bulk copy mechanism has been drastically improved in this release, it has a whole new user interface and XML file definition. The changes are too much for this post, which I will leave for a future post.

IronPython Scripting

With the introduction of a IronPython scripting engine, FDO Toolbox now has a 2nd extensibility point. You can now customise and drive FDO Toolbox through python scripts. I will be posting some example scripts in the near future to demonstrate what can be done with a scripting engine.

The side-effect of introducing IronPython is that the minimum .net Framework requirement is now 2.0 SP1. The installer has been updated to check for this version. If you have .net Framework 3.5 (or 3.5 SP1) installed, you will already have this installed.


Note: My presentation slides are also available for download from that site. The presentation (as with every presentation at FOSS4G) has been recorded, so expect a video version to crop up soon.