Vector data exemplar (LAYER configuration)

4.3.1.4 Vector data exemplar (LAYER configuration)

The example file includes the following shapefile based layers:

UK bedrock geology classified by lithology, lithostratigraphy and age
UK superficial geology classified by lithology and lithostratigraphy.

These are typical of the sorts of layer expected for OneGeology but you may have slightly different theme layers and slightly different available classification schemes. Please consult on the OneGeology forum if you are uncertain about exactly what layers and classifications to serve.

The fields you will need to edit for each LAYER section are described below. The NAME must be unique for each layer. This is a short identifier used by WMS clients to select layers rather than being for human consumption. The OneGeology catalogue service requires that the NAMEs are unique within all the OneGeology layers we have decided some naming conventions as shown in the example. These are described explicitly in Section 2.1. (Note that MapServer does not allow more than 20 characters in a LAYER NAME.)

DATA should specify the name of your shapefile. The HEADER, TEMPLATE, and FOOTER values refer to files with snippets of HTML template which format the results of GetFeatureInfo requests when requested in text/html format. The examples have been written for the data fields in the example shapefiles; it should be straightforward for you to edit them to match the fields in your shapefiles. The PROJECTION section should specify the coordinate system that your data is actually in. This might not be EPSG:4326 if you have your data in some regional projected system. However, as most OneGeology clients will want to retrieve your data in the EPSG:4326 system we suggest it will be better for performance reasons to convert your data files to EPSG:4326 rather than have MapServer convert them on-the-fly in response to requests. See Appendix A for one way to do this with the tools bundled with MS4W.

LAYER
    NAME GBR_BGS_625k_BLT #Bedrock lithology
    TYPE POLYGON
    STATUS ON
    DATA bedrock625ll
    TRANSPARENCY 100
    TOLERANCE 0
    TOLERANCEUNITS pixels
    TRANSFORM TRUE
    DUMP TRUE
    PROCESSING “CLOSE_CONNECTION=DEFER“    
    HEADER “templates/bedrock_lithology_query_header.html”
    TEMPLATE “templates/bedrock_lithology_query_body.html”
    FOOTER “templates/bedrock_lithology_query_footer.html”    
    PROJECTION
      “init=epsg:4326”
    END

In the METADATA section you should edit the following values:

WMS_TITLE

the human readable layer name and must follow the conventions laid in Section 2

WMS_ABSTRACT

expands on the title with any extra information you feel would be useful.

WMS_SRS

These values specify which coordinate systems your WMS can supply the data in and MUST include at least EPSG:4326. Other coordinate systems are up to you; for example you may wish to include the EPSG:3857 (spherical mercator) coordinate system, which is used by several web mapping clients such as Bing Maps, Google Maps, and Yahoo maps.

GML_INCLUDE_ITEMS and WMS_INCLUDE ITEMS

These items will depend on the data fields in your shapefile and which ones you wish to make available by a GetFeatureInfo request. Items should be a comma separated list of field names. These should be the same as the fields included in the HTML templates above.It is optional to include any information here but obviously if you have fields with geological unit names or ages they would be useful to include.

WMS_METADATAURL_HREF and WMS_DATAURL_HREF

are supposed to contain URLs for web pages which describe the dataset used for the layer in more detail. It is possible that you may already have suitable web pages on your organization’s website, or you may wish to create suitable pages to be served by this same server. These URL’s give users of your WMS service quick and easy links back to your web pages that may describe your available data offerings in more detail. The differences between the metadataurl and dataurl are:

WMS_METADATAURL_HREF: the metadataurl must only link to a page which describes your layer data corresponding to either the TC211/ISO:19115:2003 or FGDC-STD-001-1998 metadata standards. See Section 2.7 of this cookbook for the core metadata required to be TC211/ISO:19115:2003 compliant
WMS_DATAURL_HREF: the dataurl is to be used when you have some layer metadata that doesn’t conform to either of these standards.

