"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

CGI Interoperability Testbed #2



Geological maps on the screen: Mapfeatures (classified as geological units) fron various servers viewable in (a) client as WMS'.

Use case 1: Mapping

Client asks for map. Server returns a map with default symbolisation. User can click on any graphic feature from one layer to retrieve at least an HTML presentation of the attributes of that feature which is consistent with the CGI model. (Client can request other formats than HTML if server supports them.) The types of features to be included must include at least one of geologic units, faults, contacts or boreholes.

Use case 1 storyboard


Use case 1 implementation requirements

  • WMS must be version 1.1 compliant.
  • WMS Server must provide a standard Capabilities document.
  • The document must provide the following layers
  • Will return a MappedFeature or Borehole

Mapping the use-case to the GeoSciML model

Note: This supports returning info about one graphic feature (point, line, polygon)

Layer type Feature types Portrayal rule Expected attributes
geometry symbolization
geologic units MappedFeature where the type of its specification property is GeologicUnit, LithologicUnit, etc ./shape default ./specification/GeologicUnit(purpose="instance")
faults MappedFeature where the type of its specification property is FaultSystem, Fault ./shape default ./specification/FaultSystem(purpose="instance")
contacts MappedFeature where the type of its specification property is Contact ./shape default ./specification/Contact(purpose="instance")
boreholes Borehole ./start default .

  • Each layer should have
    • name
    • title
    • abstract : describing what the layer will provide
    • LatLonBoundingBox
    • possible projections. Given the nature of the testbed, all servers MUST support geographic coordinates (EPSG:4326) and Mercator (EPSG:9804) (N.B. check epsg numbers)

  • WMS server MUST support GetFeatureInfo. WMS client shall allow the user to select a layer in the list that will be the 'active' layer, which means that this layer will be the context of GetFeatureInfo request.

  • The WMS Server MUST provide GetFeatureInfo result in at least:
    • text/html : return the GetFeatureInfo in HTML format.

  • If no INFO_FORMAT is specified, text/html is assumed by the server.

  • WMS client might provide a control to select the INFO_FORMAT (the format in which the result of the GetFeatureInfo will be returned). In the case that this control is not available, it must handle the default format of text/html


Use case 2: Selection

Select mapped features by specifying a geographic bounding box and download the most specific information available for each mapped feature as GeoSciML.

Use case 2 storyboard


Use case 2 implementation requirements and restrictions

  • We will only require bounding box to be specifiable by drawing a box in a graphic environment.
  • A mechanism for matching WMS layer names to the feature types they portray. (This is not necessary for use case 1 but when we want to go onto use case 2 we will want to know the feature types. However, this information is service by service and layer by layer specific and so rightfully belongs in the layer element of the WMS capabilities document.)
  • Will return a collection of GeologicFeatures or Boreholes * There should be a mechanism for relating a WMS layer to a related WFS URL (possibly this already exists in WMS GetCapabilities document; need to check). SimonCox will investigate which place in the GetCapabilities document is best to put this information and how to encode it.

There is an interesting discussion in SLD spec (02-070, section 6.5), regarding component WMS vs integrated WMS. The component WMS is defined as a rendering engine without any predefined layers. The WMS is invoked by providing a valid WFS/WCS source and a SLD. This model basically covers all 3 test case (if implemented sensus stricto).

case 1: get a rendering from a WFS (can be mixed TYPENAME, just have a SLD that handle it) with this SLD case 2: get the same WFS feature collection, just omit the rendering and use this BBOX case 3: same as 1, let's use different SLDs

This model eliminates the problem of linking the WMS and WFS because all WMS are really WFS queries (there a no predefined layers). Another interesting spin off, we could all use the same WMS engine -- the only thing we really have to do is to expose our WFS (I suspect the WMS engine will be terribly slow)

Is this what we are looking for ?

-- EricBoisvert - 04 Aug 2006

My reading of the WMS 1.1.1 spec and SLD 1.0.0 specs makes me think that this should be in the response to the optional DescribeLayer command which returns something like the below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE WMS_DescribeLayerResponse SYSTEM 
<WMS_DescribeLayerResponse version="1.0.0">
This relates the WMS layer name in the LayerDescription/@name attribute to one or more WFS feature types specified in the LayerDescription/Query/@typeName attributes. There can be more than one nested Query element when there is more than one feature type in the WMS layer. The address of the related WFS server is given in the LayerDescription/@wfs attribute or, in more modern versions in a LayerDescription/@owsURL attribute with LayerDescription/@owsType set to "WFS". SLD 1.0.0 Spec OGC doc 02-070 Annex B.

