[UMN_MAPSERVER-USERS] Question re: PostGIS and MapScript
pramsey at REFRACTIONS.NET
Wed Jul 13 10:53:08 EDT 2005
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.
More information about the mapserver-dev