SELECT
   ST_AsText(
      ST_GeomFromWKB(
         decode('0101000000e5d022dbf93e2e40dbf97e6abc743540', 'hex'),
         4326))

I often need to do the same directly in C++ code – parse hex encoded binary stream to raw stream of bytes. Here is simple hex decoder I use:

#include <sstream>
#include <string>
#include <vector>
typedef std::vector<unsigned char> ewkb_t;

// bytes [out] - buffer for binary output
void hex_to_bytes(std::string const& hexstr, ewkb_t& bytes)
{
    bytes.clear();
    for(std::string::size_type i = 0; i < hexstr.size() / 2; ++i)
    {
        std::istringstream iss(hexstr.substr(i * 2, 2));
        unsigned int n;
        iss >> std::hex >> n;
        bytes.push_back(static_cast<unsigned char>(n));
    }
}

For example, I use it to build FDO geometry objects using another utility CreateGeometryFromExtendedWkb defined in FDO provider for PostGIS:

// POINT (1.234 5.678)
std::string ewkbhex("01010000005839B4C876BEF33F83C0CAA145B61640");
ewkb_t ewkb;
hex_to_bytes(ewkbhex, ewkb);
if (!ewkb.empty())
{
   FdoPtr<fdoigeometry> g = CreateGeometryFromExtendedWkb(ewkb);
   // ... use geometry
}

Recently, I’ve failed my duties in the provider development, so motivated by the load of Bruno’s work I found some gaps in time to submit a few fixes too :-)

For all interested in development of the PostGIS provider for FDO, here is detailed list of the recent updates (links point to tickets in FDO Trac database):

• #94 Generate extent for features assigned to default spatial context
• #106 PostGIS provider cannot delete a feature class
• #171 Fdo Postgis Autogenated identity property is mandatory
• #178 PostGIS : Can’t insert in a non-feature class
• #232 Fdo Postgis null and not null filter does not work
• #233 Fdo Postgis in and not in filter does not work
• #234 Fdo Postgis currently does not support anything but lowercase identifiers
• #235 Fdo Postgis Exception with insert
• #236 Fdo Postgis does not support non spatial classes
• #241 Implement Support for SelectAggregates, SpatialExtents and Count
• #310 PostGIS provider : change class naming convention without ~
• #311 PostGIS provider : mismatch between FdoGeometricTypes and FdoGeometryType
• #312 PostGIS provider : remove boost_date_time dll dependency
• #313 PostGIS provider : can’t filter,insert or update date/datetime
• #314 PostGIS provider : check-out/check-in crashes Autodesk Map
• #324 PostGIS provider : Insert and update geometry failed when a table has a srid
• #328 PostGIS FdoIInsert::Execute always returns NULL
• #329 PostGIS FdoISQLCommand::GetSQLStatement always returns NULL
• #337 PostGIS defect : insert,update more than one column failed on dates
• #338 PostGIS defect : insert with srid -1 failed
• #339 PostGIS defect : Srid is not set properly when creating a FeatureClass
• #341 PostGIS defect : SelectAggregate does not support DISTINCT

All the fixes listed above will be included in next version 3.4.0 of Feature Data Objects.

From another area of the FDO development, check Jason’s post about the brand new SQLite for both FDO and OGR

The Python bindings are generated with SWIG. As Greg Boone reported on the fdo-internals, currently Python bindings can be generated and used on Windows only. Linux support will be available soon. Also, it has been only tested with Python .2.4 so far and 2.5 line is not supported yet.

The Python scripting support for the Feature Data Objects is still under development but I’m sure it’s a great news for the large community of Python users in geospatial field. This is a next step to attract potential FDO users.

There is more about pyFDO subject on Jason Birch’s blog: pyFDO is in the House – Yeah Baby!

I strongly support Jason’s idea because with SoC, Google is giving a great opportunity for Open Source projects to boost their development and gain new features or prototypes ready for next steps toward usability.

Jason posted a nice proposal of features for SoC. Here are my favorites:

• 64-bit platform support

  FDO is not officially nor unofficially supported and as latest reports indicate some substantial work is required.

• Command line tools

  I’m a big fun of GDAL and OGR command line utilities. I think it’s a great idea about having similar tools for FDO: fdoinfo, fdo2fdo, etc. Having ogr2ogr and fdo2fdo, a user would be able to pipe vector data in any direction :-). Another utility I’m thinking about is fdoinfo, FDO equivalent of ogrinfo from the OGR package.

• Mac OS X support

  Yes, FDO is not supported on this platform. The SoC 2007 could be a nice opportunity to change this situation.

If you have any idea of new features you’d like to see in the Feature Data Objects, please propose them on the fdo-internals list or just put here as a comment and I’ll forward them to the FDO team.

I’m wondering if there is any motion in OSGeo to become a mentoring organization for Google SoC and if such idea is reasonable in any way.

The first important thing to remember is that FDO uses its own hierarchy of exceptions with FdoException class as a base. The FdoException does not use or depend on standard C++ exceptions with std::exception base class and it has to be handled in FDO specific way – catch by pointer and released:

try {
  // ...
}
catch (FdoException* ex) {
  // Handling procedure (see below)
  ex->Release();
}

