Opened 12 years ago
Closed 10 years ago
#366 closed defect (fixed)
Invalid WCS 2.0.1 GetCapabilities response (Rasdaman 9.0.3) was: Invalid WCS 2.0.0 GetCapabilities response (Rasdaman 8.4.1)
Reported by: | James Passmore | Owned by: | Piero Campalani |
---|---|---|---|
Priority: | critical | Milestone: | 9.0.x |
Component: | petascope | Version: | 9.0 |
Keywords: | WCS GetCapabilities | Cc: | |
Complexity: | Trivial |
Description
The ows:Profile elements are inserted into the wrong location in the WCS 2.0.0 GetCapabilities response. They appear after the ows:AccessConstraints element, whereas they should be added between the ows:ServiceTypeVersion and ows:Fees elements.
See: http://earthserver.bgs.ac.uk/petascope?service=WCS&Request=GetCapabilities&version=2.0.0&
Change History (18)
comment:1 by , 12 years ago
comment:2 by , 11 years ago
Complexity: | Medium → Trivial |
---|---|
Milestone: | → 8.4.2 |
Owner: | changed from | to
Priority: | major → minor |
Status: | new → assigned |
comment:3 by , 11 years ago
Milestone: | 8.4.3 → 8.4.4 |
---|
comment:4 by , 11 years ago
In addition there is now (version 8.4.3) an error in the way the wcs:ServiceMetadata block is populated.
Previously the following was valid, with the extended metadata section (ows:ExtendedCapabilities) inserted in the ServiceMetadata.templ template and the crs:CrsMetadata section inserted automatically:
<wcs:ServiceMetadata xmlns="http://www.opengis.net/ows/2.0" xmlns:inspire_common="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:inspire_dls="http://inspire.ec.europa.eu/schemas/inspire_dls/1.0"> <!-- Some INSPIRE compliant ISO 19115:2003 DISCOVERY metadata for this download service goes here --> <ows:ExtendedCapabilities> <inspire_dls:ExtendedCapabilities> <inspire_common:ResourceLocator> <inspire_common:URL>http://earthserver.bgs.ac.uk/petascope?</inspire_common:URL> </inspire_common:ResourceLocator> <inspire_common:ResourceType>service</inspire_common:ResourceType> <inspire_common:TemporalReference> <inspire_common:DateOfLastRevision>2012-11-26</inspire_common:DateOfLastRevision> </inspire_common:TemporalReference> <inspire_common:Conformity> <inspire_common:Specification> <inspire_common:Title>-</inspire_common:Title> <inspire_common:DateOfLastRevision>2012-11-26</inspire_common:DateOfLastRevision> </inspire_common:Specification> <inspire_common:Degree>notEvaluated</inspire_common:Degree> </inspire_common:Conformity> <inspire_common:MetadataPointOfContact> <inspire_common:OrganisationName>James Passmore</inspire_common:OrganisationName> <inspire_common:EmailAddress>enqiries@bgs.ac.uk</inspire_common:EmailAddress> </inspire_common:MetadataPointOfContact> <inspire_common:MetadataDate>2012-11-26</inspire_common:MetadataDate> <inspire_common:SpatialDataServiceType>download</inspire_common:SpatialDataServiceType> <inspire_common:MandatoryKeyword xsi:type="inspire_common:classificationOfSpatialDataService"> <inspire_common:KeywordValue>infoCoverageAccessService</inspire_common:KeywordValue> </inspire_common:MandatoryKeyword> <inspire_common:SupportedLanguages> <inspire_common:DefaultLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:DefaultLanguage> </inspire_common:SupportedLanguages> <inspire_common:ResponseLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:ResponseLanguage> <inspire_dls:SpatialDataSetIdentifier> <inspire_common:Code>SOME_BGS_EARTHSERVER_SERVICE_UNIQUE_CODE_OR_SOMESUCH</inspire_common:Code> <inspire_common:Namespace>http://ns.bgs.ac.uk/</inspire_common:Namespace> </inspire_dls:SpatialDataSetIdentifier> </inspire_dls:ExtendedCapabilities> </ows:ExtendedCapabilities> <!-- crs:CrsMetadata is automatically inserted below... --> <crs:CrsMetadata> <crs:supportedCrs>http://www.opengis.net/def/crs/EPSG/0/2000</crs:supportedCrs> <crs:supportedCrs>http://www.opengis.net/def/crs/EPSG/0/2001</crs:supportedCrs> <crs:supportedCrs>http://www.opengis.net/def/crs/EPSG/0/2002</crs:supportedCrs> ...
Now however there is an issue with trying to insert the ows:ExtendedCapabilities in the
ServiceMetadata.templ template. The wcsCommon schema tells us that the structure is now:
<element name="ServiceMetadata" type="wcs:ServiceMetadataType"> <annotation> <documentation>ServiceMetadata contains information describing the WCS service on hand. Extension elements allow WCS extension standards to define their individual extra service metadata. </documentation> </annotation> </element> <complexType name="ServiceMetadataType"> <sequence> <element name="formatSupported" type="anyURI" maxOccurs="unbounded"/> <element ref="wcs:Extension" minOccurs="0"/> </sequence> </complexType>
So the structure we need to create here is:
<wcs:ServiceMetadata xmlns="http://www.opengis.net/ows/2.0" xmlns:inspire_common="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:inspire_dls="http://inspire.ec.europa.eu/schemas/inspire_dls/1.0"> <wcs:formatSupported>application/gml+xml</wcs:formatSupported> <wcs:formatSupported>image/tiff</wcs:formatSupported> <wcs:formatSupported>image/jp2</wcs:formatSupported> <wcs:formatSupported>application/netcdf</wcs:formatSupported> <!-- Some INSPIRE compliant ISO 19115:2003 DISCOVERY metadata for this download service goes here --> <wcs:Extension> <ows:ExtendedCapabilities> <inspire_dls:ExtendedCapabilities> <inspire_common:ResourceLocator> <inspire_common:URL>http://earthserver.bgs.ac.uk/petascope?</inspire_common:URL> </inspire_common:ResourceLocator> <inspire_common:ResourceType>service</inspire_common:ResourceType> <inspire_common:TemporalReference> <inspire_common:DateOfLastRevision>2012-11-26</inspire_common:DateOfLastRevision> </inspire_common:TemporalReference> <inspire_common:Conformity> <inspire_common:Specification> <inspire_common:Title>-</inspire_common:Title> <inspire_common:DateOfLastRevision>2012-11-26</inspire_common:DateOfLastRevision> </inspire_common:Specification> <inspire_common:Degree>notEvaluated</inspire_common:Degree> </inspire_common:Conformity> <inspire_common:MetadataPointOfContact> <inspire_common:OrganisationName>James Passmore</inspire_common:OrganisationName> <inspire_common:EmailAddress>enqiries@bgs.ac.uk</inspire_common:EmailAddress> </inspire_common:MetadataPointOfContact> <inspire_common:MetadataDate>2012-11-26</inspire_common:MetadataDate> <inspire_common:SpatialDataServiceType>download</inspire_common:SpatialDataServiceType> <inspire_common:MandatoryKeyword> <inspire_common:KeywordValue>infoCoverageAccessService</inspire_common:KeywordValue> </inspire_common:MandatoryKeyword> <inspire_common:SupportedLanguages> <inspire_common:DefaultLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:DefaultLanguage> </inspire_common:SupportedLanguages> <inspire_common:ResponseLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:ResponseLanguage> <inspire_dls:SpatialDataSetIdentifier> <inspire_common:Code>SOME_BGS_EARTHSERVER_SERVICE_UNIQUE_CODE_OR_SOMESUCH</inspire_common:Code> <inspire_common:Namespace>http://ns.bgs.ac.uk/</inspire_common:Namespace> </inspire_dls:SpatialDataSetIdentifier> </inspire_dls:ExtendedCapabilities> </ows:ExtendedCapabilities> <!-- crs:CrsMetadata is automatically inserted below... --> <crs:CrsMetadata> <crs:supportedCrs>http://www.opengis.net/def/crs/EPSG/0/</crs:supportedCrs> </crs:CrsMetadata> </wcs:Extension> </wcs:ServiceMetadata>
To address this issue the crs:CrsMetadata elements need to be included as part of the
ServiceMetadata.templ template.
comment:5 by , 11 years ago
Status: | assigned → accepted |
---|
follow-up: 7 comment:6 by , 11 years ago
Dear James,
I submitted a patch for this issue, however I did not well understand the second issue on CRS metadata you reported: more exactly, how are you modifying the ServiceMetadata.templ
template?
comment:7 by , 11 years ago
In the ServiceMetadata.templ
template, I want to insert an ows:ExtendedCapabilities
section to hold some INSPIRE download service metadata. To do this I need to insert the ows:ExtendedCapabilities
section inside an wcs:Extension
section. The wcsCommon schema tells me that there can only be one wcs:Extension
section within the wcs:ServiceMetadata
section. The crs:CrsMetadata
section must also be placed within a wcs:Extension
section to be valid.
So my problem is how do I add my ows:ExtendedCapabilities
section to the same wcs:Extension
section as the crs:CrsMetadata
section?
follow-up: 9 comment:8 by , 11 years ago
Yes I see. In comment:4 you said that previously you were able to do this: how did you modify the ServiceMetadata.templ
template to achieve it?
comment:9 by , 11 years ago
Replying to pcampalani:
Yes I see. In comment:4 you said that previously you were able to do this: how did you modify the
ServiceMetadata.templ
template to achieve it?
No, I said that previously what I had was valid. That is what I had was valid against the schema that were referenced. So it appears that there may have been a change in the referenced schema.
comment:10 by , 11 years ago
Hi James,
patch submitted: it allows to add a WCS extension in the ServiceMetadata.templ
template, then supported formats and CRS metadata are correctly inserted.
comment:11 by , 11 years ago
NOTE: if the patches are accepted, I'll duplicate them for the master
branch as well.
comment:13 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
This has been fixed already 4 months ago in changeset:45c061d.
See also: this section.
Note: make sure the inserted XML is well-formed, otherwise the GetCapabilities handler will silently ignore the modifications: templates can have keywords there so it is currently a necessary behaviour not to throw an exception.
See petascope.wcs2.templates.Templates
class:
/** * @return in case parsing of contents fails, this returns null */ private static Element parseSafe(String contents) { try { return XMLUtil.buildDocument(null, contents).getRootElement(); } catch (Exception ex) { // nop - we might have non-XML documents return null; } }
comment:14 by , 10 years ago
Milestone: | 8.4.4 → 9.0.x |
---|---|
Priority: | minor → critical |
Resolution: | fixed |
Status: | closed → reopened |
Summary: | Invaild WCS 2.0.0 GetCapabilities response (Rasdaman 8.4.1) → Invalid WCS 2.0.1 GetCapabilities response (Rasdaman 9.0.3) was: Invalid WCS 2.0.0 GetCapabilities response (Rasdaman 8.4.1) |
Version: | 8.4 → 9.0.0 |
comment:15 by , 10 years ago
I currently have in my ServiceMetadata.templ the following ExtendedCapabilities XML:
<?xml version="1.0" encoding="UTF-8"?> <wcs:ServiceMetadata xmlns="http://www.opengis.net/ows/2.0" xmlns:ows="http://www.opengis.net/ows/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcs="http://www.opengis.net/wcs/2.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:inspire_common="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:inspire_dls="http://inspire.ec.europa.eu/schemas/inspire_dls/1.0"> <wcs:Extension> <ows:ExtendedCapabilities> <inspire_dls:ExtendedCapabilities> <inspire_common:ResourceLocator> <inspire_common:URL>http://earthserver.bgs.ac.uk/rasdaman/ows?</inspire_common:URL> </inspire_common:ResourceLocator> <inspire_common:ResourceType>service</inspire_common:ResourceType> <inspire_common:TemporalReference> <inspire_common:DateOfLastRevision>2014-07-01</inspire_common:DateOfLastRevision> </inspire_common:TemporalReference> <inspire_common:Conformity> <inspire_common:Specification> <inspire_common:Title>Technical Guidance for INSPIRE Download Services 3.1</inspire_common:Title> <inspire_common:DateOfLastRevision>2013-08-09</inspire_common:DateOfLastRevision> </inspire_common:Specification> <inspire_common:Degree>notEvaluated</inspire_common:Degree> </inspire_common:Conformity> <inspire_common:MetadataPointOfContact> <inspire_common:OrganisationName>British Geological Survey</inspire_common:OrganisationName> <inspire_common:EmailAddress>enquiries@bgs.ac.uk</inspire_common:EmailAddress> </inspire_common:MetadataPointOfContact> <inspire_common:MetadataDate>2012-11-26</inspire_common:MetadataDate> <inspire_common:SpatialDataServiceType>download</inspire_common:SpatialDataServiceType> <inspire_common:MandatoryKeyword> <inspire_common:KeywordValue>infoCoverageAccessService</inspire_common:KeywordValue> </inspire_common:MandatoryKeyword> <inspire_common:SupportedLanguages> <inspire_common:DefaultLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:DefaultLanguage> </inspire_common:SupportedLanguages> <inspire_common:ResponseLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:ResponseLanguage> <inspire_dls:SpatialDataSetIdentifier> <inspire_common:Code>fc929094-8a30-2617-e044-002128a47908</inspire_common:Code> </inspire_dls:SpatialDataSetIdentifier> </inspire_dls:ExtendedCapabilities> </ows:ExtendedCapabilities> </wcs:Extension> </wcs:ServiceMetadata>
This is XML valid and follows the agreed pattern for add to the wcs:Extension section of the GetCapabilities response.
When I run a GetCapabilities request like:
http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=GetCapabilities&acceptversions=2.0.1&
The wcs:Service section of the response is:
<wcs:ServiceMetadata xmlns="http://www.opengis.net/ows/2.0" xmlns:inspire_common="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:inspire_dls="http://inspire.ec.europa.eu/schemas/inspire_dls/1.0"> <wcs:formatSupported>image/jp2</wcs:formatSupported> <wcs:formatSupported>image/tiff</wcs:formatSupported> <wcs:formatSupported>application/gml+xml</wcs:formatSupported> <wcs:Extension> <int:InterpolationMetadata xmlns:int="http://www.opengis.net/wcs/interpolation/1.0"> <int:InterpolationSupported>http://www.opengis.net/def/interpolation/OGC/0/nearest-neighbor</int:InterpolationSupported> </int:InterpolationMetadata> </wcs:Extension> <wcs:Extension> <ows:ExtendedCapabilities> <inspire_dls:ExtendedCapabilities> <inspire_common:ResourceLocator> <inspire_common:URL>http://earthserver.bgs.ac.uk/rasdaman/ows?</inspire_common:URL> </inspire_common:ResourceLocator> <inspire_common:ResourceType>service</inspire_common:ResourceType> <inspire_common:TemporalReference> <inspire_common:DateOfLastRevision>2014-07-01</inspire_common:DateOfLastRevision> </inspire_common:TemporalReference> <inspire_common:Conformity> <inspire_common:Specification> <inspire_common:Title>Technical Guidance for INSPIRE Download Services 3.1</inspire_common:Title> <inspire_common:DateOfLastRevision>2013-08-09</inspire_common:DateOfLastRevision> </inspire_common:Specification> <inspire_common:Degree>notEvaluated</inspire_common:Degree> </inspire_common:Conformity> <inspire_common:MetadataPointOfContact> <inspire_common:OrganisationName>British Geological Survey</inspire_common:OrganisationName> <inspire_common:EmailAddress>enquiries@bgs.ac.uk</inspire_common:EmailAddress> </inspire_common:MetadataPointOfContact> <inspire_common:MetadataDate>2012-11-26</inspire_common:MetadataDate> <inspire_common:SpatialDataServiceType>download</inspire_common:SpatialDataServiceType> <inspire_common:MandatoryKeyword> <inspire_common:KeywordValue>infoCoverageAccessService</inspire_common:KeywordValue> </inspire_common:MandatoryKeyword> <inspire_common:SupportedLanguages> <inspire_common:DefaultLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:DefaultLanguage> </inspire_common:SupportedLanguages> <inspire_common:ResponseLanguage> <inspire_common:Language>eng</inspire_common:Language> </inspire_common:ResponseLanguage> <inspire_dls:SpatialDataSetIdentifier> <inspire_common:Code>fc929094-8a30-2617-e044-002128a47908</inspire_common:Code> </inspire_dls:SpatialDataSetIdentifier> </inspire_dls:ExtendedCapabilities> </ows:ExtendedCapabilities> </wcs:Extension> </wcs:ServiceMetadata>
That is two wcs:Extension sections are added to the response which, as we know, is invalid. This error seems to have been re-introduced from rasdaman 9.0.2.
Perhaps it's related to the addition of the int:InterpolationMetadata section?
comment:18 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
This I think occurs because the ows:Profile elements are automatically added to the response, whereas they should be included as part of the ServiceIdentification.templ.
So whilst it is OK to insert these elements automatically at the end of the default elements in this template:
It is not OK to insert them at the end of a fully populated ServiceIdentification.templ, such as: