Thanks for adding the comment "I think we should fix this and use select extent()... in 5.2. Returning an infinite BoundingBox in GetCapabilities is just wrong. If anyone finds their GetCapabilities too slow they can always use ows_extent metadata to force the extent value and avoid the full table scan. Any objections from the mappostgis.c maintainers?" to the ticket.
I am totally agreeing with that. As a note, any decent PostGIS DB admin would have proper indices set up on their geometries and with that the extent scan is inexpensive. Eg. my cadastral DB of Enschede has approx 60.000 quite complex (multi)polygons and returns the aggregate extent in 160ms, even when having to transform to 4326. As an addition you could mention that the fall-back of going to an infinite BBOX can be very quickly changed to a more sensible falling back on the world extent, which for Latlon is simply -180 -90 180 90, and in any other SRS should be easy to calculate also (although not making much sense in some projections) Barend On 26-10-2007 15:38, "Daniel Morissette" <[EMAIL PROTECTED]> wrote: > Barend Köbben wrote: >> >>> I'd suggest that you file a ticket about this. >> Can you point me to the place where I can do such a thing...? >> > > http://trac.osgeo.org/mapserver/ > >>> I am not sure how easy >>> that will be to fix, since we'll need a way to tell the capabilities >>> generation code that the extent returned by Postgis is not meaningful. >> My suggestion is that the error is in the way you ask the data/extent from >> PostGIS. PostGIS in it's own right is perfectly capable of providing a >> correct extent : SELECT extent(the_geom) FROM test, if you need the >> LatlonBBOX: SELECT transform( extent(the_geom),4326) FROM test. How is >> MapServer requesting the bbox at the moment...? >> > > There is a GetExtents() method on all data providers in MapServer and > the postgis driver seems to have a very poor implementation that just > returns infinite extents to avoid having to do a full table scan which > could be very expensive in some cases. > > FYI this ticket discusses the issue and why "select extent() ..." was > not used before: > http://trac.osgeo.org/mapserver/ticket/1851 > > Daniel