Second important thing and worth to remember is that FDO exceptions can nested. A source exception thrown in one place can be wrapped with new exception in catch clause on some level and re-thrown away. The new exception with can be caught on an upper level, wrapped and re-thrown again. Every such repetition of this wrap and re-throw operation nests source exception, together with associated message, in newly created. Here is a simple example presenting mechanism composing nested exceptions:

try {
  try {
    try {
      throw FdoException::Create(L"First exception");
    }
    catch (FdoException* ex) {
      throw FdoException::Create(L"Second caused by first", ex);
    }
  }
  catch (FdoException* ex) {
      throw FdoException::Create(L"Third caused by second", ex);
  }
}
catch (FdoException* ex) {
  // Handling procedure (see below)
  ex->Release();
}

Finally, it’s time to process queue of nested exceptions and output associated messages to a user. Below, catch clause completing the example above is presented. The output formatting is based on standard C++ streams:

#include <sstream>
#include <string>
#include <iomanip try {
  // throwing and re-throwing exceptions
}
catch (FdoException* ex) {

  // message offset + asterix characters
  std::streamsize offset = 5;

  // used to compose error message
  std::wostringstream msg;
  msg << L"\n*** FDO FAILURE ***\n";
  msg << std::setw(++offset)
        << L"*** "
        << ex->GetExceptionMessage()
        < < std::endl;

  FdoPtr<FdoException> cause(ex->GetCause());
  while(NULL != cause)
  {
    msg < < std::setw(++offset)
          << L"*** "
          << cause->GetExceptionMessage()
          < < std::endl;

    // get next exception from the queue
    cause = cause->GetCause();
  }
  ex->Release();

  std::wcout < < msg << std::endl;
}

The output message will look as follows:

*** FDO FAILURE ***
  *** Third caused by second
   *** Second caused by first
    *** First exception

The first, root, exception is processed as last and the last re-thrown exception is processed as first. As it’s observable, FDO nested exceptions are recorder in LIFO queue order.

I hope this short explanation will be helpful to understand FDO exceptions. By the way, if you have any questions or proposals of articles about using Feature Data Objects with C++, please drop me a note about it. I’ll do my best to give some writings and examples here, so anyone can read about it.

What is the Generic RDBMS framework:

The Generic RDBMS project provides FDO with access to RDBMS systems through a generic framework that allows code reuse and reduces the development time for creating new FDO providers.

I’ve been working with the Generic RDBMS and learning its internals straight from the code long weeks. It wasn’t easy due to fact it feels big and also because it’s not friendly documented for users yet. Nevertheless, I can say I’ve became familiar with internals of Generic RDBMS quite well.

Recently, I’ve started to experience some difficulties and limitations of the Generic RDBMS layer. I faced all these problems while adding support of another DBMS engine – PostgreSQL – to the Generic RDBMS layer and it’s internal components like RDBI and GDBI (the PostgreSQL is not yet supported by Generic RDBMS, so it was obvious for me I need to implement it in order to develop PostGIS provider).

Follow this link to read the turning point announcement posted by Paul on the fdo-internals mailing list, in which you can find more details about the rationale of our decision.

As a conclusion of my experiences from using Generic RDBMS, here is my personal summary of reasons why it’s important to analyse this framework in details before making a final choice (random order):

• Every DBMS engine is specific and it’s worth to consider specific solution.
• It’s not possible to develop a database abstraction layer for every kind of application.
• The Generic RDBMS makes some decisions first and they should be analysed before attempting to implement new provider to find if these decisions won’t become limitations.
• The Generic RDBMS forces a provider to require existence of FDO Meta Schema – a set of predefined tables
• Workarounds for decisions made by Generic RDBMS are mostly based on bringing and extending new level(s) of abstraction.
• The former point leads to increase of complexity of the solution.
• The FDO is complex and feels big. The Generic RDBMS framework increases this complexity.
• It’s probably easier to achieve optimal performance with very specific solution, so the Generic RDBMS might cause another limitations in this area.
• IMHO, there are too many abstraction levels in the Generic RDBMS itself (RDBI, DBI, GDBI, …)
• Creating new FDO provider by directly implementing FDO core interfaces is: easier to develop, easier to test and debug, maintainer friendly and it may be more robust.

I can confirm it’s easier because I’ve been developing on new generation of PostGIS provider for more than a week. I suppose thin implementation of FDO core interfaces will be faster because of use of as little abstraction levels as possible.

I’m not against of the idea of abstraction layers for DBMS and I’m not against the idea of the Generic RDBMS framework for FDO. Better, I like the concept. I’m a member of development team of SOCI library – a database access library for C++. It’s a simple abstraction providing common layer for SQL queries execution and fetching query results. I’d call SOCI as a pretty simple example of common denominator for various DBMS and even that we’ve experienced number of problems and limitations resulting from specific nature of various database engines. So, developing usable and extensible abstraction above yet more complex system is tricky for sure, but may be impossible too.

I know there are some users waiting for the PostGIS provider for FDO. I’d like to apologise all of you waiting for it for the significant delay. I’m sure our latest decision about the turning point will favourably influence the PostGIS provider development and make the release date closer.