[UMN_MAPSERVER-USERS] Question re: PostGIS and MapScript getExtent() function

[Paul Ramsey]

On 13-Jul-05, at 7:37 AM, Daniel Morissette wrote:

> Paul Ramsey wrote:
>
>> (a) The head rectangle of the index is not the real extents, it is  
>> an  approximation, particularly after some deletes. It is,  
>> however, at  least always a superset of the real extents.
>> (b) Not every table has a spatial index.
>> (c) Every version of PostgreSQL has a different API into the  
>> index  (OK, that's not a reason that's just laziness:)
>> (d) Even if we added that function, the mass of PostGIS users  
>> would  not have the new function for a long time, so the  
>> underlying problem  would remain for Mapserver.
>>
>
> Thanks for the answer, as you could tell I know nothing about the  
> postgis implementation so I was just wondering what was possible.
>
> This being said, I remember working with Oracle Spatial a few years  
> ago and being very disapointed that it didn't provide an easy way  
> to get accurate extents. I personally think this is a serious  
> limitation that any serious spatial database should fix...  
> hopefully postgis will take the lead and be the first spatial  
> database to do this right.

I dunno, "select extent(geocolumn) from geotable" is pretty easy, and  
completely accurate. Oh, you mean accurate *and* fast :)  Fernando's  
point is also well taken... once the DATA statement becomes a complex  
SQL query, all bets are off. I had completely forgotten about that,  
and it leads me back to our final solution: just punting.

>> Probably we will end up adding this stuff, but the real issue is  
>> that  not all datasets can return fast extents, and the use cases  
>> for  extents can be broken into "fast and approximate" and "slow  
>> and  accurate" so there really should be a couple of methods, not  
>> just the  one.
>
> There is already the option of setting the extent manually in the  
> layer if your underlying datasource doesn't support returning  
> extents in an accurate or efficient way. Isn't that enough?
>
> I'm not yet convinced that using Fast in the WMS case and Slow 
> +Accurate in all other cases will be an aceptable solution, at  
> least not for all WMS users. I guess I'd need to think about the  
> problem and our options some more.

Not only is it enough, it is what I do most of the time, so that my  
WMS capabilities have nice extents in them, instead of -Inf to Inf.   
How about the ultimate punt: we error out when called and tell people  
to set their extents explicitly.

Fernando's point of complex SQL has sent me back to the bench to  
reconsider this (a whole 'nother class of cases, yay!). Think about  
how use use extents, in what contexts.  We were personally surprised  
originally at how few calls to that method there were.

Paul