Archive for category FDO

FDO’s SpatiaLite Support Goes Native

Earlier today, Haris Kurtagic at SL-King announced the initial release of a new FDO1 provider for SpatiaLite. This is great news, adding to the native SpatiaLite2 support ecosystem which includes GDAL/OGR, QGIS, GeoAlchemy, and probably others (let me know in the comments!).

Being in a precipitous mood, I decided to plunge in and get my clichés wet. The first step was to attempt to use the new provider with Jackie Ng‘s FDO Toolbox, my go-to GUI tool for examining FDO data sets. I followed these steps:

  1. Downloaded the 32 bit FDO 3.5 version of the new SpatiaLite provider from the SL-King website.
  2. Copied all of the files into my C:\Program Files\FDO Toolbox\FDO directory.
  3. Copied the contents of the providers_kingspatialite_entry.xml file into the providers.xml file before the closing FeatureProviderRegistry tag, modifying the FDO version string to 3.5.
  4. Discovered that something had a dependency on the MS Visual C++ 7.1 runtime, so I found msvcr71.dll and msvcp71.dll on another PC and copied them into the same directory

With this in place, I was able to quickly connect to the SpatiaLite demo database:

And browse and visualize the data:

Confidence buoyed, I decided to take it a step further and attempt to connect to the same data in MapGuide. The initial steps were the same as for FDO Toolbox (adding the provider to the MapGuide FDO folder).

Once configured, I was able to quickly add a connection to the test database, but I had to manually hack in a coordinate system reference and map extents. This is due to an incompatibility between SpatiaLite and MapGuide’s coordinate system handling, and I’m hoping that the WKT projection support in the next version of SpatiaLite allows Haris to fix this.

With the data connection and its spatial context override in place, creating layer and map definitions was dead easy, and allowed me to quickly get to data visualization.

Next Up? Making the SpatiaLite FDO provider work with GeoREST. Out of time for tonight though…

UPDATE (2010-09-01): I was able to get the SpatiaLite provider working with the current preview version of GeoREST with very little difficulty, and the next official build of GeoREST will probably include this provider. If you’d like to play around with it earlier, you can download a totally unsupported package of GeoREST with Spatialite from my temp files area for a limited time only :)

-J

Notes:

1. FDO is a geospatial object/relational mapping framework, allowing consistent programmatic access to dozens of GIS data formats. It is used by MapGuide Open Source, FDO Toolbox, GeoREST, Autodesk’s geospatial products like Topobase, MapGuide Enterprise and AutoCAD Map 3D, and is also included in applications like Safe Software‘s FME and 1Spatial‘s MapRelate.

2. SpatiaLite takes SQLite‘s concept of database-in-a-file, and turns it into geodatabase-in-a-file, offering a full suite of geospatial query abilities in a lightweight extension to SQLite. FDO already has a robust SQLite provider that uses its own open geometry format, metadata, and spatial functions. In contrast, SL-King‘s new provider is intended for users who prefer to use the SpatiaLite geometry format, and takes advantage of SpatiaLite’s built-in GIS capabilities.

, ,

1 Comment

Python FDO Spotted in the Wild

Sean’s right, it does look a lot like C++. Still, it enabled Rick to build a Linux-native SHP to SDF conversion tool when the alternative (actual C++) would have been painful. Good to see it being used!

-J

,

1 Comment

SQLite Spatial Files in FME 2009 through the Magic of FDO

Writing the FDO/GDAL style of SQLite spatial files (see previous post for details) just got a LOT easier for those of us using Safe Software’s FME Desktop, even the affordable Base edition.

Over the past month, developers at Safe Software and the author of the FDO SQLite provider have put some time into ensuring that the SQLite provider will work properly with FME 2009. Reading worked fine out of the box, but writing required a bit of effort. FME needed datastore creation and schema writing added to their generic FDO writer, and the FDO SQLite provider needed to account for the way that FME writes to multiple schemas.

Here’s how you can take advantage of this provider in FME (and in other FDO 3.3 consumers, such as MapGuide Open Source 2.0):

  • Download the unofficial binaries for the SQLite provider from my site
  • Open this zipfile and copy the SQLiteProvider.dll file into your FDO directory (default c:\Program Files\FME\plugins\fdo\)
  • Make a backup of the providers.xml file in that directory, and then edit the original, adding the contents of the sqlite_provider_entry.xml file in an appropriate location.

Once this installed, writing to SQLite from within FME is dead easy…

1. Add new FDO Destination Dataset:

2. Go to Settings and specify OSGeo.SQLite.3.3 as the provider name:

3: Specify the filename you want to write to:

4. Optionally, set a spatial reference system, and click on OK:

That’s it; now you can start adding tables to your SQLite file as you would any other destination dataset in FME!

As far as I know, Safe will not be distributing the SQLite provider directly with FME 2009 (it’s still in beta) primarily because the provider is not officially being released for FDO 3.3, and partially because the provider is still under heavy development. Fear not, though. I am building this provider against the 3.3 branch as often as necessary, and will post binaries as I do.

The relative ease with which this format was supported by FME can be attributed to Safe’s foresight in exposing FDO directly, rather than just using it behind-the-scenes in their SDF3 writer. They also allow FME to act as an FDO provider, which enables users of products that use FDO for their data layer (such as AutoCAD Map 3D) to access the full range of formats that FME supports.

-J

, ,

1 Comment

Best practice: write amusing commit messages

OK, I’m not sure how much of a best practice this is, but at least it keeps the folks reading your commits via RSS amused, and maybe it will promote more code review. Here are a couple recent examples from the FDO timeline:

In this submission, a fix for the patch we add to the SQL engine. One character is the difference between working code and epic fail…

This submission switches the provider to compile against SQLite 3.6.2. Apart from making universe collapse imminent, this comes with a nice performance boost of up to 2x for feature reads.

;)

-J

, ,

1 Comment

Data Warehousing Goodness with FDO Toolbox (sorta)

Ok, not real data warehousing (no star schema here) but anyone who has dealt with performance issues in MapGuide due to on-the-fly joins across heterogeneous data sources knows the value of loading read-only data sets into static SDF (or SQLite!) files for rapid display.

With release 0.50 of FDO Toolbox, Jackie has done it again by allowing users to quickly take data from both spatial (FDO) data sources, and non-spatial (OLEDB) data sources, join them together, and write out performance-optimized files. This is a huge boon for folks that need to do this and can’t afford best-of-breed proprietary tools like Safe Software’s FME.

Jackie has really impressed me with the rapid development of this tool as well as his focus on providing value in three distinct areas. First, FDO Toolbox has a great GUI for FDO data transfer and administration. Second, the command line capabilities allow you to set up scheduled translations to keep your SDF files in sync with your corporate data stores. Finally, FDO Toolbox has a minimal profile and can easily be used by install scripts that need to load data, register FDO providers, and other tasks during an automated application installation.

What’s next on the horizon? Jackie’s recent post on an FDO plug-in for SharpMap provides a hint… spatial data inspection coming soon to FDO Toolbox! Now if there was only a way of plugging FDO Toolbox into MapGuide Maestro to transform data and either create packages or load data directly into MapGuide. ;)

-J

, ,

1 Comment