[Qgis-user] Re: Available CRS's not shown with some WMS servers

[Goyo]

2010/8/16 Borys Jurgiel <borysiasty at aster.pl>:

> In the getcapabilities response there is a strange line:
>
> <SRS>EPSG:4230 EPSG:4258 EPSG:4326 EPSG:25828 EPSG:25829 EPSG:25830
> EPSG:25831 EPSG:23029 EPSG:23030 EPSG:23031 EPSG:32628 EPSG:32629 EPSG:32630
> EPSG:32631</SRS>
>
> Personally, I've never seen a series of SRSes put together in one line.
> Usually it looks like that:
>
> <SRS>EPSG:4230</SRS>
>
> <SRS>EPSG:4258</SRS>
>
> <SRS>EPSG:4326</SRS>
>
> ...
>
> Could somebody state if it breaks the OGC WMS specification or not? If not,
> we should adapt this format too.

It is the only way in version 1.1.0 and it is deprecated (but have to
be handled by clients) in version 1.1.1. QGis 1.4 is supposed to
support both versions as stated in the manual. From WMS 1.1.1
specification[1]:

--%<------------------------------
When a Layer is available in several Spatial Reference Systems, there
are two ways to
encode the list of SRS values. The first of these is new in this version of the
specification, the second is deprecated but still included for
backwards compatibility.

1. Optional, recommended: Multiple single-valued <SRS> elements: a list of SRS
values is represented as a sequence of <SRS> elements, each of which
contains only a
single SRS name. Example: <SRS>EPSG:1234</SRS> <SRS>EPSG:5678</SRS>.

2. Deprecated: Single list-valued <SRS> element: a list of SRS values
is represented as
a whitespace-separated list of SRS names contained within a single
<SRS> element.
Example: <SRS>EPSG:1234 EPSG:5678</SRS>.

WMS 1.1.1 Clients shall be prepared to handle either encoding.

NOTE: Change from version 1.1.0: Only the second, deprecated encoding
was previously defined.
--%<------------------------------

I'm pretty sure QGis has supported this in the past.

[1]http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf