Barend Köbben wrote:
We noticed that error also, and indeed setting the ows_extent on the layers
works. Note however that basically Mapserver is making a strange move: If it
cannot get the extent automatically out of one of its layers LAYER , it DOES
set an extent on the parent layer's BBOX (what I'd call the service extent),
and so apparently CAN extract the BBOX automatically.
The service extent is simply using the mapfile's EXTENT values. It is
not derived automatically from the data layers.
However, on the LAYER
it does not do that and instead sets an erroneaus BBOX of inifinite extent.
You're right that this is not very consistent.
Now I wonder if the OGC WMS spec states anywhere that any given layer
extent must be a subset of the overall service extent. i.e. is it
acceptable in WMS terms for a layer at the second level or deeper in the
layer hierarchy of the capabilities to advertise an extent that is
larger than the extent of its parent layer(s)?
In theory I agree that it would be desirable to have all layers fit
within the extent of their parent(s), but in practice this may be hard
to enforce, especially when dealing with BoundingBox elements in
multiple SRS where the projected/rotated BBOX corners will hardly ever
fit within the parent layer extent.
[...]
In my opinion this is a genuine bug, its houdl either set the correct extent
on the layer or leave it out altogether, so the client can fall back on the
'service' extent...
The WMS 1.1.1 spec states that LatLonBoundingBox and BoundingBox are
inherited from parent layers if they are not explicitly set for a given
Layer, so you're right, it would be best to omit them in the postgis
layer in this case unless ows_extent is explicitly specified for the layer.
I'd suggest that you file a ticket about this. 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.
Daniel
--
Daniel Morissette
http://www.mapgears.com/
