2.4 WMS service-level metadata
Whilst the portal is layer based, it is important top add as much metadata as possible in the service metadata. Some metadata may only be added explicitly at the service level.
2.4.1 Required service-level metadata
The portal will attempt to harvest the following information from your service, and you must therefore aim to provide this information in your GetCapabilities response document.
Note, the indicative XPATH in the below tables relates to the GetCapabilities response document
|Metadata name||Indicative XPATH to metadata
(WMS version is shown in brackets)
|The WMS version. This will be automatically populated|
|As detailed in the above section
|Information about the service and general information about the map data served in the layers. You may also use this to field to describe the data owner organization, and its goals within OneGeology etc. You can also include in this section information about the scale layering of your service, and any other information that is not automatically extracted / viewable by the portal (or indeed any other client software).
|access constraints||/WMT_MS_Capabilities/Service/AccessConstraints (1.1.1)
|Information about who is allowed to use the data served by the WMS, and for what purpose they can use it for. Remember your WMS is available to any application that is able to access the Internet, not just through the OneGeology Portal.
For clarity to any potential users, it is recommended (within the OGC specifications) that you explicitly state when there are no access constraints on the using the service using the word "none".
Note too that there is no "AccessConstraints" metadata applicable at the layer level. If you need to define different access constraints for different layers in your service you will need to define these differences in the service level metadata.
A list of keywords or short phrases that users of the OneGeology portal and other catalogue services could use to search/discover your services. You must include the keyword OneGeology.
We would like you to also supply two special @ style ‘Metadata keywords‘ (MD_DATE@value and MD_LANG@value) that will be used to populate the OneGeology catalogue of services, and which help make the GetCapabilities response ISO19115 core compliant.
MD_DATE@ is used to add a date for when the information in the GetCapabilites file for the service was last updated, (for MapServer services this would be the same as a change to the .map configuration file). For example the exemplar BGS_Bedrock_and_Superficial_Geology service has a MD_DATE@ keyword of
MD_LANG@ is used to add the langauge (using the ISO 639-3 three letter codes) that the GetCapabilites file is populated with. This may be different from the language that the service returns its data in. For example the exemplar BGS_Bedrock_and_Superficial_Geology service has a MD_LANG@ keyword of
|Data (owner) provider||/WMT_MS_Capabilities/Service/ContactInformation/ContactPersonPrimary/ContactOrganization (1.1.1)
|The full name of the data owner organization not service provider, where these are different, such as in buddied services.
|Image Format||/WMT_MS_Capabilities/Capability/Request/GetMap/Format (1.1.1)
|One or more formats that the WMS service can provide its map layers in. This information would normally be populated automatically by the web service.|
|On-line Resource*||/WMT_MS_Capabilities/Service/OnlineResource (1.1.1)
|A link to the data owner organization web site, or web site with information about the data owner organization. Note this on-line resource is intended to provide additional information on the service and the provider of the service and is not intended to be the same as the on-line resource attribute attached to the layer, though this may be used if no other resource is available.
* Metadata required by the WMS specification.
Details on how to configure this metadata information in MapServer is shown in section 4.3.1 "Step-by-step configuration for MS4W" (below).
Section last modified : 08 September 2011.