Archive for category Formats

FDO’s SpatiaLite Support Goes Native

Posted by Jason Birch in FDO, Formats on August 30, 2010

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

Validating against the OGC KML Schema in jEdit

Posted by Jason Birch in Formats, KML on January 25, 2009

The Google Earth Outreach team has a good little tutorial on validating KML as you type in jEdit.  Unfortunately, it’s a little bit out-of-date, so here are some pointers for validating against the newer OGC 2.2 schema, using the current version of jEdit.

Follow the video instructions above for setting up jEdit, with the following exception: when you go to dock Sidekick, you click on Sidekick instead of Structure Browser and then, in order to start parsing the document, you need to select XML mode:

image

Once you have loaded your KML file, replace the root kml entity with the following instead of the older Google schemas, and you will be able to validate against the OGC’s KML and partial Atom schemas as you work:

<kml 
  xmlns="http://www.opengis.net/kml/2.2" 
  xmlns:kml="http://www.opengis.net/kml/2.2" 
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    http://www.opengis.net/kml/2.2 http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd
    http://www.w3.org/2005/Atom http://schemas.opengis.net/kml/2.2.0/atom-author-link.xsd"
>

One odd thing that I noticed in validating my KML.  When I placed the <name> entity anywhere other than right after its parent entity (such as Document or Placemark) the parser complained that it was not valid.  I don’t know if not having the <name> as the first entity is truly invalid, or if this is just a little quirk of the schema or the parser.  The Galdos KML Validator throws the same error.

The main reason I went through setting this up is that I decided that I had to, in good conscience, ignore the part of the OGC KML written standard that constrains Atom relation types to "related".  Not specifying the correct type of relationship means that I am contributing to the downfall of society, or at least to a less meaningful GeoWeb.  See my previous post and some follow-up at Sean Gillies’ blog for more on this.  Using jEdit allows me to ensure that my documents validate against the schema, which gives me at least some level of comfort when ignoring the online validator.

-J

, , ,

1 Comment

KML Spec Bizarro?

Posted by Jason Birch in Formats, Google Earth on January 20, 2009

I’m working on some new KML resources and, just as I try to do for my HTML, I want to at least attempt to get it to validate against an official specification.  For KML, this means the OGC KML specification.

These resources will be single-feature, and will each be related to exactly one HTML representation of the same feature.  Now, it seems logical to me that I would specify an atom:link with rel="alternate" inside of these KML files, either at the Document level or perhaps at the Placemark level.

Unfortunately, from section 9.1.3.5.1 of the official OGC KML specification:

The atom:link rel attribute shall be present and its value shall be related.

What the heck?  I’m not an XML guy by any means, but I think this means that the best I can do is specify a "I think I met that guy in a bar a couple years ago" kind of relationship, when what I really want is something more like "hey, that’s me in a dress shirt."

Now, if I’m right, the question is:  do I exclude the atom:link element from my KML, do I include the element and settle for a generic relationship, or do I intentionally break compliance with the OGC specification.  Tough choice.

-J

, , ,

1 Comment

SQLite Spatial Files in FME 2009 through the Magic of FDO

Posted by Jason Birch in FDO, FME, Formats, Open Source, Tutorial on December 2, 2008

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

FDO for Informix

Posted by Jason Birch in FDO, Formats, Open Source on August 5, 2008

Boy, the folks at SL-King are on a roll. This hasn’t been announced officially yet, but the SL-King website, the Autodesk website and an FDO RFC (draft) all point to a new open source FDO provider for IBM’s Informix Dynamic Server.

The closest I’ve got to Informix is seeing it in an ESRI employee’s custom command prompt (“Informix Rules>” or something like that) at the 2001 UC, but I’m sure that this is great news for corporations that have data stored via the Spatial DataBlade. FDO increases transparency for Informix data, allowing simple web-based publishing with MapGuide Open Source, and updates and map production using desktop applications such as Autodesk Map 3D.

-J

,

2 Comments