MapGuide Open Source serves up SQL Server Spatial

The recent FDO 3.3.0 release comes with beta support for MS SQL Server Spatial. Adding this provider to MapGuide 2.0.0 on Windows is as simple as copying a few DLLs and updating the XML provider registry.

You’ll have to take my word for it, but all of the layers here are coming from SQL Server 2008:

MapGuide Open Source using SQL Server Spatial 2008

There are a couple small gotchas that I ran into.

If your data contains geometry inconsistencies (basically anything that doesn’t match OGC geometry specs) then the February CTP of SQL Server 2008 will cause spatial queries to fail. Apparently Microsoft may be relaxing this validity requirement in future CTPs, but for now if you have “invalid” geometry, you will have to modify it.

You can find these problems with the GEOM.STIsValid() function and fix them manually, or you can get SQL Server to “fix” the problems with a statement like this:

update dbo.YOURTABLE set GEOM = GEOM.MakeValid();

The second issue was a defect in the provider that causes spatial filters to fail if you set the SRID (spatial reference) on your data. This is because with SQL Server 2008 the SRID of the filter geometry has to match that of the database, and the provider is not setting a SRID for the filter geometry.

For now, you can work around this by removing the SRID from your features with a statement like this:

update dbo.NAN_PARCELS set GEOM.STSrid = 0;

Apart from these two minor glitches, the provider is looking good so far. I’m hoping to get a chance to test it further with later releases of SQL Server 2008 and of the provider to see how well it performs.

If you get a chance to try this out and run into any further problems, please enter a good description of the problem into the FDO Trac issue tracker. The more you test now, the more likely it will work in your production environment later!

-J

P.S. Thanks to Orest at Autodesk for helping me work through these initial issues!

MapGuide 1.2 Released!

Well, after a couple months of holding back MapGuide 1.2 because of raster stability issues, it is now available for download. Tom has posted details here and here, and there is a detailed listing of all the bugs/enhancements on the release page.

So, what’s new? Lots of stuff. I really like the performance enhancements, especially around MapTips, and the ability to easily define “external” data sources. My favourite improvements are around raster handling though. Frank Warmerdam (with some help from me, Andy and Haris) made the GDAL-based raster provide a lot more stable, and added the ability to use bounding boxes in the raster config file, so that only the files required are polled. There are more details on how to use this new feature on the FDO GDAL Trac Wiki.

On the “unannounced news” front, the FDO project has quietly made a Windows build of the FDO Python bindings avaliable for download. There’s a readme in the fdopython zipfile that tells you how to install it.

http://download.osgeo.org/fdo/3.2.3/fdosdk-3.2.3_win32_release.tar.gz

http://download.osgeo.org/fdo/3.2.3/fdopython-3.2.3_win32_release.zip

This requires the MSCC++ 2005 SP1 redistributable. You can get the x86 version here if you need it.

If you’re coming to the FDO lab at FOSS4G, this is what you’ll be using.

-J

fdo2fdo Geospatial Data Tool

Today, Haris Kurtagic over at SL-King announced the latest release of his cool fdo2fdo utility.

This application hasn’t got much attention yet, but it sure deserves some. Initially used as a test platform for Haris’ open source King.Oracle FDO provider, it has quickly evolved into a general purpose FDO data transfer and inspection toolkit.

FDO2FDO Express Copy Example

Haris does a much better job of describing the functionality of this tool than I ever could in his flash movie. I really encourage you to have a look, but set your resolution to at least 1280×1024 for best viewing. As you’re watching, keep in mind that there is a command line utility included which can perform all of the common schema-related (ExportSchema, CreateDatastore, ApplySchema, CopyData) tasks. For usage you can just navigate to the isntallation folder and type f2fcmd from the Windows command line.

The demo shows SHP, SDF, and Oracle as datastores, but you can easily add any FDO provider to the application. These include things like MySQL, ArcSDE 9.1, and (read-only) any OGR-supported data format. The utility of this application is simply outstanding.

If you paid attention to the movie (and know where I work) you’ll be able to figure out my personal interest in this tool. It has allowed the City to set up a low cost one-click data synchronization between a remote field application and a corporate database. All this required was the judicial use of the “Filter” option, some saved XML transfer tasks, and pre-defined schemas. One cool feature (that we didn’t use) is that you can apply geometry filters, allowing you to transfer a specific area of interest.

fdo2fdo is currently only available in a windows binary download (with Oracle instant client bundled, which is why it’s so big), but Haris has assured me that after he cleans up the code he will be submitting at least the command line and API code to the FDO SVN repository under an appropriate OSI-approved license. Haris is new to the open source world, but he’s catching on really fast.

I believe that the API and command line tool were coded in standard C++, so I’m hoping that they can be ported to Linux shortly after he uploads them. I’m also hoping that the GUI portion of the application will be uploaded. It’s apparently written in MFC, so there isn’t an easy translation to Linux. However, it could act as a model to help someone else build a Linux-based GUI.

-J

pyFDO is in the House – Yeah Baby!

You heard me, the Feature Data Objects (FDO) team just committed initial Python support.

I’m not much of a Python hacker, but I have great respect for it. Python has strong support in the open source geospatial world (Hobu and Sean have a lot to say about it), and it is also used by proprietary software such as Safe Software‘s FME (pyFME) and ESRI ArcGIS (Hobu’s guide).

Blemishes first: this first code dump is Windows-only (Linux support is promised), and documentation is not yet available. However, the unit tests that were committed should provide an idea of how it works. I found the ApplySchemaTest to be the most instructive. I really encourage Python hackers to start looking at this. As we have found with MapGuide and Java, it can be hard to get everything exactly right with a wrapper, so I’m sure that constructive comments on the FDO users mailing list would be appreciated.

For anyone not familiar with FDO, it is a geospatial data abstraction toolkit, kind of like ODBC on steroids for vector and raster geodata. Earlier this month, following MapGuide’s graduation, FDO was accepted into OSGeo’s incubation process. The project is now taking steps towards a truly open development process, having formed its independent project steering committee (there are a couple slots available; get involved now!) and just posted its first RFC.

FDO has existing providers for many formats (such as SHP, SDF, WMS, WFS, ArcSDE, Oracle, and a whole range of raster formats), and leverages the OGR open source library to provide access to many other formats indirectly. Depending on the capabilities implemented by a specific provider, FDO can support complex geometry (three dimensions, circular arcs, geometry collections, etc), common SQL expressions, all of the standard geospatial predicates (disjoint, crosses, intersects inside, etc), locking, long transactions, and other “tough” features often associated with spatial data.

Since its initial release last year, FDO has garnered a lot of interest, with providers being developed independently by SL-King (Oracle), Refractions Research / Mateusz Loskot (PostGIS), and Safe Software (FME ; all supported formats).

I believe that with dedicated effort being applied to opening the development process around FDO, we will see a lot of good things from this project in the near future.

-J