No more short coffee breaks in VS2010

As some of you may know, when you invoke the Add References dialog in Visual Studio, you might as well go for a coffee break, because the .NET and COM references take f o r e v e r to load. It is especially annoying when all you want to do is add a reference to another project from the same solution!

Well in Visual Studio 2010 (Beta 2), this is no longer the case. Invoking the Add References dialog is super fast! The reasons being:

1) .NET and COM references are now loaded asynchronously in the background.

2) The default tab is the Projects tab (which is the one I go for most of the time)

Truth be told, I would happily upgrade to VS2010 just on this one feature. But I'd probably lose out on the coffee breaks :-)

To those who got email spammed by me today...

Apologies.

My gmail account was compromised this morning by someone operating out of Beijing, China (at least that's what IP geolocation tells me).

My current theory is that it was due to me momentarily losing all semblance of sanity and reason, by falling for a Twitter phishing scam. Although I promptly changed my twitter login after discovering this fact, it must've been hunting for any similar logins and found my gmail account.

So now I'm off to change every login I conceivably know of. Regular programming will resume shortly.

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