Bbox in GetCapabilies for PostGIS layer

[Barend K ö bben]

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" <dmorissette at MAPGEARS.COM> 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