<div dir="ltr"><div class="gmail_extra">Hi Jackie,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
When you want to preview a Feature Class or Layer Definition, we need to know<br>
the bounds and coordsys of the feature class so that a suitable preview Map<br>
Definition can be generated that contains the Layer Definition to your<br>
feature class.<br>
<br>
If the bounds are not correct (eg. A static spatial context bounds derived<br>
from an improperly tuned spatial index) it will be most apparent in the<br>
preview result.<br>
<br>
This is the only area in MapGuide I know of I know that one would need to<br>
know the bounds of a Feature Class.<br></blockquote><div><br></div><div>ok, </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Before you lay the blame on the OGR provider, could it be the PostGIS OGR<br>
driver is doing an inefficient job? Do you see similar performance<br>
characteristics with other OGR drivers/datasources?<br></blockquote><div><br></div><div>I think that OGR FDO Provider is not to be blamed.</div><div>Its GetExtent function passes the GetExtent to OGR so I think this is absolutely correct.</div>
<div><br></div><div>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. </div><div><br></div><div>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).</div>
<div><br></div><div>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.</div><div><br></div><div>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</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">175 double xmin = -2000000;<br></blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">176 double xmax = 2000000;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
177 double ymin = -2000000;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">178 double ymax = 2000000;</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">179 </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
180 FdoPtr<FdoFgfGeometryFactory> gf = FdoFgfGeometryFactory::GetInstance();</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
181 FdoPtr<FdoIEnvelope> env = gf->CreateEnvelopeXY( xmin, ymin, xmax, ymax );</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
182 FdoPtr<FdoIGeometry> geom = gf->CreateGeometry(env);</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
183 </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">184 mExtents = gf->GetFgf(geom);</blockquote>
<div><br></div><div><br></div><div>while function GetExtent() simply returns </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
131 return FDO_SAFE_ADDREF(mExtents.p);<br></blockquote><div><br></div><div><br></div><div>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. </div>
<div><br></div><div>So I think I have a few possible solutions</div><div><ol><li>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)</li>
<li>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.<br>Moreover there are many other data sources that uses FDO OGR provider apart from PostGIS, thus this workaround may not be acceptable</li>
</ol></div><div>Regards,</div><div><br></div><div>Gabriele Monfardini</div></div></div></div>