[fdo-internals] Question about FDOOGRProvider

[Gabriele Monfardini]

Hi Jackie,


When you want to preview a Feature Class or Layer Definition, we need to
> know
> the bounds and coordsys of the feature class so that a suitable preview Map
> Definition can be generated that contains the Layer Definition to your
> feature class.
>
> If the bounds are not correct (eg. A static spatial context bounds derived
> from an improperly tuned spatial index) it will be most apparent in the
> preview result.
>
> This is the only area in MapGuide I know of I know that one would need to
> know the bounds of a Feature Class.
>

ok,



> Before you lay the blame on the OGR provider, could it be the PostGIS OGR
> driver is doing an inefficient job? Do you see similar performance
> characteristics with other OGR drivers/datasources?
>

I think that OGR FDO Provider is not to be blamed.
Its GetExtent function passes the GetExtent to OGR so I think this is
absolutely correct.

If there is a smarter way to get an extimated extent instead of a correct
and expensive extent this should probably be a choice made inside ogr
Postgis driver.

Looking at OGR code there is no way to use ST_ExtimatedExtent, so it should
probably be added on OGR Postgis driver (i'm going to open an enhancement
ticket).

I've also made a test with PostGIS FDO Provider and
FeatureService->GetSpatialContext does not issue any SELECT ST_Extent nor
SELECT ST_ExtimatedExtent on any table.

Looking at the code
(Providers/GenericRdbms/Src/PostGis/SchemaMgr/SpatialContextReader.cpp line
173 in function ReadNext) it seems (but correct me if I'm wrong) that a
generic hardcoded extent is passed by

175         double xmin = -2000000;
>
176         double xmax = 2000000;

177         double ymin = -2000000;

178         double ymax = 2000000;

179

180         FdoPtr<FdoFgfGeometryFactory> gf =
> FdoFgfGeometryFactory::GetInstance();

181         FdoPtr<FdoIEnvelope>          env = gf->CreateEnvelopeXY( xmin,
> ymin, xmax, ymax );

182         FdoPtr<FdoIGeometry>          geom = gf->CreateGeometry(env);

183

184         mExtents = gf->GetFgf(geom);



while function GetExtent() simply returns

131    return FDO_SAFE_ADDREF(mExtents.p);
>


Note that in my case data are in Gauss Boaga so coordinates are around
(1600000 4800000) thus real extent is not within the generic one passed by.

So I think I have a few possible solutions

   1. add support for ST_ExtimatedExtent in libgdal, which seems not so
   difficult in my specific case (but it would be better to find a good
   generic solution to push upstream)
   2. patch OGR FDO Provider to provide a fake bound, but obviously this is
   an ugly workaround since current implementation seems correct and the bound
   may be useful.
   Moreover there are many other data sources that uses FDO OGR provider
   apart from PostGIS, thus this workaround may not be acceptable

Regards,

Gabriele Monfardini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/fdo-internals/attachments/20140328/12b7f89d/attachment.html>