SRS handling questions
Silke.Reimer at intevation.de
Thu Mar 25 11:29:16 CET 2004
On Thu, Mar 25, 2004 at 09:41:49AM +0100, Martin Schulze wrote:
> Silke Reimer wrote:
> > > Yes. They should. However, if they aren't, and the list of SRS is
> > > larger, it's likely to cause problems since there won't be a bounding
> > > box associated to an SRS. Hence, I tend to ignore the <SRS> tags
> > > except for the root layer, and generate the list of SRS for child
> > > layers from their bounding box elements. Except if you disagree.
> > Sorry to reopen the discussion again, but I had the idea that the
> > perhaps the SRS attribute in the BoundingBox element is not meant to
> > define the existence of a new SRS but does only assign the
> > BoundingBox to a special SRS. Perhaps a SRS should even not be
> > appear in an BoundingBox element if it is not part of the SRS
> *shrug* I don't remember the specs drawing any connection between the
> <SRS> element and the <BoundingBox> elements.
> > element. If there is no BoundingBox for in SRS the BoundingBox would
> > just be the LatLonBoundingBox projected to the SRS.
> There's nothing like this mentioned in the specs, as far as I can see.
> > Does the spec write something about this relation? At least this
> > would make sense in my opinion. As a follow-up the list of SRSs
> > should not be derived from the bounding box elements of a layer, but
> > only from the SRS element.
> As far as I have understood the use of Bounding Boxes and SRS, each
> layer is available in multiple SRS. The map server will render the
> requested layer clipping using the specified projection. From the
> clients point of view, the layer is available in a number of SRSs,
> EPSG:4326 being the one used for the LatLonBoundingBox clipping, and
> others (or the same) for the other BoundingBox clippings.
> I'll quote the specs a bit:
> [..] OGC Web Services are not required to support all possible
> SRSes, but shall advertise in their Capabilities XML those
> projections which they do offer and shall accept requests for all
> advertised projections.
> If a request contains an SRS not offered by a particular server,
> the server shall throw a Service Exception (code="InvalidSRS").
> [..] Each BoundingBox states the bounding rectangle of the map data
> in a particular spatial reference system; the attribute SRS
> indicates which SRS applies.
> [..] A Layer may have multiple Boundingbox elements, but each one
> shall state a different SRS.
> A Layer inherits any Bounding Box values defined by its parents.
> [..] A single Layer element shall not contain more than one
> BoundingBox for the same SRS.
> The server should provide BoundingBox information for a tleast the
> native SRS of the Layer.
> My interpretation is that a layer is available for the SRS it
> announces in the <BoundingBox> elements (and llbbox) with the
> respective minimum enclosing rectangle as specified.
In my opinion the announcement of SRS is done in the SRS-element not
in the BoundingBox-element (see above).
> When you request a map to be rendered by the map server, you'll have
> to supply the SRS you want to receive it rendered in. Using an SRS
> which wasn't announced, will most probably result in an exception
> instead of an image.
> Hence, I believe that the SRS denoted in the <BoundingBox> elements
> build the authoritative list of SRSes the map can be rendered in.
I don't understand how you come to this conclusion
[..] A server which has the ability to transform data to different
SRSes may choose not to provide an explicit BoundingBox for every
possible SRS available for each Layer.
The server should provide BoundingBox information for a tleast the
native SRS of the Layer.
Hence you can announce SRSes without giving a BoundingBox for a
specific SRS. I interpretate this as: The announcement is done in
the SRS element while you *can* provide a BoundingBox.
I agree with you that the spec doesn't prevent you to provide a
BoundingBox for a SRS which is not in the SRS-element but my
interpretation of the spec is that this should not be the case.
Intevation GmbH http://intevation.de/
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde geschreddert...
Dateiname : nicht verfügbar
Dateityp : application/pgp-signature
Dateigröße : 189 bytes
Beschreibung: nicht verfügbar
URL : http://intevation.de/pipermail/thuban-devel/attachments/20040325/9fc1dcd4/attachment-0001.bin
More information about the Thuban-devel