[fdo-internals] Question about FDOOGRProvider
gabrimonfa at gmail.com
Fri Mar 28 02:45:45 PDT 2014
When you want to preview a Feature Class or Layer Definition, we need to
> 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.
> 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
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
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
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
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;
180 FdoPtr<FdoFgfGeometryFactory> gf =
181 FdoPtr<FdoIEnvelope> env = gf->CreateEnvelopeXY( xmin,
> ymin, xmax, ymax );
182 FdoPtr<FdoIGeometry> geom = gf->CreateGeometry(env);
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fdo-internals