2 WMS 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 current WMS specification that can be accessed by the portal is WMS version 1.1.1, though the intention is to move to support WMS 1.3.0 as soon as possible (as soon as the version is fully supported by the OpenLayers software used by the portal); so it would be worth ensuring that your service is capable of delivering to both specifications. The portal will then support both versions until such time as this no longer seems appropriate by the Technical Working group. The latest editions of MapServer, ArcGIS server, and ArcIMS help provide this 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.1.0, 1.1.1, 1.3.0)
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 WMS 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 net result is that BGS, acting in the role of service provider, is serving five separate services (five separate service URLs).
Section last modified : 19 January 2010.