-- MarcusSen - 21 Jul 2006

Mapping the use-case to the GeoSciML model

Note: This usually returns info about more than one graphic feature (point, line, polygon)

Layer type Feature types Portrayal rule
geometry symbolization
geologic units GeologicUnit, LithologicUnit, etc (+) occurrence(s)/MappedFeature/shape default
faults FaultSystem, Fault (+) occurrence(s)/MappedFeature/shape default
contacts Contact (+) occurrence(s)/MappedFeature/shape default
boreholes Borehole start default

  • (+) Prefer purpose = "instance" rather than norm.

  • getFeature of type="gsml:GeologicUnit,gsml:LithologicUnit,gsml:LithodemicUnit" (*)
    • where at least one of the occurrence/MappedFeature/shape properties falls within bounding box
    • and report these properties: occurrence, composition, classification ... etc

N.B. some of the reported occurrences may fall outside the bounding box, but at least one must fall within

(*) Note: some implementations do not support schema-defined substitutability, so interoperability is likely best served by specifying all valid concrete types from a substitution group in both WFS Capabilities response and in the WFS client getFeature request.

(*) Note2: service should only return one of each, even if it does understand substitutability.

(*) Note3: We need to investigate and document which properties we return for each feature type and how deeply we represent the values in line. Bruce Johnson, Bruce Simons and Steve Richard will form the group to discuss this issue and place the proposed list here.


Use case 3: Symbolisation of geologic units

The user chooses to display mapped features representing geologic units, symbolized on the basis of age using the IUGS standard geologic age colour scheme, or on the basis of lithology using a CGI defined lithology colour scheme.

Use case 3 storyboard


Use case 3 implementation requirements

We will use the following very simple four lithology classes which we think is a lowest common denominator which everyone can manage. The shared SLD will be stored on the IUGS webpage as a static file.

Layer type Feature types Portrayal rule
geometry symbolization
geologic units GeologicUnit, LithologicUnit, etc occurrence(s)/MappedFeature/shape ./....../ControlledConcept
faults FaultSystem, Fault occurrence(s)/MappedFeature/shape XXX
contacts Contact occurrence(s)/MappedFeature/shape XXX
boreholes Borehole start XXX

Igneous (pinkish) FF66CC
Sedimentary (greenish) 00FF66
Metamorphic (purpleish) 9933CC
Unconsolidated (yellowish) FFFF99

