| Version 62 (modified by , 15 years ago) ( diff ) |
|---|
Status report on MapServer OGC CITE Compliance
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.
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 (http://trac.osgeo.org/mapserver/ticket/2432)
- Add a mechanism to support gml:_geometryProperty for a WFS 1.0.0 server (http://trac.osgeo.org/mapserver/ticket/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 (http://trac.osgeo.org/mapserver/ticket/2606)
The following table lists the tests that failed and the related ticket number.
Test Name Ticket wfs:test1.0.0-basic-getfeature-filter-comparisonoperators-get-1 through 21 http://trac.osgeo.org/mapserver/ticket/2432 wfs:test1.0.0-basic-getfeature-filter-comparisonoperators-post-1 through 21 http://trac.osgeo.org/mapserver/ticket/2432 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-bbox-get-1 through 12 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-bbox-post-1 through 12 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-get-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-post-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-get-6 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-post-6 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-get-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-post-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-get-1-3-5 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-get-2-4-6-8-10-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-post-1-3-5 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-post-2-4-6-8-10-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-get-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-post-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-get-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-post-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-get-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-post-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-get-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-post-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-get-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-get-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/2606 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-post-2-6-10 http://trac.osgeo.org/mapserver/ticket/2445 wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-post-3-4-7-8-11-12 http://trac.osgeo.org/mapserver/ticket/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 (http://trac.osgeo.org/mapserver/ticket/3076).
- Axis order must be in order lat long for 4326 for 1.1.0 (http://trac.osgeo.org/mapserver/ticket/2899).
All bugs are shown with this query:
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.
WCS 1.0.0
Status: Testing completed
- 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 wcs1-0-0:getcoverage_operations-getcoverage_request-response_crs-get-kvp-2 http://trac.osgeo.org/mapserver/ticket/3083#comment:1
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).
- 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>
</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.1
Status: Not tested
- Tested
- GetCapabilities, GET KVP and POST XML encodings
- DescribeCoverage, GET KVP and POST XML encodings
- GetFeature, GET KVP and POST XML encodings
SOS 1.0.0
Status: Testing completed
