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

Related posts

4 Responses to “pyFDO is in the House - Yeah Baby!”

  1. 1Sean Gillies on Mar 14, 2007 at 8:58 am:

    Jason,

    FDO is intriguing, but thanks to SWIG, the Python API is a clunker.

    >>> oClasses.FindItem(”SewerPipe”)

    is better done in Python like

    >>> oClasses["SewerPipe"]

    using Python’s mapping protocol. Similarly,

    >>> schema = FdoFeatureSchema.Create(sSchemaName, sSchemaName)

    should be

    >>> schema = FdoFeatureSchema(sSchemaName, sSchemaName)

  2. 2Jason Birch on Mar 14, 2007 at 9:27 am:

    Thanks Sean,

    Guess it takes a Python user to see that. I’d be confused not having explicit methods, but I guess what you’re suggesting is an implied default method for these objects based on the context?

    Does SWIG make that kind of thing impossible, or just difficult?

    I’ll be posting more on an FDO app later today.

  3. 3Sean Gillies on Mar 14, 2007 at 4:10 pm:

    Jason, Python convention is that Foo() returns an instance of class Foo. Users expect it. I’m pretty sure that this is still automatic with SWIG if you enable shadow classes.

    Different topic … I followed your link to the FDO PSC page. It names 3 Autodesk people, and two contractors to Autodesk. Indulge me in a bit of devil’s advocacy: how is that an independent PSC?

  4. 4Jason Birch on Mar 14, 2007 at 6:33 pm:

    Hi Sean,

    Devil’s advocacy is a such an odd position for you :)

    While Frank does contract to Autodesk, I don’t think that most people think of him as an Autodesk consultant. He’s got a pretty good reputation for making good technical choices independant of his commercial relationships.

    Mateusz is not, to my knowledge, consulting to Autodesk. For the PostGIS provider, he is being jointly funded by the City of Nanaimo and Refractions Research. Unless there’s a side deal I’m unaware of :)

    In the next while, the PSC should expand by two additional members. One of them will almost certainly be Haris Kurtagic, who is also independant. It’s quite possible that he has provided consulting services to Autodesk in the past though.

    It’s hard to deal with this issue at this point in the project’s life. The majority of the active users have pre-existing relationships with Autodesk (either as consultants, employees, or clients). For instance, I think of myself as independant (I know I’ve caused some pain for Autodesk with some of my comments) but there are probably some in our community that see me as a corporate lackey.

    I believe that in this case independance will have to be assesed by whether the individual members have enough personal integrity to guide the projects in the best interest of the community. Only time will be able to provide a true measurement of this.

    The community is small enough right now, that filling the last PSC slot is a difficult question. Are you interested in joining the FDO community and helping to guide the project? I don’t think that anyone would question your indepedance :)

    Jason