| Version 92 (modified by , 14 years ago) ( diff ) |
|---|
Status report on MapServer OGC CITE Compliance
Fixing issues plan
| Specification | Version | Ticket | Description | Note |
| WMS | 1.1.1 | 1534 | When CONNECTION missing MS not using "wms_onlineresource" | |
| 1.1.1 | 2028 | Using non-EPSG-format projections | Asked Daniel if we should reassing | |
| 1.3.0 | 2979 | WMS 1.3.0 should noy allow the SRS parameter but only the CRS parameter | Assefa fixed it. | |
| WFS | 1.0.0 | 2432 | namespace needs to be strip off of a feature name when serving a WFS GetFeature request | Fixed by Assefa, to verify |
| 1.0.0 | 2445 | Add a mechanism to support gml:_geometryProperty for a WFS 1.0.0 server | ||
| 1.0.0 | 2606 | Add multipoint, multipolygon, multilinestring geometries support to define an area in a spatial filter, when a GetFeature request is sent to a WFS 1.0.0 server | Could be harder | |
| WFS | 1.1.0 | 3076 | DefaultSRS string value is stripped off from the end. | Fixed by Assefa, Assefa to verify |
| 1.1.0 | 2445 | Add a mechanism to support gml:_geometryProperty for a WFS 1.0.0 server | ||
| 1.1.0 | 2899 | axis order must be in order lat long for 4326 for 1.1.0 | Fixed by Assefa. | |
| 1.1.0 | The main issue is that the layer contains multiple geometry types on the same layer | Could be really harder. Daniel submitted an idea to solve this. | ||
| WCS | 1.0.0 | 3083 | When a GetCoverage request is sent to a WCS 1.0.0 server with a bbox that is the same as the defined bbox (describecoverage), the server must NOT return an exception | Steve fixed it. |
| 1.1.0 | 3105 | GetCapabilities request does not support the sections | Tom k. is working on this but there | |
| 1.1.0 | 3086 | wcs 1.1.1 GetCapabilities response does not contain the schemaLocation | ||
| SOS | 1.0.0 | 2646 | XML of the response to a GetObservation request sent to SOS 1.0.0 server doesn't validate against the schema | Tom is working on this one. |
| 1.0.0 | 2559 | A GetObservation request with an invalid featureOfInterest value sent to a SOS 1.0.0 server must return an exception | Tom is working on this one. | |
| 1.0.0 | 2512 | A GetCapabilities issue to a SOS 1.0.0 server with no service parameter must trigger an OWS 1.0.0 exception | Daniel is working on this one. Hard. See #2531 | |
| 1.0.0 | 2513 | A GetCapabilities request sent to a SOS 1.0.0 with an invalid value for the service parameter must trigger an exception | Same as #2512. | |
| 1.0.0 | 2514 | A GetCapabilities request sent to a SOS 1.0.0 server with invalid parameter/value pairs, it must trigger an exception | Same as #2512. | |
| 1.0.0 | 3103 | GetObservation request sent to a SOS 1.0.0 server with a procedure specified as a URI returns an exception | ||
WMS 1.1.1
Status: All tests passed. Need to get compliance certificate.
- MapServer Version 5.4.2
- Tests Engine http://cite.opengeospatial.org/teamengine/
- Tests Session
s0018 s_wms1.1.1_ms5.4.2_basic s0019 s_wms1.1.1_ms5.4.2_queryable
- Tested -Basic Profile
-Queryable Profile
- Results summary
There are actually two profiles that were tested: basic and queryable. MapServer 5.4.2 used to pass 87 required tests for the basic profile and 88 tests for the queryable profile. MapServer is conformed to WMS 1.1.1 specification.
WMS 1.3.0
Status: All tests passed. Need to get compliance certificate.
- MapServer Version 5.4.2
- Tests Engine http://cite.opengeospatial.org/teamengine/
- Tests Session
s0020 s_wms1.3.0_ms5.4.2_basic s0021 s_wms1.3.0_ms5.4.2_queryable
- Tested -Basic Profile
-Queryable Profile
- Results summary MapServer 5.4.2 passed all of the 188 tests in the basic profile and all of the 188 tests in the queryable profile. MapServer is conformed to the WMS 1.3.0 specification.
There are the same number of tests in both profiles.
WFS 1.0.0
Status: First pass of testing completed. Need to fix issues.
- MapServer Version 5.4.1
- Tests Engine http://cite.opengeospatial.org/teamengine/
- Tests Session
s0016 s_wfs1.0.0_cgf_ms5.4.1 s0017 s_wfs1.0.0_cdf_ms5.4.1
- Tested
- basic-describefeaturetype
- basic-getcapabilities
- basic-getfeature-filter-comparisonoperators
- basic-getfeature-filter-spatialoperators
- URL used for testing http://dev1.lan.mapgears.com/manwe/cgi-bin/mswfs100_ogc_cite?&VeRsIoN=1.0.0&SeRvIcE=wfS&ReQuEsT=Getcapabilities
- exemptions/allowances The OGC WFS 1.0.0 compliance tests suite uses dual namespaces in the test requests. Since MapServer does not support multiple namespaces in the same map file, the tests listed in the table below failed. After some discussion on the CITE mailing list (http://lists.opengeospatial.org/pipermail/cite-forum/2008-January/000086.html), it comes out that if a WFS server does not support multiple namespaces, the tests suite may be run as many time as there are different namespaces. Then the test results could be combined to satisfy the tests suite. For that, we need to create two different tests sessions: the first one set up with the "cdf" namespace and the second one, with the "cgf" namespace, and run them separately.
The discussion took place on the mailing list but the final answer was posted offline by Greg Buehler. This is why I pasted it below.
-------- Original Message -------- Subject: Re: [CITE-Forum] WFS 1.0.0 TEAM Engine tests suite: multiple namespaces] Date: Mon, 18 Feb 2008 15:45:15 -0500 From: Greg Buehler <gbuehler@opengeospatial.org> To: Normand Savard <nsavard@mapgears.com> References: <2DC5CCA14756424BBBEE8B4B2E4A682F036CEF56@ecburexch1.ontario.int.ec.gc.ca> <47B2F670.8070608@mapgears.com> <47B9D994.3030307@mapgears.com> Norm, After looking into this, I believe that you are correct. The Test Scripts are too limiting and should not fail implementations that do not support multiple namespaces. Please do submit your test results with the below notice. As long as the tests are all complete, I can review the test results with the below test failures. Greg Buehler
The "wfs_namespace_prefix" and "wfs_namespace_uri" metadatas have to be modified to follow the current tests session that is based on the namespace. The following table describe the settings used in the tests.
"WFS_TITLE" "cite:OGC_CITE WFS Server" "WFS_ONLINERESOURCE" "http://dev1.lan.mapgears.com/manwe/cgi-bin/mswfs100_ogc_cite?" "WFS_SRS" "EPSG:32615" "OWS_SCHEMAS_LOCATION" "http://schemas.opengis.net" "WFS_ACCESSCONTRAINTS" "none" "WFS_FEES" "none" wfs_namespace_prefix" "cdf"/"cgf" "wfs_namespace_uri" "http://www.opengis.net/cite/data"/"!http://www.opengis.net/cite/geometry"
- not supporting multiple namespaces: see #2484 for more on this issue. Based on this allowances the following tests passed. Two sessions were created, one with each namespace.
Test Name Actual Namespace Should be wfs:test1.0.0-basic-describefeaturetype-get-4 cgf cdf wfs:test1.0.0-basic-describefeaturetype-post-4 cgf cdf wfs:test1.0.0-basic-describefeaturetype-get-7 cgf cdf wfs:test1.0.0-basic-describefeaturetype-post-7 cgf cdf wfs:test1.0.0-basic-getfeature-get-1 through 10 cgf cdf wfs:test1.0.0-basic-getfeature-post-1 through 10 cgf cdf wfs:test1.0.0-basic-describefeaturetype-get-5 cdf cgf wfs:test1.0.0-basic-describefeaturetype-post-5 cdf cgf wfs:test1.0.0-basic-describefeaturetype-get-6 cdf cgf wfs:test1.0.0-basic-describefeaturetype-post-6 cdf cgf wfs:test1.0.0-basic-getfeature-get-1 through 10 cdf cgf wfs:test1.0.0-basic-getfeature-post-1 through 10 cdf cgf cdf cgf cdf cgf
- Results Summary MapServer passed 34 of 132 tests. There are 16 bugs still opened.
There are three main issues that are:
- Namespace needs to be strip off of a feature name when serving a WFS GetFeature request (2432)
- Add a mechanism to support gml:_geometryProperty for a WFS 1.0.0 server (2445)
- Add multipoint, multipolygon, multilinestring geometries support to define an area in a spatial filter, when a GetFeature request is sent to a WFS 1.0.0 server (2606)
The following table lists the tests that failed and the related ticket number.
Test Name Ticket Description wfs:test1.0.0-basic-getfeature-filter-comparisonoperators-get-1 through 21 2432 namespace needs to be strip off of a feature name when serving a WFS GetFeature? request wfs:test1.0.0-basic-getfeature-filter-comparisonoperators-post-1 through 21 2432 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-bbox-get-1 through 12 2445 Add a mechanism to support gml:_geometryProperty for a WFS 1.0.0 server wfs:test1.0.0-basic-getfeature-filter-spatialoperators-bbox-post-1 through 12 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-get-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-get-3-4-7-8-11-12 2606 Add multipoint, multipolygon, multilinestring geometries support to define an area in a spatial filter, when a GetFeature request is sent to a WFS 1.0.0 server wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-post-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-get-6 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-post-6 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-get-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-post-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-get-1-3-5 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-get-2-4-6-8-10-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-post-1-3-5 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-post-2-4-6-8-10-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-get-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-post-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-get-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-post-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-get-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-post-6-10 2445| wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-get-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-post-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-post-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-get-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-get-3-4-7-8-11-12 2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-post-2-6-10 2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-post-3-4-7-8-11-12 2606
All bugs are shown with this query:
WFS 1.1.0
Status: Stalled
- MapServer 5.4.1
- URL used
- Tests Engine http://cite.opengeospatial.org/te2/
- Tests Session
s0006 s_wfs1.1.0_cgf_ms5.4.1
- Tested
- GetCapabilities, GET and POST methods
- DescribeFeature, POST and GET methods
- GetFeature, POST and GET methods
- Results summary
- The main issue is that the layer contains multiple geometry types on the same layer. Follow this thread http://lists.opengeospatial.org/pipermail/cite-forum/2008-April/000115.html on the mailing list.
- The tests suite was run but stopped because the capabilities document does not validate (3076).
- Axis order must be in order lat long for 4326 for 1.1.0 (2899).
- XML validation failed. We need to make it possible to specify that the geometry is using one of the predefined properties from the GML 2.1.2 feature.xsd schema by referring to the GML schema definition and using the property in the 'gml:...' namespace instead of defining a new property in the namespace of the MapServer WFS service(2445).
All bugs are shown with this query:
WCS 1.0.0
Status: First pass testing completed. Waiting for ticket fix and answers from CITE.
- Tested
- GetCapabilities, GET KVP and POST XML encodings
- DescribeCoverage, GET KVP and POST XML encodings
- GetFeature, GET KVP and POST XML encodings
- MapServer Version 5.4.2
- Tests Engine
- Tests Session
s_wcs1.0.0_ms5.4.2 (s0007)
- Results summary MapServer passed 65 out of 69 tests. Of these four tests that failed, two are the same tests but they used a post request instead of a get request.
The following table lists the tests that failed and the related ticket number.
Test Name Ticket Description wcs1-0-0:getcoverage_operations-getcoverage_request-response_crs-get-kvp-2 3083 When a GetCoverage request is sent to a WCS 1.0.0 server with a bbox that is the same as the defined bbox (describecoverage), the server must NOT return an exception
All bugs are shown with this query:
- Note 1:
There are some issues about OGC CITE tests suite. The first one is that the WCS capabilities document does not validate with XMLSpy. An email has been sent to the CITE mailing list (http://lists.opengeospatial.org/pipermail/cite-forum/2008-January/000082.html, http://lists.opengeospatial.org/pipermail/cite-forum/2008-February/000098.html) and after some discussion on the wcs-1.2.swg@… mailing list, it was detected that a XML restriction on the AbstractDescriptionBaseType element was causing this issue.
The purpose of this note is to keep a record of what need to be done in order to have a valid capabilities schema since the official Web schema http://schemas.opengis.net/wcs/1.0.0/wcsCapabilities.xsd was not updated with the proposed solution. The relevant parts of the emails exchange are pasted in the appendix A below since the discussion happened on the wcs-1.2.swg@… mailing list. To solve this issue, the second solution proposed by Alexandre Robin was applied on a local copy of the schema. The XML was validated against this local copy and is valid. So the capabilities schema was changed as follow.
- Note 2:
There is another issue when testing the version negotiation: wcs1-0-0:basic_service_elements-version_numbering_and_negotiation-1. If a GetCapabilities request is sent with no value for the version parameter then the capabilities response have to be the highest version supported. Since MapServer supports wcs 1.1.1 this is the wcs 1.1.1 capabilities response that is returned and the XML does not validate against the wcs 1.0.0 schema. Chuck modified the test to pass as long as the wcs server does not return a service exception (http://lists.opengeospatial.org/pipermail/cite-forum/2008-February/000109.html and http://lists.opengeospatial.org/pipermail/cite-forum/2008-August/000134.html)
- Note 3:
There is also an issue with one of the test (wcs1-0-0:getcoverage_operations-getcoverage_request-time-get-kvp-1) that uses the time parameter in a GetCoverage request (http://dev1.lan.mapgears.com/manwe/cgi-bin/mswcs100_ogc_cite?&VeRsIoN=1.0.0&FoRmAt=GeoTIFF&TiMe=&CrS=EPSG:4326&CoVeRaGe=ndvi&ReQuEsT=GetCoverage&HeIgHt=100&SeRvIcE=WCS&WiDtH=200). The test retrieves the "timePositions" parameter instead of the time position. An email has been sent to the CITE list (http://lists.opengeospatial.org/pipermail/cite-forum/2009-August/000158.html).
Answer pasted here since it does not appear on the mailing list.
-------- Original Message -------- Subject: Re: [CITE-Forum] WCS 1.0.0 timePosition parameter is not retrieve correctly Date: Thu, 13 Aug 2009 01:01:19 +0200 From: Peter Baumann <baumann@rasdaman.com> Organization: rasdaman GmbH / Jacobs University Bremen To: Normand Savard <nsavard@mapgears.com> CC: cite-forum@lists.opengeospatial.org <cite-forum@lists.opengeospatial.org>, wcs-2.0.swg <wcs-2.0.swg@lists.opengeospatial.org> References: <4A81C880.9010700@mapgears.com> Normand, thanks for notifying. Actually, the WCS suite is planned to be revamped, we have submitted a request to the OWS-7 planning team led by David Arctur. As WCS-2.0.SWG co-chair I will archive your input so that we can duly consider it. Unfortunately it seems like there are not resources to look into the issue immediately - but I cc to the WCS list, maybe somebody with TEAM engine experience can chime in. cheers, Peter
- Note 4:
Finally there is an issue with a GetCoverage request with a "time" parameter and no "crs" parameter (wcs1-0-0:getcoverage_operations-getcoverage_request-time-get-kvp-2). The test is aimed to verify that a request with an invalid "time" parameter has to return a service exception. (request sent: http://dev1.lan.mapgears.com/manwe/cgi-bin/mswcs100_ogc_cite?&WiDtH=200&CoVeRaGe=ndvi&TiMe=WCS_TIME_INVALID&ReQuEsT=GetCoverage&VeRsIoN=1.0.0&SeRvIcE=WCS&FoRmAt=GeoTIFF&HeIgHt=100). An email has been sent (http://lists.opengeospatial.org/pipermail/cite-forum/2009-August/000160.html).
- Appendix A
From:
<!-- =========================================================== -->
<xs:complexType name="AbstractDescriptionBaseType" abstract="true">
<xs:annotation>
<xs:documentation>Description of a WCS object. </xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="gml:AbstractGMLType">
<xs:sequence>
<xs:element ref="metadataLink" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- =========================================================== -->
<xs:complexType name="AbstractDescriptionType" abstract="true">
<xs:annotation>
<xs:documentation>Human-readable descriptive information for the object it is included
within.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractDescriptionBaseType">
<xs:sequence>
<xs:element ref="description" minOccurs="0"/>
<xs:element ref="name"/>
<xs:element name="label" type="xs:string">
<xs:annotation>
<xs:documentation>Short human-readable label for this object, for human
interface display. </xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute ref="gml:id" use="prohibited"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
To:
<!-- =========================================================== -->
<xs:complexType name="AbstractDescriptionBaseType" abstract="true">
<xs:annotation>
<xs:documentation>Description of a WCS object. </xs:documentation>http://dev1.lan.mapgears.com/manwe/cgi-bin/mswcs111_ogc_cite?service=WCS&request=GetCapabilities
</xs:annotation>
<xs:complexContent>
<xs:restriction base="gml:AbstractGMLType">
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- =========================================================== -->
<xs:complexType name="AbstractDescriptionType" abstract="true">
<xs:annotation>
<xs:documentation>Human-readable descriptive information for the object it is included
within.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractDescriptionBaseType">
<xs:sequence>
<xs:element ref="metadataLink" minOccurs="0" maxOccurs="unbounded"/>
...
</xs:complexType>
Normand Savard wrote: > >So I wanted to get more information on this error by validating the WCS > >1.0.0 capababilities against its associated wcsCapabilities.xsd with XML > >Spy and I got the following error: > > > >"Error in reference schema or DTD. Type 'AbstractDescriptionBaseType' > >is not a valid restriction of type 'gml:AbstractGMLType'." > >Do someone else got this error before? Can someone give me some pointers? > > De : Robin, Alexandre > Envoyé : mardi 12 février 2008 10:01 > À : 'Whiteside, Arliss E (US SSA)'; Peter Baumann; Kralidis,Tom > [Burlington]; wcs-1.2.swg@opengeospatial.org; Kevin Stegemoller Objet > : RE: [WCS-1.2.swg] [CITE-Forum] [Fwd: WCS 1.0.0 legacy tests engine] > > > > Arliss, Peter, > > > > The error in this schema is pretty obvious and is not due to new > validators being too picky. > > There was an error in this schema from the start and the author > probably used a tool like XMLSpy v5 to validate it which does not > handle restrictions at all... > > > > The error is that AbstractDescriptionBaseType in wcsCapabilities.xsd > derives from gml:AbstractGMLType by restriction but adds a > metadataLink element which is not present in the base type. > This is an erroneous restriction for sure and needs to be fixed... > > > > The simplest solution would be to not derive from gml:AbstractGMLType > since we don't keep anything from this object anyway!!! > > If some implementations are relying on the fact that it derives from a > gml object (which I doubt since it never validated with automatic > binding frameworks!), it is also possible to move the metadataLink in > the AbstractDescriptionType thus making the restriction correct... >
WCS 1.1.0
Status: Works with wcs and schemaslocation 1.1.1. Need to check test execution results.
- MapServer Version 5.4.2
- Tested
- GetCapabilities, GET KVP and POST XML encodings
- DescribeCoverage, GET KVP and POST XML encodings
- GetFeature, GET KVP and POST XML encodings
- Tests Engine http://cite.opengeospatial.org/te2/
- Tests Session
s0008 s_wcs1.1.0_ms5.4.2
- Results Summary There are 177 tests in total.
The following table lists the tests that failed and the related ticket number.
Test Name Ticket Description wcs:GetCapabilities-main 3105 GetCapabilities request does not support the sections wcs:DescribeCoverage-main 3105 wcs:GetCoverage-main 3105 wcs:GetCapabilities-main 3086 wcs 1.1.1 GetCapabilities response does not contain the schemaLocation wcs:DescribeCoverage-main 3086 wcs:GetCoverage-main [http://trac.osgeo.org/mapserver/ticket/3086 3086
All bugs are shown with this query:
SOS 1.0.0
Status: Testing completed, waiting for bugs fixed
- MapServer Version 5.4.2
- Tested
- GetCapabilities, GET method
- DescribeSenor, POST method
- GetObservation, POST method
Tests Engine http://cite.opengeospatial.org/te2/
- Tests Session
s_sos1.0.0_ms5.4.2
- Results Summary There are 34 tests in total, 16 failed.
The following table lists the tests that failed and the related ticket number.
Test Name Ticket Description owsTests:ows-OWS.GetCapabilities-Exceptions.1 2512 A GetCapabilities issue to a SOS 1.0.0 server with no service parameter must trigger an OWS 1.0.0 exception getCapabilities:core-SOS.GetCapabilities-KVPRequestParameterHandling.1 2512 owsTests:ows-OWS.GetCapabilities-Exceptions.2 2513 A GetCapabilities request sent to a SOS 1.0.0 with an invalid value for the service parameter must trigger an exception getCapabilities:core-SOS.GetCapabilities-KVPRequestServiceParameterHandling.1 2513 owsTests:ows-OWS.GetCapabilities-Exceptions.5 2514 A GetCapabilities request sent to a SOS 1.0.0 server with invalid parameter/value pairs, it must trigger an exception getObservation:core-SOS.GetObservation-RequestInvalidFeatureOfInterest.1 2559 A GetObservation request with an invalid featureOfInterest value sent to a SOS 1.0.0 server must return an exception getObservation:core-SOS.GetObservation-ResponseMatchingSRSData.1 2646 XML of the response to a GetObservation request sent to SOS 1.0.0 server doesn't validate against the schema getObservation:core-SOS.GetObservation-ResponseMatchingResponseFormatData.1 2646 getObservation:core-SOS.GetObservation-ResponseMatchingResultData.1 2646 getObservation:core-SOS.GetObservation-ResponseMatchingFeatureOfInterestData.1 2646 getObservation:core-SOS.GetObservation-ResponseMatchingProcedureData.1 3103 GetObservation request sent to a SOS 1.0.0 server with a procedure specified as a URI returns an exception
All bugs are shown with this query:
- Note 1: The getObservation:core-SOS.GetObservation-RequestInvalidEventTime.1, getObservation:core-SOS.GetObservation-ResponseMatchingEventTimeData.1, getObservation:core-SOS.GetObservation-ResponseAdvertisedEventTimeData.1 is marked as "passed" but is in fact not executed because the "TM_Equals" attribute value is not detected in the capabilities document. I post a question to the OGC forum ([http://feature.opengeospatial.org/forumbb/viewtopic.php?t=1763)
WMC 1.1.0
Status: Testing completed, there is an issue with one of the test, posted a question on the forum http://feature.opengeospatial.org/forumbb/index.php
- MapServer Version 5.4.2
- Tested
- All trials
o Standalone context document or context collection document syntax
- Follow Links option
o Availability of linked resources and integrity of link attributes (format, width, and height) o Integrity of essential layer information from layers derived from WMS version 1.0.0, 1.1.0, or 1.1.1 sources o Integrity of context documents in a context collection
- Unique IDs recommendation
o Uniqueness of the root element's id within the context document or context collection document
- Tests Engine http://cite.opengeospatial.org/te2/
- Tests Session
s_wmc1.1.0_ms5.4.2
- Results Summary The test engine reports 5 tests out of 131 tests in total, that failed. In fact there is only one test that failed: wmc:check-dimensionlist with the Autos layer (Parents of the test that failed are also counted as failed tests which increase the failed tests count. There is probably an error with this test. A question was posted on the forum and we are waiting for an answer (http://feature.opengeospatial.org/forumbb/viewforum.php?f=18).
