Opened 21 years ago

Closed 17 years ago

#287 closed defect (wontfix)

msPOSTGISLayerGetExtent returns infinite extents

Reported by: pspencer@… Owned by: refractions
Priority: high Milestone:
Component: PostGIS Interface Version: 4.0
Severity: normal Keywords:
Cc: wbronsema@…

Description (last modified by hobu)

msPOSTGISLayerGetExtent function returns infinite extents.  This function is
used by the WMS interface and we are also adding the ability to get extents on
layer objects through php_mapscript.  The comments in the code suggest that this
function is not called (it is through the WMS interface) and "can't" be called
from mapscript (isn't or can't?).

Can this be fixed to return real extents?

Change History (5)

comment:1 by dmorissette, 21 years ago

Copying the main parts of an email discussion about this:

David Blasby wrote:
> I did have an implementation that did the "select extent(geom) from <sub 
> select>" trick.  Unfortunately, I couldnt find a way to actually call 
> the function, so I removed it.
> 
> I also experimented with using the index to determine the extents of a 
> table.  It is possible, but its not all that easy - it would be better 
> to use the  new index-selecting-Histogram.  Also, it doesnt extend 
> nicely to cases where there are sub-selects or selects with a WHERE 
> clause. 
> 
> Paul Ramsey wrote:
> 
>> Adding an extent function is pretty easy, just wrap a function around 
>> "select extent(geom) from thetable".
>> The trouble is that the call is *costly*. It has to sequence scan the 
>> entire table to figure out the aggregate extent of the table.  Shape 
>> files have it easy, because the file extent is writ into the top of 
>> the file. As long as the function is not going to be called 
>> frequently, and the return speeds aren't an issues (yeah right ;) then 
>> it is easy to do.
>>
>> PS - As an aside, I suppose if we had our own RTree thing we could 
>> pretty easily maintain a "master extent" at the top level of the 
>> index. I wonder if there would be some way to get into the guts of the 
>> associated index to figure out table extent - it should be derivable 
>> from the top of the tree, no?
>>
>> P.

comment:2 by dmorissette, 21 years ago

Daniel Morissette wrote:
> 
> Paul Ramsey wrote:
> >
> > Hm. So it looks like DM wants to expose that function now, both through
> > WMS and via mapscript. DM guys: is performance an issue? Because there
> > is not a pretty way to expose it and be performant in the short term.
> >
> 
> Of course performance is always an issue, but completeness of the
> software is even more important.  The getExtent call has been used by
> the WMS GetCapabilities for quite a while already, and I'm surprised
> that nobody ever complained that their WMS capabilities had invalid
> extents for PostGIS layers.
> 
> I think that the order of priorities would be:
> 
> 1- Implement something that works, even if it's slow, at least so that
> things like WMS capabilities will produce the correct result.
> 
> 2- Performance can be an issue for applications using getExtents in
> MapScript, or for WMS servers with many PostGIS layers in them, so the
> function would have to be optimized for performance eventually.
> 

comment:3 by dmorissette, 21 years ago

Daniel Morissette wrote:
> 
> Paul Ramsey wrote:
> >
> > Probably they have been doing what I have been doing, which is using the
> > wms_* metatdata entries to override what the function was returning.
> > Similar extent-returning issues exist for some raster layers, I believe.
> >
> 
> You're correct, extents are still an issue for raster layers.  And the
> GetExtent() call can also be very slow for some OGR file formats, mostly
> the ASCII ones.
> 
> >
> > Would the presence of wms_* metadata override the call to the function?
> > That way one could speed up the capabilities by providing the extents
> > explicitly.
> >
> 
> Yup, the presence of wms_extent metadata if it's set overrides the call
> in the WMS capabilities case.
> 
> In our specific case we were looking at using getExtent() on PostGIS
> layers from MapScript, I guess we'll have to cache the result somewhere
> or ask the developer to set the metadata (and read it in MapScript)
> until the function is optimized for performance.
> 

comment:4 by hobu, 17 years ago

Description: modified (diff)

Any status on this one? Has this issue been resolved long ago?

comment:5 by dmorissette, 17 years ago

Resolution: wontfix
Status: newclosed

Closing as wontfix due to lack of activity. If this is still a current issue for anyone then please reopen or create a new ticket with more details.

Note: See TracTickets for help on using tickets.