[fdo-internals] King.Oracle & PostGIS provider failed with Empty tables

[Traian Stanev]

In my case it was because the OGR provider doesn't support SpatialExtents, and the table being added as layer in Map3D had a null geometry in one feature. Map3D attempts to compute the extents of the layer by itself, in case the provider doesn't support SpatialExtents, and was throwing that same error when it encountered the null geometry (and tried to dereference the pointer).

Another problem that may generate a similar error is if from your DescribeSchema you return feature classes with NULL ClassCapabilities. This is the fix I did for the OGR (and SQLite) provider to avoid that particular problem:

    FdoPtr<FdoClassCapabilities> caps = FdoClassCapabilities::Create(*m_fc);
    caps->SetSupportsLocking(false);
    caps->SetSupportsLongTransactions(false);
    caps->SetSupportsWrite(true);
    m_fc->SetCapabilities(caps);

If the feature classes you return from DescribeSchema happen to not have an initialized capabilities object, you will also get that error.


Traian


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Bruno Scott
Sent: Wednesday, May 27, 2009 4:14 AM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] King.Oracle & PostGIS provider failed with Empty tables



I've just made some testing to check the spatialextents,
It does even not call the spatialextents function.
I only see the initial select that return 0 records

Bruno
-- 
View this message in context: http://n2.nabble.com/King.Oracle---PostGIS-provider-failed-with-Empty-tables-tp2973492p2979703.html
Sent from the FDO Internals mailing list archive at Nabble.com.

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals