wiki:MapServerOGCCITECompliance

Status report on MapServer OGC CITE Compliance

Fixing issues plan

SpecificationVersionTicketDescriptionNote
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 2432namespace needs to be strip off of a feature name when serving a WFS GetFeature? request Fixed by Assefa, to verify
1.0.0 2445Add a mechanism to support gml:_geometryProperty for a WFS 1.0.0 server
1.0.0 2606Add 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 2445Add 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.

  • Tests Session

s0018 s_wms1.1.1_ms5.4.2_basic s0019 s_wms1.1.1_ms5.4.2_queryable

-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 Session

s0020 s_wms1.3.0_ms5.4.2_basic s0021 s_wms1.3.0_ms5.4.2_queryable

-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 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
  • 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://gw.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 NamespaceShould be
wfs:test1.0.0-basic-describefeaturetype-get-4cgfcdf
wfs:test1.0.0-basic-describefeaturetype-post-4 cgfcdf
wfs:test1.0.0-basic-describefeaturetype-get-7 cgfcdf
wfs:test1.0.0-basic-describefeaturetype-post-7 cgfcdf
wfs:test1.0.0-basic-getfeature-get-1 through 10cgfcdf
wfs:test1.0.0-basic-getfeature-post-1 through 10cgfcdf
wfs:test1.0.0-basic-describefeaturetype-get-5cdfcgf
wfs:test1.0.0-basic-describefeaturetype-post-5cdfcgf
wfs:test1.0.0-basic-describefeaturetype-get-6cdfcgf
wfs:test1.0.0-basic-describefeaturetype-post-6cdfcgf
wfs:test1.0.0-basic-getfeature-get-1 through 10cdfcgf
wfs:test1.0.0-basic-getfeature-post-1 through 10cdfcgf
cdfcgf
cdfcgf
  • 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 NameTicketDescription
wfs:test1.0.0-basic-getfeature-filter-comparisonoperators-get-1 through 212432namespace 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 212432
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-bbox-get-1 through 122445Add 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 122445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-get-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-get-3-4-7-8-11-122606Add 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-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-contains-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-get-62445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-crosses-post-62445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-get-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-post-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-disjoint-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-get-1-3-52445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-get-2-4-6-8-10-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-post-1-3-52445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-dwithin-post-2-4-6-8-10-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-get-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-post-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-equals-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-get-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-post-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-intersects-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-get-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-post-6-102445|
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-overlaps-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-get-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-post-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-touches-post-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-get-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-get-3-4-7-8-11-122606
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-post-2-6-102445
wfs:test1.0.0-basic-getfeature-filter-spatialoperators-within-post-3-4-7-8-11-122606

All bugs are shown with this query:

http://trac.osgeo.org/mapserver/query?status=new&status=assigned&status=reopened&reporter=~nsavard&component=WFS+Server&order=priority

WFS 1.1.0

Status: Stalled

  • URL used

http://gw.mapgears.com:8500/cgi-bin/mswfs110_ogc_cite?&VeRsIoN=1.1.0&SeRvIcE=wfS&ReQuEsT=Getcapabilities

  • Tests Session

s0006 s_wfs1.1.0_cgf_ms5.4.1

  • Tested
  • 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:

http://trac.osgeo.org/mapserver/query?status=new&status=assigned&status=reopened&reporter=~nsavard&component=WFS+Server&order=priority

WCS 1.0.0

Status: First pass testing completed. Waiting for ticket fix and answers from CITE.

  • MapServer Version 5.4.2
  • Tests Engine

http://cite.opengeospatial.org/teamengine/

  • 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 NameTicketDescription
wcs1-0-0:getcoverage_operations-getcoverage_request-response_crs-get-kvp-23083When 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:

http://trac.osgeo.org/mapserver/query?status=new&status=assigned&status=reopened&reporter=~nsavard&component=WCS+Server&keywords=~ogc&order=priority

  • 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://gw.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://gw.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://gw.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
  • 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 NameTicketDescription
wcs:GetCapabilities-main3105GetCapabilities? request does not support the sections
wcs:DescribeCoverage-main3105
wcs:GetCoverage-main3105
wcs:GetCapabilities-main3086wcs 1.1.1 GetCapabilities? response does not contain the schemaLocation
wcs:DescribeCoverage-main3086
wcs:GetCoverage-main[http://trac.osgeo.org/mapserver/ticket/3086 3086

All bugs are shown with this query:

http://trac.osgeo.org/mapserver/query?status=new&status=assigned&status=reopened&reporter=~nsavard&component=WCS+Server&keywords=~ogc&order=priority

SOS 1.0.0

Status: Testing completed, waiting for bugs fixed

  • MapServer Version 5.4.2

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 NameTicketDescription
owsTests:ows-OWS.GetCapabilities-Exceptions.12512A 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.12512
owsTests:ows-OWS.GetCapabilities-Exceptions.22513A 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.12513
owsTests:ows-OWS.GetCapabilities-Exceptions.52514A 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.12559A GetObservation? request with an invalid featureOfInterest value sent to a SOS 1.0.0 server must return an exception
getObservation:core-SOS.GetObservation-ResponseMatchingSRSData.12646XML 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.12646
getObservation:core-SOS.GetObservation-ResponseMatchingResultData.12646
getObservation:core-SOS.GetObservation-ResponseMatchingFeatureOfInterestData.12646
getObservation:core-SOS.GetObservation-ResponseMatchingProcedureData.13103GetObservation? 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:

http://trac.osgeo.org/mapserver/query?status=new&status=assigned&status=reopened&component=SOS+Server&keywords=~OGC&order=priority

  • 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 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).
Last modified 7 years ago Last modified on Jul 4, 2010 1:11:55 PM