CRS in the DescribeCoverage response sent by a WCS 1.0.0 server is WGS84(DD), instead of EPSG

[nsavard]

This is a problem related to the WCS 1.0.0 OGC Test suites.

The test is wcs1-0-0/basic_service_elements/general_http_request_rules/6 found at  http://cite.opengeospatial.org/tsOGC/interface/ViewTestSource?testid=wcs1-0-0/basic_service_elements/general_http_request_rules/6&ts=0033&sesstype=OGC

The test engine sends a DescribeCoverage? request which returns the description of the first coverage. The envelope is given in both WGS84(DD) and EPSG:26915 CRS (see below). Then a second request is sent to the server by using the first CRS appearing in the DescribeCoverage? response. This CRS is captured by the test script engine. This makes MapServer returns the following exception:

<?xml version='1.0' encoding="ISO-8859-1" ?> <ServiceExceptionReport? version="1.2.0" xmlns=" http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ogc  http://schemas.opengis.net//wms/1.1.1/OGC-exception.xsd"> <ServiceException? code="InvalidParameterValue?" locator="srs">msWCSGetCoverage(): WMS server error. Unsupported SRS namespace (only EPSG currently supported). </ServiceException> </ServiceExceptionReport>

MapServer only supports EPSG for now. To overcome this issue MapServer should return the coverage envelope with EPSG code first. What do you think?

[nsavard]

I forgot to include an example of the DescribeCoverage? response:

DescribeCoverage? response:

<domainSet> <spatialDomain> <gml:Envelope srsName="WGS84(DD)"> <gml:pos>-97.7071758865421 41.0324719184183</gml:pos> <gml:pos>-80.6778361148771 49.6650665681236</gml:pos> </gml:Envelope> <gml:Envelope srsName="EPSG:26915"> <gml:pos>159707 4597895</gml:pos> <gml:pos>1400207 5501395</gml:pos>

...

[nsavard]

Replying to nsavard:

This is a problem related to the WCS 1.0.0 OGC Test suites. The test is wcs1-0-0/basic_service_elements/general_http_request_rules/6 found at  http://cite.opengeospatial.org/tsOGC/interface/ViewTestSource?testid=wcs1-0-0/basic_service_elements/general_http_request_rules/6&ts=0033&sesstype=OGC

Replied by Tom:

For some reason, I can't get to this URL (my OGC account u/p doesn't work either).

The test engine sends a DescribeCoverage? request which returns the description of the first coverage. The envelope is given in both WGS84(DD) and EPSG:26915 CRS (see below). Then a second request is sent to the server by using the first CRS appearing in the DescribeCoverage? response. This CRS is captured by the test script engine. This makes MapServer returns the following exception: <?xml version='1.0' encoding="ISO-8859-1" ?> <ServiceExceptionReport? version="1.2.0" xmlns=" http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ogc  http://schemas.opengis.net//wms/1.1.1/OGC-exception.xsd"> <ServiceException? code="InvalidParameterValue?" locator="srs">msWCSGetCoverage(): WMS server error. Unsupported SRS namespace (only EPSG currently supported). </ServiceException> </ServiceExceptionReport> MapServer only supports EPSG for now. To overcome this issue MapServer should return the coverage envelope with EPSG code first. What do you think?

Replied by Tom: cc'ing Steve and Frank.

I get the same behaviour when I run (against trunk):

 http://devgeo.cciw.ca/cgi-bin/mapserv/ecows?service=WCS&version=1.0.0&re quest=DescribeCoverage?

WGS84(DD) is hardcoded in mapwcs.c for latLongEnvelope. I think the attached patch (for comment) would fix this issue. Unless there's an explicit reason why WGS84(DD) was used in the implementation.

[nsavard]

Patch to fix this issue

[nsavard]

WGS84(DD) is hardcoded in mapwcs.c for latLongEnvelope. I think >the attached patch (for comment) would fix this issue. Unless >there's an explicit reason why WGS84(DD) was used in the >implementation.

Replied by Steve:

When that code was written the were a few example instance/schema documents that I used aid in my interpretation of the standard. I suspect this came from one of those so I think it's ok to apply your patch.

[nsavard]

Tom Kradilis submitted and applied the patch-- committed in r7281.

[warmerdam]

Updated msautotest/wcs results to reflect this change in trunk (r7284).

I notice the fix was made only in trunk. If we are sufficiently confident in the fix perhaps we should push it into 5.0 branch today so it will appear in 5.0.1 too.

[tomkralidis]

I've applied this to 5.0 branch in r7285

[tomkralidis]

Frank: should I make the change you made in r7284 to msautotest in branch as well (asking this as a general rule as well as specific to this ticket)?

[warmerdam]

Tom,

Yes, I believe you should. Backporting autotest changes is valuable when it ensures that the stable tests will continue to pass. It is less valuable when it would just add a new test.

IMHO

[tomkralidis]

Thanks for the recommendation. Changes made in r7287