FDO Toolbox status update

It's been a while since the last release of FDO Toolbox. Previously, I stated that things would be business as usual. As ambitious as that statement was, the sad reality is that since starting my 2nd software development gig, my work-related projects have taken higher precedence over my personal projects, and when there are a lot of work related projects to get out the door, that leaves little room to continue development of FDO Toolbox (as you would imagine)

Does this mean the FDO Toolbox project is dead? No way! Rather the correct term would be that the project will be "on ice" to be thawed out (hopefully) in the near forseeable future. In the meantime I am happy to accept any patches or any applications for project membership (on a case-by-case basis of course) to continue development of this tool that has so much potential.

Gettin' swiggy wit it

Besides working on FDO Toolbox, another thing I've been doing lately is trying to learn SWIG and attempting to grok all the nice things you have to deal with from trying to wrap an API written in C++ :-)

One of the oddities I have noticed with the FDO API is that the managed bindings are coded "by-hand" unlike its geospatial cousin, which uses SWIG to do all the dirty work. The current bindings for FDO has a few shortcomings.

1) Because of the "coded by hand" nature, the Managed wrapper API is almost always behind the C++ version. Cases in point: Missing methods/properties and the FDO Expression Engine. Us .net people still can't get to use them yet!

2) The current .net wrapper is not inherently "portable", in the sense that I could run a certain .net application using the current managed FDO wrappers in an alternate .net environment. This is because the current FDO wrapper is a mixed-mode assembly, meaning it is inextricably tied to windows. At least with the SWIG approach, things are done via P/Invoke which is a more portable method of managed/unmanaged interop (in that we can attempt to make it portable).

3) Not a lot of language variety. Only .net and Python bindings exist, which are both in in various states of neglected/lagging maintenance and cruftiness. There are some really useful java geospatial applications out there that can be even more useful with FDO integration! Also, a good swig wrapper can serve as a useful template for creating bindings to other languages in the future.

FDO is a wonderful and ambitious API. But for FDO to really succeed, I truly believe that it needs more than a .net wrapper.

Back to the front

Next week I am returning to the place I thought I would never be going back to. (I guess they got wind of what I've been working on since I left).

It's a strange, slightly awkward feeling going back to your previous job, seeing people who you thought you may never see again, and seeing the new faces that have popped up since you left.

In light of these turn of events, what will happen to the FDO Toolbox project?







































Nothing. Business as usual. :-)

FDO, MapGuide. I pronounce you husband and wife.

One of the other major new features being currently worked on at the moment is integration with MapGuide Open Source/Enterprise.

Since MapGuide itself uses FDO for data access and its Feature Service API being similar to FDO. FDO Toolbox integration with MapGuide is a very useful feature to have. This integration exists in the form of an Extension Module.

One of the original design goals of FDO Toolbox apart from being a GUI front-end to FDO, is to be as extensible as possible. The MapGuide extension module is more-or-less a realisation of this goal.

To enable MapGuide integration, you would load the MGModule.dll via the Load Extension command.



Once loaded you'll notice something has changed. A new MapGuide application menu and a MapGuide Servers node in the Object Explorer



Now you can establish a connection to a MapGuide Server by right clicking the MapGuide Servers node and selecting the Connect to a remote MapGuide Server command (also available from the MapGuide menu)



From here it's like starting up MapGuide Studio or MapGuide Maestro. Provide the Site URL, Username, and Password.



And now you'll see all the feature sources for that particular server.

You can right click any feature source to bring up the Data Preview command


This will load up a Feature Source Preview tab for that particular feature source. This is very similar to the Data Preview tab for FDO connections, with the following differences.

• There is no Expression Editor support for constructing filters. The reason is because the expression functions are not exposed via the mapagent, thus we cannot determine what expression functions are available for us to use. Nevertheless, the filter in MapGuide is the same as the filter in FDO. For MapGuide Open Source 1.2 or earlier expression functions do not exist.
  

• The map preview tab will open the Schema Report page of the MapGuide web tier.

This is just only the tip of the iceberg as far as MapGuide integration goes. There are still many possible ideas yet to be realised.

If you work with MapGuide on a consistent basis then I invite you check out and play around with the latest trunk build from subversion and to contribute any suggestions and/or ideas on how we can best leverage this FDO/MapGuide "marriage" (and you were wondering what the title was all about!? :-)

Edit: A special thanks goes out to Kenneth Skovhede, author of the MapGuide Maestro API library for which this feature cannot exist without.

Visual Data Preview in FDO Toolbox

As a result of a successful proof of concept, I have just landed an update on the svn trunk that allows you to visually preview data sources in addition to the standard grid view.

Here's what a standard query looks like.


And now here's what that same query looks like in the map view.



The map view reflects the contents of the result set, so if I were to query all countries starting with A, I would get the following:


There are stills a few kinks to be ironed out. The map preview is known to fail if there happens to be invalid geometries in the data source. Also the map preview will be slower on large results (naturally).

Expect to see this feature in the next release or for the adventurous, you can check out the latest subversion revision.