Announcing: FDO Toolbox 1.0 beta 3

Here it is! The 3rd beta of FDO Toolbox 1.0

Some of the highlights include:

• A new type of automated task: Sequential Process
• FDO 3.6.0 (build F037). Like I said previously, the old PostGIS provider is no longer bundled.

Along with some fixes:

• FDO Data Stores containing Object and Association properties can now be exported
• Improved Object and Association property support in the Data Store Editor
• Insert/Update/Preview support for Object and Association properties. Many thanks to Crispin for providing this patch
• Geodetic polygons with bad orientation are fixed when bulk copying to SQL Server 2008

Download

Report Issues/Enhancements

FDO RFC48: Easing some of the pain of copying data to SQL Server

The next beta of FDO Toolbox will come bundled with a beta version of FDO 3.6.0

The reason for the move is because FDO 3.6 incorporates RFC48, which provides APIs allowing us to correct the orientation of polygons.

Where is this API most relevant? Copying data to SQL Server 2008.

For those of us who fell for the "Microsoft Technology v1.0" trap (because frankly Microsoft never gets things right on the first attempt!), SQL Server has strict rules regarding geography types (FDO will create geography data types if your FDO Geometric Property uses lat/long coordinates). If you try to insert polygons with invalid orientation into a geography column, SQL Server will automatically reject the input. A post-insert MakeValid is not possible.

This basically meant that copying polygons (with lat/long coordinates) into SQL Server had a high chance of failure, with no way to correct the problem.

Apparently the next version of SQL Server (codenamed "Denali") will be more lenient with regards to geometry correctness (among other things) rendering this point moot. But that is the future, and we are in the present! With the next beta of FDO Toolbox, RFC48 APIs will be used exclusively for copying data to SQL Server 2008, ensuring a more pleasant bulk copy experience.

These new APIs are generic, so I can look at making the geometry correction available to all providers in the future, but for now this is only for SQL Server as it is the most relevant provider requiring such services.

A PostGIS Public Service Announcement

If you use PostGIS, avoid using the OSGeo.PostGIS provider. It hasn't been maintained for quite some time now and there are many un-fixed stability and performance problems that have made this provider unsuitable for production use.

Instead, use the OSGeo.PostgreSQL provider which is included in the 2.2 release of MapGuide Open Source (currently in RC), Autodesk MapGuide Enterprise 2011, AutoCAD Map3D 2011 and recent releases of FDO Toolbox.

The OSGeo.PostgresSQL provider is built on the same robust core as the MySQL, SQL Server and other RDBMS providers, and provides better stability and reliability than the old provider.

The OSGeo.PostGIS provider is not included in the next version of FDO. The next beta of FDO Toolbox will not include this provider, as it is using the next version of FDO.

So for those still using the old provider, take this as a warning to start migrating your PostGIS connections and layers in MapGuide over to the new provider before it's too late!

Introducing: SequentialProcess

Ever tried to chain multiple calls to FdoUtil.exe using a batch file?

I did recently on a client site, and found out that for one reason or another the Task Scheduler feature of Windows Server 2008 decided that the batch file I wrote was not going to run. After trying to find out the reason why (with no success), I tried running the individual calls to FdoUtil.exe with the Task Scheduler. Lo and behold they ran!

So armed with this knowledge, I have introduced a 3rd task type into FDO Toolbox, which will be in the next beta release: The Sequential Process.

A sequential process is simply an XML document that contains a series of calls to FdoUtil.exe, with an option at each invocation to abort the process if the previous FdoUtil.exe invocation returns a non-zero result (FdoUtil.exe returns 0 on success, otherwise it returns one of the predefined values here)

So for example, you can define a sequential process like so:

1. Run a SQL command to delete some rows

2. Execute a bulk copy task file (eg. SDF to SQL Server)

3. Run a SQL command to rebuild indexes

The SequentialProcess document would look like this:

Here's what it looks like visually (yes! This will have design support):

When you run this sequential process. Each step will be run as a separate FdoUtil.exe process, with the root process waiting for a return result from this process before continuing onto the next step.

For reference, FdoUtil.exe currently supports the following commands:

• ApplySchema
• CreateDataStore
• Destroy (data store)
• DumpSchema
• CreateFile (data store)
• RegisterProvider
• UnregisterProvider
• BulkCopy
• RunTask
• ExecuteSql

The sequential process task has opened up the design space for more FdoUtil.exe commands. So this list will definitely grow in size in future releases.

And yes, the RunTask command now supports SequentialProcess documents, so theoretically speaking, you can also nest Sequential Processes and other supported task types.

As I said before this is task scheduler friendly (the main reason for introducing this feature), so you can hook this up via the task scheduler for painless daily data updates or other automated spatial data maintenance.