| Version 52 (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/
- 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/
- 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/
- 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
- 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 passed 37 out of 69 tests. This number is not really meaningful though because the updateSequence tests are triggered and MapServer does not support it. Also the tests on time dimension are not triggered because MapServer does not advertized it in its capabilities document.
There are a main issue about OGC CITE tests suite. The WCS capabilities document does not validate with XMLSpy. An email has been sent to the mailing list and we are waiting for an answer on this issue.
There are seven of thirteen bugs still opened.
All bugs are shown with this query: http://trac.osgeo.org/mapserver/query?reporter=%7Ensavard&component=WCS+Server&order=priority
- Note There is a mistake in the capabilities schema found on http://schemas.opengis.net/wcs/1.0.0/wcsCapabilities.xsd. The relevant parts of the emails exchange are pasted below. To solve this issue, the second solution proposed by Alexandre Robin was applied. So the capabilities schema was changed as follow.
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
Note:
See TracWiki
for help on using the wiki.