The UK geology layer examples point to some pre-existing web pages on the BGS website which were suitable so that you can get an idea of what you might use for your own data.

    METADATA
      OWS_TITLE “GBR BGS 1:625k Bedrock Lithology”
      OWS_ABSTRACT “GBR BGS 1:625k scale Bedrock Lithology”
      WMS_SRS “CRS:84 EPSG:27700 EPSG:3857 EPSG:4258 EPSG:4326”
      GML_INCLUDE_ITEMS “RCS_D”
      GML_FEATUREID “ID”
      WMS_INCLUDE_ITEMS “RCS_D”
      WMS_METADATAURL_FORMAT “application/xml; charset=UTF-8“
      WMS_METADATAURL_HREF “http://.../geonetwork/srv/en/csw?SERVICE=CSW&
        VERSION=2.0.2&REQUEST=GetRecordById&ID=ac9f8250-3ae5-49e5-9818-d14264a4fda4&”
      WMS_METADATAURL_TYPE “TC211”
      OWS_DATAURL_HREF “http://www.bgs.ac.uk/discoverymetadata/13480426.html”
      OWS_DATAURL_FORMAT “text/html”
      OWS_KEYWORDLIST “OneGeology,bedrock,lithology,continent@Europe,
      subcontinent@Northern Europe,geographicarea@United Kingdom,geology,
      dataprovider@British Geological Survey,DS_TOPIC@geoscientificInformation,
      serviceprovider@British Geological Survey,DS_DATE@2011-06-15”
    END

The CLASS related items are the most complicated. These sections are setting up the legend and colour scheme of your map polygons so you will need a separate item for each rock type or lithology you have in your data. This will depend on your data and which field in your shapefile you are going to use for colouring the map. The example below specifies that the RCS_D field will be used for specifying which colour to use with the CLASSITEM VALUE. Then for each CLASS section the EXPRESSION specifies the value of RCS_D this colour will apply to and the COLOR and BACKGROUNDCOLOR give the respective RGB colour values. It is likely that creating a CLASS for all your values would be very time-consuming to do manually. If you already have ArcView and an ESRI .avl legend file you can automatically convert this to the MapServer format using the utility described in Appendix C or if you have ArcGIS and .mxd or .lyr files you can use the utility described in Appendix C.

    
  CLASSITEM ‘RCS_D’
    CLASS
      NAME ‘ANORTHOSITE’
      EXPRESSION ‘ANORTHOSITE’
      #RASTERFILL_STYLE_SOLID
      STYLE
        COLOR 237 237 237
        BACKGROUNDCOLOR 255 255 255
      END #style
    END #class

#... more classes needed to assign colours

# for each value of RCS_D

Colour codes for the lithostratigraphical and lithology layers are specific to the British Geological Survey, you should use the codes used by your geological survey. However, for OneGeology it has been agreed, where possible, to serve a chronostratigraphic age layer using the new IUGS 2009 colour scheme (https://www.seegrid.csiro.au/wiki/pub/CGIModel/GeologicTime/ISChart2009.pdf). This will give some form of harmonization between the different chronostratigraphic layers served by the contributing geological surveys and this is only possible where such an internationally agreed scheme exists. In this case the British Geological Survey had to refine, re-allocate, and ‘map’ its internal ages to fit the IUGS 2009 one. The file ‘ICSClasses.txt’ contains a full list of names and CLASS definitions for the appropriate colours for all the IUGS 2009 colours. In the map file we have commented out the terms that are not actually used in the BGS map; please do the same for your map.

3 star accreditation requirement

For a 3 star accredited service, where an age harmonization layer is defined, it must be based on the IUGS standards.
If you wish you are encouraged to go a step further and follow the GeoSciML-Portrayal schema, which would allow your age service to be queried and re-symbolized using CGI URI codes.

See (Section 7) for details on how to enable GeoSciML-Portrayal in your service.

You may notice that in two of our example layers we have defined some ‘DUMMY’ classes. This is a hack to work around a bug we found with Google Earth. It should only affect you if you have layers with fewer than 16 classes. If this is the case then read the comments in the map file for an explanation and add some dummy classes to your own layers so that there are at least 16.

Also note that the example CLASS definitions do not have any polygon borders (no OUTLINECOLOR directive). This is important as the different scales of viewing to be used within OneGeology mean that border lines would often obscure the polygons themselves.

You will also notice that we do not currently recommend enabling some capabilities in a WMS service such as setting Transparency (this can upset some WMS viewing clients and also other clients can allow the user to set the level of transparency interactively) and ScaleHint (this can upset several clients and make your service difficult to use in them).

Section last modified: 03 October 2014

Back | Next