[WCS/WMS] make <requestResponseCRSs> tag repeat for each CRS instead of listing CRSs in one <requestResponseCRSs> tag

[nacional@…]

From John Vincent's (Intergraph) e-mail:
> You advertise CRS's in this manner:
>
>     <supportedCRSs>
>       <requestResponseCRSs>EPSG:26915 EPSG:2163 EPSG:4269
> EPSG:4326</requestResponseCRSs>
>       <nativeCRSs>EPSG:26915</nativeCRSs>
>     </supportedCRSs>
>
> which I believe should be:
>
>     <supportedCRSs>
>       <requestResponseCRSs>EPSG:26915</requestResponseCRSs>
>       <requestResponseCRSs>EPSG:2163</requestResponseCRSs>
>       <requestResponseCRSs>EPSG:4269</requestResponseCRSs>
>       <requestResponseCRSs>EPSG:4326</requestResponseCRSs>
>       <nativeCRSs>EPSG:26915</nativeCRSs>
>     </supportedCRSs>

To which Steve Lime asked for Tom Kralidis's opinion.  Tom spoke thus:
>space seperated is supported but deprecated.  I'm guessing the other
>specs follow suit.  Another reason why I can't wait until the OWS Common
>spec comes out.
>
>Suggest:
>- confirm with OGC:WCS editors that both approaches are allowed
>- if yes, confirm with OGC:WCS editors that although one element lists
>are supported, they are deprecated
>- if yes, file a MapServer bug for BOTH OGC:WCS AND OGC:WMS to update
>output of SRS lists in OGC:WMS GetCapabilities and OGC:WCS
>DescribeCoverage as one code per element

To which John Vincent replies:
>I have looked over the WCS specification and determined that it does not
>clearly define what is intended.  However, it is clear from the schema that
>the <requestResponseCRSs> element is allowed to repeat, which would serve no
>purpose if the intent was to space delimit a list of values in a single
>instance of the element.  I believe the trend of the OGC is to move away
>from lists defined by character strings which contain multiple values, and
>instead, to move toward explicity defined lists using XML constructs.  This
>also allows more rigorous testing for conformance.
>
>I've copied the WCS editor (John Evans) to see if he can provide further
>insight into this issue.

So, based on the communications above, <requestResponseCRSs> is allowed to
repeat but this doesn't really say that you shouldn't have a list within the
tag.  Moreover, the tag itself implies having multiple CRS definitions (hence,
requestResponseCRSs).  Ideally clients would support the list within the
<requestResponseCRSs> tag as well as single CRS per tag.  However, from comments
by two OGC/WCS gurus, it's clear the latter is the preferred method. So, can we
implement it?

I'll post John Evans' (WCS editor) comment when I hear from him.

-Perry

PS:  If you'd like to try Intergraph's online WCS client, the URL is:
http://ogc.intergraph.com/wcs/client/

[tomkralidis]

Note that this should also be put forth in mapwms.c

[nacional@…]

Does this also apply to WFS then? 

[tomkralidis]

Nope, OGC:WFS only allows one SRS per feature type, which don't have to comply
with a common global SRS list, as OGC:WFS (by virtue of spec) doesn't have one.

[dmorissette]

> Note that this should also be put forth in mapwms.c

Can you please elaborate on required changes to the WMS, perhaps in a new bug to
avoid unnecessary noise here?  (FYI mapwms.c already produces multiple <SRS>
elements for WMS 1.1.0 and up... this is when the change from space-delimited to
separate elements happened in the WMS spec.)

[sdlime]

Er, opps. Kinda forgot about this one. Fixed in 4.10 branch and CVS HEAD.

Steve