For age we will use the IUGS 2004 age classification (http://www.stratigraphy.org/.) and colour scheme where the values in our data correspond to these and the testbed will illustrate the problems of not having an agreed vocabulary where our data do not correspond exactly to them. It is the service provider's prerogative to determine the mapping from the data source to the classification.

We also need to sort out the issue of which age property to use as there will be more than one in many cases (upper and lower and also different kinds of event age; metamorphic, genesis...)

I've uploaded a series of SLD for IUGS ages (with IUGS color schemes), depending on how the GeoSciML document is organised (If I understand SLD correctly)

These files are maintained by the BGS on the IUGS/CGI web site

-- EricBoisvert - 07/08 Aug 2006


Use case 4 (optional):

Select a subset of geologic unit mapped features on the basis of age or lithology and highlight them with the same highlight colour.

Use case 4 Storyboard


Use case 4 implementation requirements and restrictions

  • See use case 3
  • Highlight color will be 000000

Use Case 5:

Module for loading received GML into local databases

Long term future aspiration not for testbed 2.


Set up a CGI working group specifically for borehole to bring what testbed 1 borehole work achieved to the cgi schema. Current BGS/BRGM borehole work to be part of testbed 2 but not part of the testbed 2 schema (green classes) but able to validate within it (purple classes).


Agreed by CGI collaborators that all clients will be password protected.


XML Document Contents

See TestbedWFSProfile

schema validation

For test bed conformance testing of instance documents, some reference set of schema and a reference validatation tool need to be available. One possible solution is an online service to which an instance document could be sent and a validation report returned. Some existing examples:




I have produced a local version of the xmml/subversion/trunk directory structure with all the schema necessary to validate GeoSciML. The schema here validate with XMLSpy 2005 v. 3, but some testing with other validators (Stylus Studio) suggests that your results WILL vary depending on the validator used (also on random, unknown system state variables in your local environment). This package is in XmmlSVN:GeoSciML/trunk/Documents/LocalSchema.zip. Most of the instance documents in this package are validated against GeoSciML schema. The readme.txt in GeoSciML/1.1.0 in this zip archive documents modifications to GeoSciML schema for consistency with 1.1.0 EA UML model.

-- SteveRichard - 21 May 2006

Best Practice Suggestions

See TestBed2BestPracticeSuggestions

Content moved to a new page -- SteveRichard - 21 May 2006


(Key testbed contact from each participating organisation) :

GSC: EricBoisvert - map of canada scale: 1:5000000?

GSV: BruceSimons - piece of Victoria (possible 1:50k) or whole Victoria 1:1000000

GA: DalePercival 1:1,000,000 Surface Geology of Australia - Victoria. GeologicUnits and possibly Contacts and Faults. Client to be determined.

BGS: TimDuffy 625k Map of UK plus Loughborough sheet Solid and Drift (1:50k) plus approx. 5000 Loughborough boreholes with associated down hole interval logs plus a 10k piece from GSD of Strathmore (Scotland)

BRGM: JeanJacquesSerrano - some boreholes plus a map of France and 1:50K geological map (Nord Pas de Calais region)

USGS/NCGM: SteveRichard: Possible Arizona map 1:100000 30 by 60 degrees, possibly hosted by Dave Soller?

USGS/MRP: BruceJohnson: 1:5,000,000 bedrock unit map of USA, 1:5,000,000 faults and large dikes of USA, 1:2,500,000 geologic map of Alaska, Geologic terranes of the World, and Country outlines of the world are now available.

SGU: LarsStolen: National Bedrock Map 1:1 000 000 transformed into simple datasets.

  • fenn_cgi_litho lithostratigraphic units (polygon) WGS84
  • fenn_cgi_faultsystem faults (lines)
  • fenn_cgi_contact contacts (lines)

Decisions to take to testbed group coordinator:

  1. Request group to take this testbed 2 specification on (AGREED by Francois Robida BRGM chairman of CGI testbed group 13/09/2005). TimDuffy to act as liaison between testbed group and data modelling group.
  2. Request to add each testbed organisation key contact as above to testbed group (AGREED by Francois 13/09/2005).

Model and Schema

UML Model

See GeoSciMLModel

XML Schema

See GeoSciML1SchemaDiscussion

Schema patterns and profile

See TestbedWFSProfile

Tools (Servers)

These must be complex-property enabled. Many WFS implementations only support flat de-normalized views.

Tools (Possible Clients)


See TestBed2Success
Topic attachments
I Attachment Action Size Date Who Comment
GeochemScenarios.pptppt GeochemScenarios.ppt manage 432.5 K 25 Apr 2006 - 16:51 SimonCox Geochemistry testbed storyboard from SEE Grid
Storyboardforusecase1.pptppt Storyboardforusecase1.ppt manage 837.0 K 27 Apr 2006 - 21:15 MarcusSen Use case 1 storyboard
Storyboardforusecase2.pptppt Storyboardforusecase2.ppt manage 386.0 K 27 Apr 2006 - 21:16 MarcusSen Use case 2 storyboard
Storyboardforusecase3.pptppt Storyboardforusecase3.ppt manage 230.5 K 27 Apr 2006 - 21:18 MarcusSen Use case 3 storyboard
Storyboardforusecase4.pptppt Storyboardforusecase4.ppt manage 356.0 K 27 Apr 2006 - 21:20 MarcusSen Use case 4 storyboard
Testbed2UseCases.pptppt Testbed2UseCases.ppt manage 330.5 K 25 Apr 2006 - 16:21 SimonCox Storyboard mockup
sld_age_Feature.xmlxml sld_age_Feature.xml manage 113.4 K 08 Aug 2006 - 03:32 EricBoisvert more fixin
sld_age_mappedFeature.xmlxml sld_age_mappedFeature.xml manage 111.0 K 08 Aug 2006 - 03:33 EricBoisvert more fixin
Topic revision: r72 - 07 Apr 2011, MarcusSen

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).