2 WMS Profile
|
For a 2 star accredited service, the service and ALL OneGeology layers must conform at least to the minimum requirements described in this profile. |
For your service(s) to be accepted in the OneGeology Portal the participant protocol requires that you follow the WMS service naming conventions as agreed by the OneGeology Technical Working Group; these naming conventions (the ‘profile’) are described in detail with examples in this section.
The Web Map Service must conform to the appropriate WMS specification. The latest editions of MapServer, ArcGIS server, and ArcIMS help provide the version 1.3.0 WMS capability by default, though you may need to make some modifications to the GetCapabilities response to achieve full conformance to the specification and/or OneGeology WMS profile. With the latest version of MapServer you need to make no changes to the .map configuration file to achieve all versions of the WMS standards (that is WMS versions 1.0.0, 1.0.7, 1.1.0, 1.1.1, 1.3.0).
|
For a 3 star accredited service, the service must support WMS version 1.3.0. Note, in line with the requirement to conform to the WMS specification (above), this means that the service must supply the highest WMS version supported (in the GetCapabilities response) when no version number is given in the GetCapabilities request. |
In the profile we make a distinction between the organization that owns or has copyright to provide the data (whom we term the ‘data owner’) and the organization that serves that data as a WMS (whom we term the ‘service provider’).
The intention of the OneGeology Portal is that there will be one service (and only one service) per data owner per language; though it is understood this won’t be possible in some cases, such as when you are serving different data sets from different servers. Any such service will serve one or more layers, which may be of different scale and/or of different geographical extent. The OneGeology WMS profile sets out a naming mechanism to ensure uniqueness across service names and layer names, whilst maintaining human readability.
Where a data owner serves their own data (is also the service provider) in a single language we expect a single service. Where an organization acts as a buddy to serve data for a partner geological survey organization (is the service provider) we expect one service for each organization per language served.
For example, at the time of writing The British Geological Survey is hosting its own data, and is acting as a buddy to host data for the Afghanistan Geological Survey, and for the Namibian Geological Survey, and for the Falkland Island Government, and for Geoscience Australia for Antarctica data, each of these is only available in English language versions. The British Geological Survey is also hosting a single language (French) service for Burkina Faso. The net result is that BGS, acting in the role of service provider, is serving six separate services (six separate service URLs).
Section last modified: 06 October 2015