ecp-2007-geo-317001 onegeology-europe wp5: · pdf file- to provide a standard access to...

OneGeology-Europe : WP5 – 1GE Data model

31/08/2009 of 84

ECP-2007-GEO-317001

OneGeology-Europe

WP5: Informatics specification, data model, interoperability and standards

D5.1 : Documented data model, thematic profile and

guidance for GeoSciML

Executive summary

This document presents the OneGeology-Europe (1GE) data model to be used by European Geological surveys to deliver geological data. The 1GE data model takes into account requirements from WP2, WP3, and WP9 but also requirements from the INSPIRE data specification in preparation for the future task of defining the data model for the “Geology” theme of INSPIRE. The OneGeology-Europe data model is a profile of the GeoSciML data model as this one is the result of the work done for several years by Geological Surveys across the world (in the CGI-IWG of the IUGS

1) to share geological data and is also in line with the technical requirements

defined by the INSPIRE Data Specification Drafting Team. Although the scope of OneGeology-Europe data model is geology, some information is given about existing data models related to other data themes such groundwater, mineral occurrences, landslides. Deliverable number D5.1

Dissemination level Public

Delivery date 31rd

August 2009

Status Final Version

Author(s) WP5 Leader Jean-Jacques Serrano (BRGM) WP5 Team John Laxton (BGS), Lars Kristian Stolen (SGU), Horst-Günter Troppenhagen (BGR), Robert Tomas (CGS), Lucie Kondrova (CGS), Jorgen Tulstrup (GEUS), Carlo Cipolloni (ISPRA), Pierre-Yves Declercq (GSB), Urszula Stephen (PGI), Aleksandra Lukasiewicz (PGI)

This project is funded under the eContentplus programme

2

A multilingual Community programme to make digital content in Europe more accessible, more usable and exploitable

1 Interoperability Working Group of the Commission for the Management and Application of Geoscience

Information – International Union of Geological Sciences. 2 OJL 79, 24.3.2005, p.1


31/08/2009 of 84

Table of content

1 Introduction ........................................................................................................................ 4

2 Analysis of existing data models within the 1GE scope .................................................... 5

2.1 Identification of existing data models within the 1GE scope..................................... 5

2.1.1 Scope of OneGeology-Europe data model......................................................... 5

2.1.2 List of existing data models ............................................................................... 6

2.2 GeoSciML description ............................................................................................... 7

2.2.1 Purpose of the GeoSciML model ....................................................................... 7

2.2.2 Scope of the model ............................................................................................. 8

2.2.3 Overview of the model ....................................................................................... 8

2.3 Groundwater data model description ....................................................................... 25

2.4 Mineral Occurrence data model description ............................................................ 25

2.5 Landslides data model description ........................................................................... 26

2.6 Earthquakes data model description......................................................................... 27

2.7 Borehole data model description.............................................................................. 27

2.7.1 Boreholes in GeoSciML................................................................................... 27

2.7.2 Boreholes in BoreholeML................................................................................ 28

3 INSPIRE requirements for data specification .................................................................. 29

3.1.1 Available INSPIRE documents to help data specification activity.................. 29

3.1.2 INSPIRE Data specification document for each theme ................................... 29

3.1.3 INSPIRE requirements for data modeling ....................................................... 29

4 WP2 requirements ............................................................................................................ 30

4.1 User needs summary for data modeling................................................................... 30

4.2 Proposal to address WP2 requirements .................................................................... 30

5 WP3 requirements ............................................................................................................ 31

5.1 General review of WP3 requirements ...................................................................... 31

5.1.1 Requirements for Geologic Units..................................................................... 32

5.1.2 Requirements for Geologic Contacts and Structures ....................................... 32

5.1.3 Requirements for Common Vocabularies ........................................................ 32

6 WP9 requirements ............................................................................................................ 33

6.1 Requirements for Geologic Units and Structures for “high resolution maps” ......... 33

6.2 Need for Vocabularies.............................................................................................. 33

7 Proposal to fit requirements from WP2, WP3, WP9........................................................ 34

7.1 Proposal to fit requirements for Geologic Units ...................................................... 34

7.2 Proposal to fit WP3 requirements for Geologic Structures...................................... 36

7.3 Proposal to fit requirements for Vocabularies.......................................................... 36

7.4 Conclusion................................................................................................................ 36

8 Guidelines for a 1GE profile ............................................................................................ 37

8.1 GeoSciML elements selected for OneGeology-Europe ........................................... 37

8.1.1 For Geologic units ............................................................................................ 38

8.1.2 For Geologic Structures ................................................................................... 40

8.2 Description of GeoSciML elements (feature types and attributes) .......................... 40

8.2.1 For Geologic units ............................................................................................ 40

8.2.2 For Geologic Structures ................................................................................... 47

8.3 Documentation, UML data model and XSD files for GeoSciML............................ 48

9 Conclusion and next steps ................................................................................................ 50


31/08/2009 of 84

10 ANNEXE A – GeoSciML and INSPIRE..................................................................... 51

11 ANNEXE B – Examples of mapping to GeoSciML.................................................... 60

11.1 Example from BRGM (France)................................................................................ 60

11.1.1 Lithology .......................................................................................................... 60

11.1.2 Age ................................................................................................................... 64

11.1.3 Genetic category............................................................................................... 65

11.1.4 Event process and Event environment ............................................................. 65

11.2 Example from SGU (Sweden).................................................................................. 66

11.2.1 Results of the mapping exercise....................................................................... 67

11.2.2 Comments......................................................................................................... 68

11.3 Example from Czech and Slovak Geological Surveys............................................. 69

11.3.1 Process of the mapping into GeoSciML .......................................................... 69

11.3.2 Used technology............................................................................................... 72

11.4 Example from ISPRA (Italy).................................................................................... 72

11.4.1 Lithology .......................................................................................................... 72

11.4.2 Age ................................................................................................................... 75

11.4.3 Genetic category............................................................................................... 76

11.4.4 Event-Process ................................................................................................... 76

11.4.5 Event-Environment .......................................................................................... 77

11.5 Example from BGS (UK)......................................................................................... 77


31/08/2009 of 84

1 Introduction

To insure interoperability among geological data providers across Europe to deliver

geological maps and data to the users, the OneGeology-Europe (1GE) project has to

address two main issues:

- to provide a standard access to geological data, regardless of how each provider

manages these data,

- to define a common language to exchange geological data. This language has two

complementary facets: the structure (the data model), and the semantics (related to

the content, mainly addressed by defining common vocabularies).

WP5 addresses the first issue, selecting standards to use, and WP6 will implement the

services according to these selected standards.

WP5 also addresses the second issue, defining the 1GE data model, according to

requirements provided by WP2, WP3 and WP9. To complete the 1GE data

specifications, WP3 deals with the content, defining common vocabularies. A specific

issue is also addressed by WP3, the geometric harmonisation, as geological bodies do

not take care about borders, but this does not impact the data model.

Before starting the 1GE data model development, the scope was clearly defined, and

existing data models were analysed. The main input is the GeoSciML data model,

developed since 2003 by the Interoperability Working Group (IWG) of the IUGS

Commission for the Management and Application of Geoscience Information (CGI).

The active participants are Geological Surveys: BGS (United Kingdom), BRGM

(France), CSIRO (Australia), GA (Australia), GSC (Canada), GSV (Australia),

APAT/ISPRA (Italy), JGS (Japan), SGU (Sweden) and USGS (USA).

GeoSciML is based on the GML standard (Geographic Markup Language, ISO 19136)

and the Observations and Measurements standard (ISO project 19156). The CGI/IWG

released a stable version (GeoSciML version 2.0) in December 2008.

The project decided to build the 1GE data model as a profile of GeoSciML (using

selected GeoSciML elements to meet 1GE requirements). A detailed description of

GeoSciML is presented in chapter 2.2

Relationship with INSPIRE Data Specification

As the European INSPIRE directive also has an important requirement to develop a

common geological data model for the “Geology” data theme, GeoSciML was analysed

against data specification requirements defined by INSPIRE (in the D2.5 Generic

Conceptual Model and D2.7 Rules for exchange spatial data documents) (cf annexe A).

Even though the 1GE data model scope is geology, some existing data models related to

other INSPIRE data themes were also analysed, and a brief summary is presented. This

should be a useful input for the work of the future INSPIRE Thematic Working Groups.


31/08/2009 of 84

Relationship with CGI/IWG about GeoSciML

The use of GeoSciML by over 20 European Geological Surveys in 1GE will improve

the “quality” of the data model and proposed enhancements will be discussed with the

CGI/IWG to update GeoSciML 2.0 (the work to release the new version 3.0 will start in

September 2009, during a meeting in Québec). These enhancements will cover the data

model itself (WP5 inputs) and the vocabularies (WP3 inputs).

Content of this document

- Chapter 2 analyses existing data models, with a specific focus on GeoSciML,

- Chapter 3 analyses requirements from INSPIRE to build a data model compliant to

INSPIRE rules,

- Chapters 4, 5 and 6 analyse requirements respectively from WP2, WP3 and WP9

- Chapter 7 defines the proposal to implement the requirements using GeoSciML,

- Chapter 8 defines the 1GE profile, a set of selected GeoSciML elements with their

definition,

- Chapter 9 provides a conclusion and explains the next steps within the project

(mainly for the implementation phase by the European Geological Surveys),

- Annexe A presents the detailed comparison between GeoSciML and INSPIRE

requirements for data models,

- Annexe B presents examples of mappings between national data bases and

GeoSciML.

2 Analysis of existing data models within the 1GE scope

2.1 Identification of existing data models within the 1GE scope

2.1.1 Scope of OneGeology-Europe data model

The scope of the 1GE data model is defined in the “Description of work”, but as the

project has also to contribute to INSPIRE, the scope could be completed by proposals

provided from the “D2.3 INSPIRE Themes definition” for Geology (chapter 6.4).

From the “Description of work”:

“To define a robust data model, schema and markup language for core geological

spatial data, which is OGC compliant and based on standards, documented and

deployed widely across Europe.”

“Identify and evaluate existing spatial and geoscience data models. Input results to

develop and refine the GeoSciML geoscience data model and markup language and

associated standards”

From the “D2.3 INSPIRE Themes definition” for Geology:

D2.3 Description: “Geological information provides basic knowledge about the physical

and chemical composition and the genesis of the underground, in particular on the


31/08/2009 of 84

properties of the rocks and sediments (age, petrography, genesis and tectonic elements

...) and their structure.”

“Groundwater is by geologists commonly treated as a geological resource. Groundwater

in aquifers mainly depends on the geological structure of the subsurface (rock type).

Thus it is an integral, inseparable part of Geology. It is mentioned in the INSPIRE

Annexe as aquifers. However, as being part of the hydrological cycle, it might be part of

Hydrography as well.”

Scope of OneGeology-Europe data model

The 1GE data model has to define:

- Geologic Units with Earth Material if needed,

- Geologic Structures,

but not to take into account:

- Geophysical data,

- Geochemical data

- Earthquakes,

- Landslides,

- Mineral resources,

- Geological heritage

- Groundwater.

2.1.2 List of existing data models

Even if only GeoSciML is within the scope of 1GE, we provide here a summary of

other data models for geosciences that could be a useful input for the INSPIRE

Thematic Working Groups who will have to define the European data models for data

themes: Geology, Mineral Resources, Soil, Natural Hazards, and Energy resources.

Geology

GeoSciML GeoSciML v2 is primarily concerned with "interpreted" geology (units,

structures, etc), but links to external schemas for the descriptions of

observational data

http://www.geosciml.org/

Ground water

GroundWaterML Extension of GeoSciML for GroundWater, using also O&M and

SensorML

http://ngwd-bdnes.cits.rncan.gc.ca/gwml

Landslides

Landslides data model GML application schema using O&M and SensorML

https://www.seegrid.csiro.au/twiki/bin/view/Geohazards/LandSlides

Earthquakes

QuakeML Representing seismological data (but no use of ISO/OGC standards)

https://quake.ethz.ch/quakeml/QuakeML

Mineral Occurences

Mineral occurences GGIPAC Mineral Occurrence Model


31/08/2009 of 84

https://www.seegrid.csiro.au/twiki/bin/view/Xmml/MineralOccurrences

Geotechnics/GeoEnv.

DIGGSML Data Interchange for Geotechnical and GeoEnvironmental Specialists

http://www.diggsml.com/

Boreholes

BoreholeML Developed by German Geological Surveys

http://www.infogeo.de/infogeo/borehole/doc/boreholeMLV2.doc

2.2 GeoSciML description

This description comes from the GeoSciML cookbook “How to map data to GeoSciML

version 2.0” (John Laxton, BGS). It is much more detailed than for the other data

models as GeoSciML will be used to build the 1GE profile (a subset of GeoSciML

classes to fit 1GE requirements).

2.2.1 Purpose of the GeoSciML model

In order to ensure the interchange of information there has to be agreement on the

nature and structure of the information to be interchanged. The simplest way of

achieving this would be if all geoscience data providers shared a common database

structure. However, because data providers already have their own database

implementations, and the information gathered and held by different providers is not

exactly the same, this option is not possible. The solution is to agree a common

conceptual data model, to which data held in existing databases can be mapped. Such a

data model needs to identify the objects being described (eg ‘faults’), their properties

(eg ‘displacement’) and the relations between objects (eg ‘faults are a type of Geologic

Structure’). Such a model can be described graphically using Universal Modeling

Language (UML), an ISO standard.

Having agreed a conceptual data model it needs to be mapped to an interchange format.

The GeoSciML application is a standards-based data format that provides a framework

for application-neutral encoding of geoscience thematic data and related spatial data.

GeoSciML is based on Geography Markup Language (GML – ISO DIS 19136) for

representation of features and geometry, and the Open Geospatial Consortium (OGC)

Observations and Measurements standard for observational data. Geoscience-specific

aspects of the schema are based on a conceptual model for geoscience concepts which

includes packages for GeologicUnit, GeologicStructure, EarthMaterial, and Borehole

information. Development of controlled vocabulary resources for specifying content to

realize semantic data interoperability is underway.

Intended uses are for data portals publishing data for customers in GeoSciML, for

interchanging data between organizations that use different database implementations

and software/systems environments, and in particular for use in geoscience web

services. Thus, GeoSciML allows applications to utilize globally distributed geoscience

data and information.


31/08/2009 of 84

GeoSciML is not a database structure. GeoSciML defines a format for data interchange.

Agencies can provide a GeoSciML interface onto their existing data base systems, with

no restructuring of internal databases required

2.2.2 Scope of the model

Developing a conceptual data model for geoscience is a major piece of work and in the

current phase of development the scope has been restricted to those geoscience objects

which form the main components of a geological map, as well as boreholes and field

observations.

The GeoSciML model will never provide definitions of everything in geoscience

because other groups may have governance of particular areas of geoscience. The IWG

aims to coordinate with the work of these other groups.

GroundwaterML is an example of a derived implementation of GeoSciML. It is also the

first official collaboration between GeoSciML and an external exchange model group.

MineralOccurrences is an example of an inherited implementation of GeoSciML. It is

being developed by the Australian Government Geologists Information Committee

(GGIC) as a model to deliver mineral occurrences information as a WMS/WFS.

Australian State, territory and federal organizations presently govern the model.

GeoSciML has not got a clearly defined ultimate limit to its scope. It has been

developed primarily by Geological Survey Organisations (GSOs) to assist them in the

interchange and delivery of their data, although it has always been envisaged that it

would be adopted by other geoscience data providers. GeoSciML has been developed in

the first instance to handle the interpretative information shown on geological maps, as

this is GSOs most widely used data set, but it also handles some of the data underlying

the map. The extent to which the need to exchange other types of geoscience data will

be met by extending GeoSciML, as opposed to using standards developed elsewhere,

will depend on what external standards are developed. GeoSciML will always aim to

adopt external standards where possible and GeoSciML will only be extended where no

such standards exist or are being developed by other governance bodies.

2.2.3 Overview of the model

There are twelve distinct packages in the GeoSciML data model, and in this section the

UML of each will be shown and the key points of each identified. The relationships

between the packages will also be identified.


31/08/2009 of 84

Geologic Feature:

Figure 1: Summary UML diagram for the Geologic Feature package

A MappedFeature can be considered an occurrence, such as a polygon on a geologic

map, of a real world GeologicFeature the full extent of which is unknown. It is

independent of geometry, so the same GeologicFeature can have different

MappedFeature instances representing mapped polygons at different scales or a

modelled volume, for example. Each MappedFeature, however, can represent only one

GeologicFeature.

A mandatory property of GeologicFeature is ‘purpose’ which states whether the

GeologicFeature is an instance or normative description. On published geologic maps,

for example, it is generally the case that normative GeologicUnits are shown, for which

a standard description is given in a StratigraphicLexicon. Survey scale, or field, maps

on the other hand may describe unclassified instances of GeologicUnits.

The observationalMethod properties of both MappedFeature and GeologicFeature

enable the distinct methodologies for observing each of these to be recorded. For


31/08/2009 of 84

example a MappedFeature might be observed through field observation (mapping)

while the normative GeologicFeature it is an occurrence of may have been observed

(defined) through summarising published descriptions.

Each MappedFeature is associated with a SamplingFrame that indicates the spatial

reference frame within which the MappedFeatures have been observed, such as a

surface of mapping or a borehole.

A GeologicFeature can be either a GeologicUnit or GeologicStructure.

The age of GeologicFeatures is described in terms of GeologicEvents. This can either

be as a single GeologicEvent giving a preferredAge for the GeologicFeature, or as a

series of one or more GeologicEvents describing the geologicHistory of the

GeologicFeature.

The relationship between GeologicFeatures can be described using

GeologicFeatureRelation. Relationships are described from a source to a target - for

example a source GeologicFeature might be an intrusive igneous rock body which could

point to a target indicating the host rock body. In this case the ‘relationship’ attribute

would be 'intrudes'. Other appropriate relationship attributes might include: overlies,

offsets, crosscuts, folds, etc.


31/08/2009 of 84

Geologic Unit:

Figure 2: Summary UML diagram for the Geologic Unit package

A GeologicUnit is a notional unit, complete and precise extent of which is inferred to

exist. Spatial properties are only available through association with a MappedFeature.

GeologicUnits can be formal units (i.e. formally adopted and named in the official

lexicon), informal units (i.e. named but not promoted to the lexicon) and unnamed units

(i.e. recognisable and described and delineable in the field but not otherwise

formalised).

Geologic units have no specialisations, the type of GeologicUnit being defined by the

geologicUnitType property. This means that there is no control, through the model, of

the required properties for any particular geologicUnit type. For example a lithologic

unit logically must have a composition value, but this constraint can only be enforced

by applications using GeoSciML.

A GeologicUnit can be classified with a ControlledConcept. The ControlledConcept can

be a normative description of a GeologicUnit, defined in a StratigraphicLexicon for

example

GeologicUnitPart allows for composite geologic units, made up of other geologic units,

to be described. This can be used for formal stratigraphic hierarchies as well as informal

relationships.

The composition of a GeologicUnit is described using CompositionPart. A

GeologicUnit can have a single CompositionPart describing the entire unit, in which


31/08/2009 of 84

case the ‘proportion’ property would be ‘only_part’ or 100%, or it can be made up of

several CompositionParts with the relationship of each to the whole GeologicUnit

described by the ‘role’ property (e.g. vein, interbedded constituent, layers, dominant

constituent). The lithology is described using a lithology term (eg ‘conglomerate’)

drawn from an EarthMaterial vocabulary, but can in addition have a specific

EarthMaterial description using the ‘material’ property to provide more detailed

information about the lithology of the particular GeologicUnit.

The MetamorphicDescription, PhysicalDescription, WeatheringDescription and

BeddingDescription data types allow the recording of certain specific properties of

GeologicUnits. It is appreciated that the properties included, particularly in the case of

PhysicalDescription, are a subset of those which may be required. Additional properties

may be added in future versions of the model in light of user requirements.

Earth Material:

Figure 3: Summary UML diagram for the Earth Material package

The EarthMaterial package allows for the description of naturally occurring substances

in the earth. These substances can be either discrete components, such as a specific type

of mineral, or CompoundMaterials built up from either discrete components or other

CompoundMaterials. At present RockMaterial is the only type of CompoundMaterial

modelled, and this includes both consolidated and unconsolidated materials.

A CompoundMaterial can be described in terms of its ConstituentParts, each of which

has a role and a proportion property to allow, for example, for the description and

relative abundance of the framework and matrix in a rock such as oolitic limestone. The

description of a CompoundMaterial can be enhanced using the


31/08/2009 of 84

ParticleGeometryDescription which provides additional properties relating to particle

geometry such as size and shape.

The MetamorphicDescription, PhysicalDescription and FabricDescription data types

allow the recording of certain specific properties of RockMaterials. It is appreciated that

the properties included, particularly in the case of the PhysicalDescription, are a subset

of those which may be required. Additional properties may be added in future versions

of the model in light of user requirements. FabricDescription is distinguished from

ParticleGeometryDescription on the criterion that ParticleGeometryDescription is

preserved if a CompoundMaterial is disaggregated, while FabricDescription is not

defined if the material is disaggregated.

Geologic Structure:


31/08/2009 of 84

Figure 4: Summary of UML diagram for the Geologic Structure package

The Geologic Structure package models most types of geologic structure. Primary

sedimentary and igneous structures, as well as tectonic structures, are included. Many of

the structural properties concern orientation measurements and specific orientation data

types are used for recording these.

ShearDisplacementStructures include both Faults and FaultSystems, with the latter

described in terms of their component Faults. The DisplacementValue can be described

both as a single totalDisplacement for the structure, and as a series of

incrementalDisplacements each associated with a particular DisplacementEvent. The

DisplacementValue is recorded in terms of its SeparationValue and NetSlipValue and,

optionally, as SlipComponent vectors. Physical properties, such as porosity and

permeability, can be recorded for ShearDisplacementStructures.

Both Folds and FoldSystems are modelled, the latter described in terms of their

component Folds. Foliation is modelled and includes Layering.

Contacts are included as a type of Structure and the BoundaryRelationship between the

GeologicUnits either side of the Contact can be described along with their descriptive

properties.


31/08/2009 of 84

Geologic Age :

Figure 5: Summary UML diagram for the Geologic Age package

GeologicAge is defined in terms of GeologicEvents which, in addition to age, may have

information about the eventEnvironment (the physical setting within which a

GeologicEvent takes place) and the eventProcess (a function that acts on one geologic

entity to produce another geologic entity at a later time) recorded.

GeologicEvents record the age and history of GeologicFeatures. DisplacementEvents

are the particular type of GeologicEvents associated with ShearDisplacementStructures.


31/08/2009 of 84

Boreholes and observations:

Figure 6: Summary UML diagram for the Boreholes & Observations package

Boreholes are modelled as a special type of SamplingCurve feature but borehole logs

can be described in two ways in the GeoSciML model – either as a series of

Observations or as a series of logElements which associate to MappedIntervals.

MappedIntervals are a type of MappedFeature and in this approach a borehole can be

considered as being akin to a linear geological map. The GeoSciML Boreholes and

Observations package re-uses standard components from the OGC Observations and

Measurements package.

A borehole is a feature whose median axis is a curve. Related observations and

measurements are made on points or intervals at depths measured from the collar along

the borehole curve. Observations may concern, for example, lithology, stratigraphy


31/08/2009 of 84

(category results), porosity, geophysical logs data, and ore-grades (numerical results). In

the case of holes with non-constant diameter, the variation of the diameter may also be

described as a log.

The shape of the boreholes (median axis of the borehole) is a 3D curve, which in the

simplest cases may be vertical and straight, but is commonly deviated, and often not

straight. The axis-shape may be described by means of another log known as the

“survey” (3-D direction as a function of depth) which may be converted (“de-

surveyed”) to obtain the shape in an x-y-z reference frame.

A borehole is associated with one or more domain features which it samples: for

instance, the GeologicalUnit intersected by the borehole. A borehole may also be

associated with related sampling features. This allows a set of boreholes to be grouped

as a campaign, or specimens to be associated with boreholes, boreholes with mines, etc.

While boreholes may carry various kinds of observation, in a geological mapping

context, lithology logs are a key information type. There are two ways to describe these:

1. The lithology log is reported as the result of a related observation in which the

association points from the borehole sampling frame to the observations made

within that sampling frame. This point of view is natural when comparing

multiple logs of different properties.

2. The lithology log is a collection of MappedIntervals (i.e. occurrences of

GeologicUnits) whose sampling frame is a sampling curve describing the

borehole – i.e. classification-centric. In this view the association points from

the borehole sampling frame to the MappedIntervals. This point of view is

natural when comparing a borehole log with other representations of the same

property, perhaps sampled in a different frame (e.g. map or section).

When to use which approach?

1. The first approach (borehole observations) is important during observation/data-

collection and for re-examination through the lens of an observational campaign.

2. The second approach (mapped features) is important after interpretation, and is

used later on during compilation.

With the second approach, it is highly convoluted to also include measurements of

continuously varying properties, such as ore-grades, porosity, etc. Hence, the first

approach is recommended when it is required to compare geologic features (e.g. units)

and ore-grade within a hole. However, the second approach is more convenient to

compare a geological interpretation from a borehole with a 2-D or 3-D model described

as a set of mapped features (i.e. a geologic map).

Many measurements, such as magnetic susceptibility, could be recorded either as a

property of the GeologicUnit specifying the MappedInterval or as an Observation. If the

borehole has been divided into MappedIntervals, and the measurement has been made

for that MappedInterval specifically to describe a property of the GeologicUnit

specifying the MappedInterval, then it should be recorded as a property of the

GeologicUnit. If on the other hand the measurement has been made for a borehole

interval defined solely for sampling purposes (eg at regular intervals down the borehole)

then it should be recorded as an Observation.


31/08/2009 of 84

Geological observations are not only made in boreholes and SamplingFeatureCollection

is the class to use for representing geoscience field data collected at an outcrop, e.g.

geologic unit descriptions, fault description, contact description, structural

measurements, specimens. SamplingFeatureCollection might also be used to represent

dredge hauls, measured sections, and other sorts of sampling features with multiple

kinds of associated observations.

Geologic Relation:

Figure 7: Summary UML diagram for the Geologic Relation package

GeologicRelations are typed, directed associations between geologic objects. They can

represent any of a wide variety of relationships that can exist between two or more

Features or other entities. GeologicRelations are likely to be of most use where

specialisations have been developed.

The GeologicFeatureRelation class is a subtype that is used to define relationships

between geologic features, ie. structure-structure, unit-unit, and structure-unit

relationships. Appropriate relationship attributes might include: intrudes, overlies,

offsets, crosscuts, folds, etc. Both the ‘Source’ and ‘Target’ have a role in the

relationship. Where an igneous unit intrudes a sedimentary unit, the geological


31/08/2009 of 84

relationship is ‘intrudes, the intruded sedimentary unit has the role ‘host’, and the

igneous unit has the role ‘intrusion’

A special type of GeologicFeatureRelation is the BoundaryRelationship which defines

the two GeologicUnits that bound a Contact.

Fossil:

The GeoSciML Fossil package is not attempting to model taxonomy. ‘Organism’ is a

broad class to represent any living or once living thing and can be classified using a

vocabulary of ControlledConcepts. This vocabulary could be a full taxonomy for

fossils. Fossils have a limited role in the GeoSciML model and are modelled only in

their role as types of GeologicStructure, either TraceFossils or FossilMolds.

CGI Values:

The CGI_Value package defines two different data types of particular relevance to geoscience:

generic values and geometric values.

Figure 8: Summary UML diagram for the Generic Values package

The generic values model (Figure 8) provides a way of encoding ‘literal’values, both

textual and numeric, which have uncertainty and may be a range. These structures are

designed to capture value descriptions as conventionally recorded by geologists. They

are required if the value you wish to record has a qualifier, such as ‘rare’ or

‘approximate’; where it can be either a single value or a range; where you wish to

record the uncertainty of a numeric value; or where a value or range can contain either

text or numeric values or a combination of both.


31/08/2009 of 84

Figure 9: Summary UML diagram for the Geometric Values package

The geometric values model (Figure 9) enables the description of the planar or linear

orientation of a GeologicFeature. Geometric values are particularly used in the

GeologicStructure package. For PlanarOrientation values differing measurement

conventions (eg right hand rule) can be used and recorded, as can the polarity (upright

or overturned) of the feature being measured. LinearOrientations may have an

orientation in 3D space, described by trend and plunge, along with a direction and

magnitude.


31/08/2009 of 84

Vocabularies:

Figure 10: Summary UML diagram for the Vocabulary package

The specification of a GeologicVocabulary is derived as a sub-type from the ISO19136

AnyDictionary definition. A StratigraphicLexicon is defined as a sub-type of

GeologicVocabulary. A GeologicVocabulary contains members which may be either

ControlledConcepts or VocabRelations.

At its simplest a ControlledConcept will have a name and, commonly, a description. A

ControlledConcept can have several names, for example in different languages, and can

be defined using a prototype. For example, most geological maps do not have

descriptive information about each individual polygon, rather they have a key, usually

related to a StratigraphicLexicon, which provides a standard (prototype) definition and

description. A prototype can be any type of entity, but most commonly will be a


31/08/2009 of 84

GeologicUnit, GeologicStructure, or EarthMaterial instance which exemplifies the

concept. The type of the entity used as a prototype for a ControlledConcept must be

consistent with the intention of the concept. GeologicFeature and EarthMaterial

prototype definitions follow the same pattern as described for these feature types in

sections 3.2.1 and 3.2.3 above, but the ‘purpose’ property should be set to

‘definingNorm’ to distinguish prototype descriptions from instance descriptions.

VocabRelations enable the relationship between ControlledConcepts to be described

and can be used to implement thesaurus type relationships like 'broader than', 'narrower

than', 'related term', and 'synonym'. The ‘role’ property specifies the nature of the

relationship between the source ControlledConcept and the target ControlledConcept,

read as 'source' - 'role' - 'target' (eg metasediment broader than metalimestone).

The Vocabulary package is likely to be replaced at some point by more suitable

ontology models, but these are not yet available.


31/08/2009 of 84

Metadata :

Figure 11: Summary UML diagram for the Metadata package


31/08/2009 of 84

The GeoSciML Metadata package shows the metadata links from various GeoSciML

classes. GeoSciML refers to the (externally maintained) ISO 19115 metadata package

(MD_Metadata). Metadata can apply to an individual feature, for example a particular

map polygon; a dataset, for example a map sheet; or a series, for example all 1:50k

scale bedrock geology maps. Pending GeoSciML migrating to GML v3.2, the XML

Schema contains a stub schema representing the actual metadata elements. As well as

metadata referring to individual GeoSciML classes, metadata can be provided

describing the collection of information being delivered in response to a particular WFS

call.

Collection:

Figure 12: Summary UML diagram for the Collection package

The GSML feature is a container for the information to be sent in response to a WFS

request. The GSML container can hold, as members, any of the types of feature in the

GSMLitem union class which includes all of the GeoSciML classes. In the future, sub-

types of the GSML container may be required to define the scope of information

returned in response to particular types of WFS request.

Metadata can be provided about the collection. This is distinct from the metadata

describing items within the collection, which is documented in section 3.2.11.

In most cases wfs:FeatureCollection should be used in preference to GSML. GSML is

useful when the collection of information being sent does not comprise features, such as

a GeologicVocabulary.


31/08/2009 of 84

2.3 Groundwater data model description

GWML (Groundwater Markup Language) is an exchange format based on GML

(Geography Markup Language). The model covers description of hydrogeologic units,

both groundwater properties and geological properties. It also covers water quality and

quantity and groundwater exploitation artifacts (eg. wells).

GWML is an extension of GeoSciML. Therefore, GWML borrows from the

Observation and Measurements (O&M: OGC 07-022r1) and Sampling Features (OGC

07-002r3) specifications.

The scope of GWML is the geological aspect of groundwater together with technical

details of wells and groundwater measurements. It covers, amongst other aspects:

- Aquifers and other kinds of HydrogeologicUnit

- Water Quantity, Flow system, Reservoir and Budget.

- Water Quality (natural quality), suspended, dissolved and colloidal content

- Water Wells, wells components, such as screens and casing.

It does not cover water quality beyond natural quality, for instance contamination by

human activity and remediation is not specifically covered, but handled generically.

Surface water is not modeled in any details. Geochemistry is not modeled beyond result

reporting using O&M, which excludes explicit details about sample manipulations,

methodologies, etc. But this can be covered generically though O&M.

GWML has been designed according to the ISO-19103, ISO-19118 and ISO-19136

standards following the best practices developed in GeoSciML. This methodology

allows this development to be inserted into the larger OGC framework and SOA

architecture implied by such standards.

The methodology to create this model involves creating a UML representation,

following ISO profiles (ISO 19103), and importing all the external models that can be

reused in the context of GWML. The UML representation can be converted into a W3C

XSD schema following the ISO-19118 guidelines, which prescribe a series of standard

XSD constructs to represent all elements permitted in the ISO UML profile. The XSD

schema defines the XML structure of a GML application and provides the validation

mechanism to assess the syntactic conformance of a XML document. The XSD

representation is a 1:1 equivalent of the UML representation; therefore the UML model

is also the official documentation of the XSD schema.

GWML is conformant to many ISO and OGC standards and uses GeoSciML to describe

geology. Documentation, UML model and schema are available at:

http://ngwd-bdnes.cits.rncan.gc.ca/gwml

2.4 Mineral Occurrence data model description

The Mineral Occurrence data model is now renamed EarthResourceML (ERML). It has

been developed by the Australian GGIC (Government Geoscience Information

Committee) Mineral Occurrence working group since 2004.

From a modeling viewpoint, ERML uses all rules defined by ISO/OGC to create a data

model for geographic information (feature type structure, UML modeling, XML

encoding).


31/08/2009 of 84

The main packages managed by ERML are “Mine” and “Mineral Occurrence”.

Feature-types for Mine:

- Mining activity, with type, status, duration, ore processed, deposit, raw material,

product, material,

- Mining Feature Occurrence, with location, positional accuracy, and link to all

occurrences,

- Product with name, commodity, grade, source reference, production, source

commodity, recovery,

- Mined material, with material (use of Earth Material from GeoSciML), raw material

role (gangue, ore, …), proportion,

Feature-types for Mineral Occurrence:

- Commodity, commodity measure

- Earth resource, with dimension, material

- Mineral occurrence and non metallic occurrence,

- Mineral deposit model,

- Mineral system,

- Ore measure, reserve, resource, and endowment,

- Supergene processes

ERML uses GeoSciML to describe geology related to mineral occurrences.

The official version is number 1.1. The model is still under development.

Documentation, UML model and schema are located at www.earthresourceml.org.

2.5 Landslides data model description

The development of the Australian Landslides Data Model is being coordinated by

Geoscience Australia. Project partners, landslide consultants, interoperability experts

and members of the Australian Geomechanics Society are contributing to the model

development work.

The model was developed to provide best practice in establishing landslide inventories

to ensure that information is useful and relevant to users. The model also demonstrates a

way of utilizing interoperability to: “establish a nationally consistent system of data

collection, research and analysis to ensure a sound knowledge base on natural disasters

and disaster mitigation”.

The model is an extension of GeoSciML and uses patterns and features common to

GeoSciML. These patterns are based on ISO and Open Geospatial Consortium (OGC)

standards using Geographic Mark-up Language (GML) as an eXtensible Markup

Language (XML) encoding for geographic information. The Landslide Data Model is

an example of a domain-specific schema.

The model is still under development.


31/08/2009 of 84

2.6 Earthquakes data model description

QuakeML is a flexible, extensible and modular XML representation of seismological

data which is intended to cover a broad range of fields of application in modern

seismology. The first part of QuakeML will cover basic seismic event description,

including moment tensors. The current version of QuakeML is 1.1. (released December

2008)

The flexible approach of QuakeML allows further extensions of the standard in order to

represent waveform data, macroseismic information, probability density functions, slip

distributions, shake maps, and others

QuakeML is developed in parallel with a UML representation of its data model. This

allows an elaborate software development strategy which uses the UML class model

together with a custom UML profile. The XML Schema (XSD) description is created

automatically from the UML model with the help of tagged values, which describe the

mapping from UML class attributes to XML representation.

The main classes of QuakeML are:

- The event defined by an ID, an origin, a magnitude, a focal mechanism, a type

(earthquake, explosion, quarry blast, …), a description, a comment, and information

about the creator in the database (agency, author, version, date of creation),

- All properties of a specific seismic event are described by:

- Origin with time, coordinates, depth, epicentre, reference system, earth model,

quality, origin type, evaluation mode and status,

- Magnitude with value, type station count, azimuthal gap

- Station Magnitude with magnitude, type, amplitude, method, wave form

- Focal Mechanism with triggering origin, nodal planes, principal axes, azimuthal

gap, station polarity, misfit, station distribution ratio, method, and Moment

tensor,

- Amplitude with type, displacement, time window, period, signal to noise, pick

ID, wave form, filter, method, scaling time, evaluation mode

- Pick with time, wave form, filter, method, horizontal slowness, onset, phase

hint, polarity, evaluation mode and status, and arrival.

This data model uses UML and XML technologies, but it does not use ISO TC 211

standards about Geographic Information (like GML to describe the geometry, or the

definition of a feature-type).

More information about QuakeML can be found on the web site:

https://quake.ethz.ch/quakeml/QuakeML

2.7 Borehole data model description

Two main data models for boreholes are available (excluding WITSML from the

petroleum domain, which is quite different from the geological boreholes addressed

here): GeoSciML developed by the CGI/IWG and BoreholeML develop by Germany.

2.7.1 Boreholes in GeoSciML

See GeoSciML, paragraph “Boreholes & Observations”


31/08/2009 of 84

2.7.2 Boreholes in BoreholeML

BoreholeML development started in 2004 and the initiative was closely connected to

the European eEarth project, designed and set up in 2003 (www.eEarth.nl). The

objective was the creation of XML structures providing data exchange for borehole data

between the different state geological surveys in Germany and their eEarth project

partners. Due to the federal structure in Germany, the state geological surveys have

responsibility for management of geological data in their state and have their own

borehole databases. These databases differ significantly in structure, data format, and

the coding standards which are used for describing the sampled material and the drilled

geological units. However, the digital data coverage is high with approximately 2.7

million boreholes stored digitally in these databases. Because of the lack of a national

standard, the BoreholeML team coordinated with a national ad-hoc geological expert

group to set up an agreed collection of key lists with mapping to the different existing

geological coding dictionaries. The code lists in BoreholeML have been derived from

these key lists.

The first web application based on the outcome of the XML expert group was the

“Borehole Map of Germany” (http://www.infogeo.de/infogeo/home/bohrpunkte). This

application displays borehole locations and metadata and includes functions to display

borehole profiles with interval data. It is multilingual and allows (for some boreholes)

the viewing of borehole interval logs in a choice of languages.

The currently released version of BoreholeML is version 2 which is available from

http://www.infogeo.de/bla-geo/bis-

steuerungsgruppe/publikationen_und_downloads/bohrdatenaustausch/index_html with

documentation (in English with some German) available at

http://www.infogeo.de/infogeo/borehole/doc/boreholeMLV2.doc. Version 3 of

BoreholeML also includes technical data for production wells (casings, installation,

water measurements etc.) – this has now been completed but not published.

The BoreholeML version 2 model is primarily concerned with borehole index

information, but it does also provide geoscientific information on borehole intervals.

This interval information includes lithostratigraphy, chronostratigraphy, lithology,

genesis, carbonate content and water content. These properties are constrained by code

lists.

There has been some discussion between the BoreholeML development team and the

GeoSciML development team about integration of BoreholeML into GeoSciML, but at

present there is no-one available in the BoreholeML team to collaborate on this so the

data models are quite distinct.


31/08/2009 of 84

3 INSPIRE requirements for data specification

3.1.1 Available INSPIRE documents to help data specification activity

The INSPIRE Data Specifications Drafting Team provided documents as a basis to

create the common European data model for each INSPIRE Theme:

- D2.3 INSPIRE Themes definition. For Geology “Geological information provides

basic knowledge about the physical and chemical composition and the genesis of the

underground, in particular on the properties of the rocks and sediments (age,

petrography, genesis and tectonic elements ...) and their structure.”

- D2.5 Generic Conceptual Model. This document is to help in the process of

developing Data Specifications that will become Implementing Rules. Using it

within different themes will result in a first level of harmonization. It specifies the

generic aspects of geometry, topology, time, thematic information, identifiers and

relationships between spatial objects. It defines rules and recommendations to build

the common data model for each theme.

- D2.6 Methodology for the development of data specifications

- D2.7 Rules for the exchange of spatial data. It specifies general rules for exchange

of spatial data that are mandatory for all spatial objects in spatial data sets that fall

under the regulation of the INSPIRE Directive.

3.1.2 INSPIRE Data specification document for each theme

The INSPIRE team has defined the table of content of the data specification document

to be made by each theme:

- Overview

- Data product identification

- Data content and structure, with Application schema

- Reference systems

- Data quality

- Metadata

- Delivery

- Portrayal, with Layer organization

In this table of content, only a part of “Data content and structure, with Application

schema” is related to WP5: the data structure with its application schema.

3.1.3 INSPIRE requirements for data modeling

The D2.5 Generic Conceptual Model defines components for data harmonization, and

94 requirements and 34 recommendations.

Table A1 in Annexe A is the list of requirements for data specification. They must be

read with the knowledge of the document “D2.5 Generic Conceptual Model”. The table

contains the requirement id and the chapter number to locate each requirement in this

document.

The “1GE” column specifies if the INSPIRE requirement is relevant for 1GE project.


31/08/2009 of 84

It is possible to provide comments for each requirement using the line below the

requirement.

4 WP2 requirements

A part of the work of WP2 is to define user needs for geological information. A part of

these users’ needs are requirements for the OneGeology-Europe data model. This

chapter checks if the data model is able to manage all necessary information required by

WP2.

The scope of the 1GE data model is geology, not applied geology, so we take into

account from WP2 requirements only those for geology (from deliverable D2.1 User

need).

4.1 User needs summary for data modeling

To summarize from the data model viewpoint, there are needs for:

1. surface geology (lithology mainly, and geological structures),

2. high resolution data,

3. harmonized data,

4. information presented so that it can be understood by non-specialist,

5. information presented so that it can be easily used by engineers,

6. delivery through internet (mainly through web services).

4.2 Proposal to address WP2 requirements

1. Surface geology (lithology mainly, and geological structures)

WP3 has defined the layers organization for geology with a mandatory layer - surface

geology - and an optional layer – bedrock geology. These two layers use data described

with the same data structure as they are both geologic units. The attribute “Lithology” is

managed by the 1GE data model.

The 1GE data model also manages geologic structures.

2. High resolution data

From the data model viewpoint there is no difference between low and high resolution

data. Only the content, the accuracy, the density, the geometry of information are

involved. High resolution data could use different terms (for lithology for example) to

low resolution data. These terms are managed in dictionaries or vocabularies, and the

data model allows data providers to use the relevant vocabularies according to their

needs.

3. Harmonized data

To harmonize data there are three main topics to address:

- The data structure: all providers must provide their data in the same “format”, so

that user’s applications are able to get different data in the same way. The 1GE

data model provides this harmonized structure using XML technologies.

- The data content (semantic interoperability): for the same attribute (lithology for

example), all data providers have to use a common vocabulary (in various


31/08/2009 of 84

languages if needed), so that the same concept is well understood, well described

among various providers and the users get consistent information.

- The geometry: geological units are described by polygons on geological maps. But

these maps are interpretive maps, so the same unit described on both sides of a

border by two geologists may have geometries which do not fit totally on the

border line. This important issue is not an issue for the data model; it manages

geometry for each geologic unit, with the shape provided by geologists and

digitizers.

4. Information presented so that it can be understood by non-specialists

This requirement could be satisfied using more general vocabularies instead of

specialist geological ones. The data model allows the providers to select the relevant

vocabulary. There is a need to define vocabularies for non-specialists.

Only a few attributes should be presented for each geologic unit, maybe only the name,

the main lithology, and possibly the age. The data model offers all these attributes, the

selection of attributes to publish has to be done when the providers set up the web

services.

5. Information presented so that it can be easily used by engineers

The same remark as previously for non-specialists: use of specific vocabularies and

selected attributes according to the engineers requirements.

6. Delivery through internet (mainly through web services)

The 1GE data model uses technologies in line with internet and web services

requirements: XML as an exchange format, ISO/OGC web services to access and

deliver data.

5 WP3 requirements

The first objective of this chapter is to analyze the WP3 requirements (from deliverable

D3.1) to define the GeoSciML profile for OneGeology-Europe, and so to provide

information for the service implementation with the necessary mapping between

national data models and GeoSciML.

The second objective is to check if the GeoSciML data model is able to satisfy the WP3

requirements about features, and their attributes.

5.1 General review of WP3 requirements

To build on-the-fly a European geological map at the scale of around 1:1Million,

Geological Surveys agreed on features (and their attributes) to provide.

Two main layers will be setup for the Web Map Services:

- a layer for the Surface Geology (Quaternary superficial geology + exposed bedrock)

- a layer for the Geologic Structures

A third and optional bedrock layer is provided when the geology is described by two

layers: Quaternary layer and Bedrock layer (pre-Quaternary).


31/08/2009 of 84

From a data modelling viewpoint Surface Geology and Bedrock can be described by

Geologic units with several attributes and polygons (one or several) that represent the

geologic unit on the map.

5.1.1 Requirements for Geologic Units

A Geologic Unit can be described by the following main attributes:

- a name,

- a description,

- the lithology,

- the age, at least one term or two terms (lower – upper) from ICS (but other options

are possible)

- the genesis described with Event Environment and Event Process is mandatory for

quaternary units

- the metamorphic background (facies, grade, P/T conditions)

- the geometry: one or more polygons

One or more Geologic Events with age, and process could be used to describe history,

including Orogenic Events, if necessary.

To improve interoperability between various data providers, the data must use as much

as possible common vocabularies for lithology and age (see chapter below).

5.1.2 Requirements for Geologic Contacts and Structures

For Structures, WP3 deals only with Faults. At the scale 1:1M others structures (folds,

horsts, grabens…) are not described.

A Geologic Structure is described by the following attributes:

- Fault Type with Fault Sense and Fault Movement Type

- Observation method: Structure Inferred/Observed

- The geometry: one or more lines

A Contact is described by

- The Contact Type

- The geometry: one or more lines

5.1.3 Requirements for Common Vocabularies

To improve interoperability among various data providers, the data must use as much as

possible common vocabularies. The following vocabularies are requested by WP3

specifications, the 1GE profile will determine how to manage this according to

GeoSciML proposals.

Requested vocabularies:

- Lithology,

- Age,


31/08/2009 of 84

- Event environment,

- Event process,

- Orogenic event,

- Regional stratigraphy,

- Composite rocks

- Composition category

- Metamorphic grade,

- Metamorphic facies,

- Metamorphic P/T condition,

- Contact type,

- Faults type,

- Lines and delineated object,

- Observation method

6 WP9 requirements

6.1 Requirements for Geologic Units and Structures for “high resolution maps”

The definition of requirements for geological data used to produce high resolution maps

is a developing process during the project as it is linked to the use cases and related best

practices to be delivered at the end of the project. At this stage, some requirements are

already available (results of draft documents and meetings). The following requirements

are in addition to the WP3 requirements.

For Geologic Units:

- Rank (Group, Formation, Member, …) if stratigraphy is harmonised,

- Material, to describe geologic units with more details than with a “simple” lithology

(for example to describe various components and their abundance, particle geometry

with size and shape, …),

- Description of Geologic Units with sub-units (enabling the building of stratigraphic

hierarchies),

- Mineral composition,

- Weathering character,

- Metamorphic description (part is already required by WP3)

- Physical description (density, permeability, …)

- Bedding description (style, thickness, …)

For Geologic Structures:

- Contact (a part is already required by WP3)

- Boundary relationships

6.2 Need for Vocabularies

For high resolution data more detailed vocabularies might be needed (mainly for

lithology) than vocabularies used for data at 1:1M scale. The GeoSciML structure

allows managing various vocabularies for the same attribute (lithology for example). It

will be up to the data providers to use this option.


31/08/2009 of 84

7 Proposal to fit requirements from WP2, WP3, WP9

7.1 Proposal to fit requirements for Geologic Units

This chapter describes the proposed use of the GeoSciML data model to manage

features and attributes required by WP2, WP3 and WP9. This proposal is used by WP5

to define the 1GE profile. Only features and required attributes are presented, along

with the mandatory attributes of GeoSciML. The detailed description will be provided

in the profile, this table is only to check the link between the required elements and

GeoSciML features and attributes. The GeoSciML data model provides many more

elements to describe geology.

Required Features and

attributes

GeoSciML Features and attributes (1) Comment

Geologic Unit Geologic Unit

Name Name This field should contain the

national name of the unit, when

available (often not available at

scale 1:1M).

Description Description Description of the unit, in

national language. This field

will keep the whole national

description

Geologic Unit Type GeologicUnitType x

ObservationMethod x

Purpose x

Thickness UnitThickness

Rank Rank

eventAge (as a term range)

eventProcess

Age (as a term range) preferredAge / GeologicEvent:

- eventAge

- eventProcess

- eventEnvironnement eventEnvironnement

name: for Orogenic Events

eventAge (numeric)

One or more Geologic Events

(age as a numeric value)

geologicHistory / GeologicEvent:

- name

- eventAge

- eventProcess eventProcess

x role

lithology : to describe simple

lithology

Material: to describe more

attributes than simple lithology

(CompoundMaterial/

CompositionCategory, and

RockMaterial/ Lithology or

other attributes

Lithology Composition /

CompositionPart:

- role

- lithology as a ControlledConcept

- material as a CompoundMaterial

- proportion

x Proportion

Metamorphic description

(with Orogenic event)

MetamorphicProperties or

MetamorphicCharacter/

MetamorphicDescription:

If related to the Geologic Unit,

then use



31/08/2009 of 84

- metamorphicFacies

- metamorphicGrade

- peakPressureValue

- peakTemperatureValue

- protolithLithology

metamorphicDescription.

If related to the rock, then use

RockMaterial /

metamorphicProperties/

metamorphicDescription .

Genetic aspects Genetic aspects (mandatory for

quaternary deposits) are described

with event process of Geologic

event.

Geologic units with various parts GeologicUnit/part/GeologicUnitPart

With role and proportion

Physical properties of the

geologic unit

Physical Description with density

and permeability

Bedding Bedding description with pattern,

style and thickness

Weathering character Weathering description with

environment, degree, process and

product

Compound Material /

ParticleGeometry/

ParticleGeometryDescription with

size and shape

More description for material

Physical Description with density

and permeability

Mineral composition Earth material / Mineral / mineral

name

Polygons of the unit MappedFeature

ObservationMethod x

PositionalAccuracy x

SamplingFrame x

Geometry Shape x

(1): Elements not required by WPs but mandatory for GeoSciML, so they must be present in the profile.

Remarks:

Unit name: Several name fields are available in GeoSciML. One of those could be used to hold the

original (national) name of the unit and thus provide a potential future hook to the national stratigraphic

lexicon and the full detail of information recorded there.

Age : there is one age for a geologic unit (the “preferred age”), and one of the encoding possibilities has

to be selected (text value - one value or a range from vocabulary, or numeric value – one or a range). If

there is a need to encode age in various forms, or to register several ages, then GeoSciML provides the

“geologic history” with the same attributes but where many values are allowed. The ‘preferred age’ is to

improve interoperability and to allow queries on this attribute (too many various ways of encoding age

will prevent interoperable queries)


31/08/2009 of 84

7.2 Proposal to fit WP3 requirements for Geologic Structures

WP3 Features and attributes GeoSciML Features and attributes (1) Comment

Geologic Structure (Fault) Geologic Structure

ObservationMethod x

Purpose x

Fault type with movement and

sense

Shear Displacement Structure /

Total Displacement/

Movement Sense and Movement

Type

To be checked

Contact with contact type Geologic Structure

Contact type

Lines of structures MappedFeature

ObservationMethod x

PositionalAccuracy x

SamplingFrame x

Geometry Shape x

(1): Elements not required by WP3 but mandatory for GeoSciML, so they must be

present in the profile

7.3 Proposal to fit requirements for Vocabularies

A vocabulary is a list of concepts; each concept is described by an ID, a name, a

description, a list of translated terms in various languages, and relationships with other

concepts.

From a data structure viewpoint, GeoSciML fits the requirements for vocabularies.

From a content viewpoint, new items have been identified by WP3 and a conciliation

meeting with the Concept Definition Working Group of the CGI-IWG will take place in

Québec (September 2009).

7.4 Conclusion

GeoSciML version 2.0 provides most of the necessary features and attributes to fit the

WP2, WP3 and WP9 known requirements. Some missing or incomplete elements have

been identified; these will be an input for the development of GeoSciML version 3 that

will start in September 2009 during the Québec meeting of the CGI-IWG.


31/08/2009 of 84

8 Guidelines for a 1GE profile

This chapter provides guidelines for the 1GE data model according to all the

requirements specified. A GeoSciML example encoded in XML will be provided by

WP6 to give guidelines for implementation within the web services (WMS and WFS).

Note: This profile could be updated during the next months when Geological Surveys

implement it in Web Services, and in light of WP9 use cases and best practices.

Some values come from vocabularies; except for the stratigraphic vocabulary, provided

by ICS (International Chart of Stratigraphy), all other vocabularies are the result of

discussions between 1GE/WP3 and CGI/IWG- Concept Definition Working Group. The

aim is to produce an agreed vocabulary for each type of element. This task is currently

in progress, and the deadline is to have these vocabularies available in early January

2010. The 1GE profile gives a reference to these vocabularies to the CGI/IWG web site.

The reader should check this web site to see the status of these vocabularies and to read

the current discussions about terms.

(https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/ConceptDefinitionsTG)

The CGI reference for vocabularies is the version “200811” (November 2008).

The discussion about lithology is here:

https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/LithologyCategories

8.1 GeoSciML elements selected for OneGeology-Europe

This chapter describes for geologic units and geologic structures the selected elements

(feature-types and their attributes) to create the OneGeology-Europe profile. The first

table gives the list of these elements, if they are mandatory or optional (for 1GE), the

type, if the value comes from a vocabulary. The second table gives the definition of

each element.

How to read the tables:

- M/O : “Mandatory” or “Optional”

- 1, 0..1, 1..n : “1” for only one value, “0..1” for zero or one value, “0..n” for zero or

many values, “1..n” for one or many values

- Type: “Text”, “ControlledConcept”, “CGI_Term”, “CGI_Value”, … (see

GeoSciML description, chapter 2.2, paragraph “CGI Values”, Figure 8)

- Vocab. “x” means the value comes from a vocabulary

Some groups of elements are optional but some of their attributes are mandatory: that

means that you may or may not use this group, but if you use it then some attributes

must have a value.

The status Mandatory or Optional is a combination between requirements from 1GE

and GeoSciML (some elements optional in GeoSciML may be mandatory for the 1GE

profile).


31/08/2009 of 84

8.1.1 For Geologic units

The three first elements (ID, name and description) are inherited from GML, as

GeoSciML uses the general rules to model Feature type as defined in the ISO standards

and encoded in GML.

GeoSciML Features and attributes M/O 0, 1, n Type Vocab.

Geologic Unit

GeologicUnit ID M 1 Text

Name O 0..n Text

Description O 0..1 Text

GeologicUnitType M 0..1 x

ObservationMethod M 1..n x

Purpose M 1 Text

Rank O 0..1 x

UnitThickness O 0..n CGI_Numeric

Age:

preferredAge / GeologicEvent: M 0..1

- name (for Orogenic Event) O 1 Text x

- eventAge (as a term range) M 1 CGI_TermRange x

- eventProcess M 1..n CGI_TermValue x

- eventEnvironnement O 0..n CGI_TermValue x

Complementary ways to specify the age:

geologicHistory / GeologicEvent: O 0..n

- eventAge (as numeric values) M 1 CGI_NumericRange

- eventProcess M 1..n CGI_TermValue x

Lithology:

Composition / CompositionPart: M 0..n

- role M 1 Text x

- lithology M 1..n ControlledConcept x

- material O 0..1 CompoundMaterial

- proportion M 1 CGI_Value x

Material:

EarthMaterial / CompoundMaterial: O 0..n

- color, O 0..n CGI_TermValue

- purpose, M 1 Text (“instance”)

- compositionCategory, O 0..n CGI_TermValue x

- geneticCategory, O 0..n CGI_TermValue x

- consolidationDegree, M 1 CGI_TermValue x

- lithology M 1..n ControlledConcept x

More description for material:

Compound Material / ParticleGeometry/

ParticleGeometryDescription:

O 0..1

- size O 0..n CGI_Value

- shape O 0..n CGI_Value

Compound Material / Physical Description: O 0..1

- density, O 0..n CGI_Numeric

- permeability O 0..n CGI_Value


31/08/2009 of 84

Metamorphic Properties:

Compound Material / MetamorphicProperties or

MetamorphicCharacter / MetamorphicDescription:

O 0..1

- metamorphicFacies O 0..n CGI_TermValue x

- metamorphicGrade O 0..1 CGI_TermValue x

- peakPressureValue O 0..1 CGI_Numeric

- peakTemperatureValue O 0..1 CGI_Numeric

- protolithLithology O 0..n EarthMaterial

Mineral composition:

CompoundMaterial/ConstituentPart/Earth material

/ Mineral / mineral name

O 1..n ControlledConcept x

If only “CompositionPart / lithology” is used:

O

- Geologic event / Event process M 1..n CGI_TermValue x

- Geologic event / Event environment O 0..n CGI_TermValue x

If “CompositionPart /material” is used:

- CompoundMaterial / geneticCategory

O 0..n CGI_TermValue x

Geologic unit composed of various units:

GeologicUnit/part/GeologicUnitPart: O 0..n

- role M 1 Text

- proportion M 1 CGI_Value

Physical properties of the geologic unit:

Physical Description: O 0..1

- density, O 0..n CGI_ Numeric

- permeability O 0..n CGI_Value

Bedding:

Bedding description: O 0..1

- pattern, O 0..n CGI_TermValue

- style, O 0..n CGI_TermValue

- thickness O 0..n CGI_Value

Weathering character:

Weathering description: O 0..1

- environment, O 0..n CGI_TermValue x

- degree, O 0..1 CGI_TermValue

- process, O 0..n CGI_TermValue x

- product O 0..n EarthMaterial

Polygons of the unit:

MappedFeature with: O 0..n

- ObservationMethod M 1..n CGI_TermValue x

- PositionalAccuracy M 1 CGI_Value

- SamplingFrame O 0..n

- Shape M 1..n Geometry


31/08/2009 of 84

8.1.2 For Geologic Structures

GeoSciML Features and attributes M/O 0, 1, n Type Vocab.

Geologic Structure (Fault) and Contacts

GeologicStructureID M 1 Text

Name O 0..n Text

ObservationMethod M 1..n x

Purpose M 1 Text

For Faults : type with movement and sense:


Total Displacement/

O 0..1

- Movement Sense O 0..1 CGI_TermValue x

- Movement Type O 0..1 CGI_TermValue x

For Contacts:

- ContactType, O 0..1 ControlledConcept x

Lines of structures or contacts:

MappedFeature with: O 0..n

- ObservationMethod M 1..n CGI_TermValue x

- PositionalAccuracy M 1 CGI_Value

- SamplingFrame O 0..n

- Shape M 1..n Geometry

8.2 Description of GeoSciML elements (feature types and attributes)

This description comes from the GeoSciML resources web site:

(http://www.geosciml.org/)

8.2.1 For Geologic units

GeoSciML Features and attributes Description

Geologic Unit Geologic units includes both formal units (i.e.

formally adopted and named in the official lexicon)

and informal units (i.e. named but not promoted to

the lexicon) and unnamed units (i.e. recognisable and

described and delineable in the field but not

otherwise formalised). Explicit spatial properties are

available through association with a MappedFeature

GeologicUnit ID

Name

Description

GeologicUnitType Controlled concept defining the type of unit. Logical

constraints of definition of unit and valid property

cardinalities are contained in the definition.

ObservationMethod Term(s) that specify the method by which the values

for the GeologicFeature were obtained (e.g. point

count, brunton compass on site, air photo

interpretation, field observation, hand specimen,

laboratory, aerial photography, creative

imagination...).

Purpose Specification of the intended purpose/level of

abstraction for a given feature or object instance.


31/08/2009 of 84

Scoped name because intention is asserted by author

of the data instance. Values: Instance, TypicalNorm,

IdentifyingNorm.

Rank Term that classifies the geologic unit in a

generalization hierarchy from most local/smallest

volume to most regional. Scoped name because

classification is asserted, not based on observational

data.

Examples: group, subgroup, formation, member, bed,

intrusion, complex, batholith

UnitThickness Typical thickness of the geologic unit.

Age: A geologic age is related to a particular

GeologicEvent, during which one or more geological

processes act to modify geological entities

preferredAge / GeologicEvent: Specifies the geologic event that the data supplier

considers the 'preferred' event age and event process

for that feature.

This is the age and process of the feature that would

be commonly shown on a geologic map (eg

deposition age, peak temperature age, intrusion age).

Normative geologic unit descriptions are expected to

include an age specification whenever the age is

constrained--even if the range is very large (e.g.

Phanerozoic....).

- eventAge (as a term range) The eventAge attribute is the age of a particular

geological event or feature expressed in terms of

years before present (absolute age), referred to the

geological time scale, or by comparison with other

geological events or features (relative age). An

eventAge can represent an instant in time, an interval

of time, or any combination of multiple instants or

intervals. Specifications of age in years before

present are based on determination of time durations

based on interpretation of isotopic analyses of

EarthMaterial (some other methods are used for

geologically young materials). Ages referred to

geological time scales are essentially based on

correlation of a geological unit with a standard

chronostratigraphic unit that serves as a reference.

Relative ages are based on relationships between

geological units such as superposition, intruded by,

cross-cuts, or 'contains inclusions of'

- eventProcess A geologicProcess is a function, possibly complex,

that acts on one geologic entity to produce another

geologic entity at a later time. GeologicProcess is

time independent; some GeologicProcesses are

presently observable in the world or in the laboratory,

others can only be inferred from observing the results

of the process. Processes take one or more of

EarthMaterial, GeologicUnit, or GeologicStructure as

input and have one or more of EarthMaterial,

GeologicUnit or GeologicStructure as output.

- eventEnvironnement The physical setting within which a GeologicEvent

takes place. GeologicEnvironment is construed

broadly to include physical settings on the Earth

surface specified by climate, tectonics, physiography

or geography, and settings in the Earths interior

specified by pressure, temperature, chemical


31/08/2009 of 84

environment, or tectonics. Specification of setting

may be a simple text description or a link to a

complex description.

Complementary ways to specify the age:

geologicHistory / GeologicEvent: A sequence of GeologicEvents with role

geologicHistory allow describing the Genesis of the

GeologicFeature

- eventAge (as numeric values) See above

- eventProcess See above

Lithology:

Composition / CompositionPart: Describes the composition (detailed, instance

specific, lithologic description) of the GeologicUnit

- role Defines the relationship of the earth material

constituent in the geologic unit, e.g. vein, interbedded

constituent, layers, dominant constituent. Scoped

name because role is asserted by the geologist

building the description.

- lithology 1..* so that it is possible to give a material names

from several different vocabularies, e.g. chemical and

genetic classifications (common in volcanic rocks) or

to use multiple terms from a single vocabulary with

implication that classification is a conjonction of

terms.

- material

- proportion Quantity that specifies the fraction of the geologic

unit composed of the compound material.

Material: Earth Material represents material composition or

substance, and is thus independent of quantity or

location. Ideally, Earth Materials are defined strictly

based on physical properties, but because of standard

geological usage, genetic interpretations may enter

into the description as well.

EarthMaterial / CompoundMaterial:

- color, Terms to specify color of the earth material. Color

schemes such as the Munsell rock and soil color

schemes could be used.

- purpose, Specification of the intended purpose/level of

abstraction for the given EarthMaterial. Scoped name

because intention is asserted by author of the data

instance.

Values: Instance, TypicalNorm, IdentifyingNorm.

- compositionCategory, Term to specify the gross chemical character of

geologic unit. Examples: silicate, carbonate,

ferromagnesian, oxide.

Chemical classification terms for igneous rocks also

go here. Examples: alkalic, subaluminous,

peraluminous, mafic, felsic, intermediate.

- geneticCategory, A term that represents a summary geologic history of

the material. (ie, a genetic process classifier term)

Examples include igneous, sedimentary,

metamorphic, shock metamorphic, volcanic,

pyroclastic.

- consolidationDegree, A property that specifies the degree to which an

aggregation of EarthMaterial particles is a distinct

solid material. Consolidation and induration are

related concepts specified by this property. They

define a continuum from unconsolidated material to


31/08/2009 of 84

very hard rock. Induration is the degree to which a

consolidated material is made hard, operationally

determined by how difficult it is to break a piece of

the material. Consolidated materials may have

varying degrees of induration (NADMSC, 2004)

- lithology A controlled concept indicating the name of the

RockMaterial type (eg, quartz sandstone, basalt,

muscovite schist, sand, mud, soil, saprolite).

More description for material:

Compound Material / ParticleGeometry/

ParticleGeometryDescription:

ParticleGeometryDescription describes particles in a

CompoundMaterial independent of their relationship

to each other or orientation. It is distinguished from

Fabric in that the ParticleGeometryDescription

remains constant if the material is disaggregated into

its constituent particles, whereas Fabric is lost if the

material is disaggregated. Properties include the

particle size (grainsize), particle sorting (size

distribution, eg: well sorted, poorly sorted, bimodal

sorting), particle shape (surface rounding or crystal

face development, eg: well rounded, euhedral,

anhedral), and particle aspectRatio (eg: elongated,

platy, bladed, compact, acicular).

- size The Size attribute specifies particle grainsize. Values

may be reported using absolute measurements (eg:

range, mean, median, mode, maximum) or as

descriptive terms from a schema appropriate to the

type of Compound Material (eg: the Udden-

Wentworth sheme for clastic sedimentary rocks - silt,

sand, gravel; volcaniclastic rocks - ash, lapilli, bomb;

crystalline rocks - fine, medium, coarse,

cryptocrystalline)

- shape The Shape attribute describes, a) the development of

crystal faces bounding particles in crystalline

compond materials, and b) surface rounding of grains

in sedimentary rocks. Roundness is a measure of the

sharpness of the edges between surfaces bounding a

particle (see Jackson, 1997; Wadell, 1932). Terms

should be appropriate for the kind of compound

material (eg: for crystalline rocks- euhedral,

ideoblastic, subhedral, anhedral, xenoblastic; for

sedimentary rocks - angular, rounded)

Compound Material / Physical Description: PhysicalDescription describes a limited but

commonly used set of physical properties of Rocks

and UnconsolidatedMaterials. This set is an

incomplete subset of potential physical properties

that could be used to describe rocks and

unconsolidated materials

- density, Material mass per unit volume

- permeability The measure of the capacity of a porous material to

transmit a fluid under unequal pressure. Customary

unit of measure: millidarcy

Metamorphic Properties:

Compound Material / MetamorphicProperties

or MetamorphicCharacter /

MetamorphicDescription:

MetamorphicDescription describes the character of

metamorphism applied to a CompoundMaterial or

GeologicUnit using one or more properties including

estimated intensity (grade; eg high grade, low grade),

characteristic metamorphic mineral assemblages


31/08/2009 of 84

(facies; eg, greenschist, amphibolite), peak P-T

estimates, and protolith material if known

- metamorphicFacies A description of characteristic mineral assemblages

indicative of certain metamorphic P-T conditions.

Examples include Barrovian metasedimentary zones

(eg: biotite facies, kyanite facies) or assemblages

developed in rocks of more mafic composition (eg:

greenschist facies, amphibolite facies).

- metamorphicGrade A term to indicate the intensity or rank of

metamorphism applied to an EarthMaterial (eg: high

metamorphic grade, low metamorphic grade)

Indicates in a general way the P-T environment in

which the metamorphism took place. Determination

of metamorphic grade is based on mineral

assemblages (ie, facies) present in a rock that are

interpreted to have crystallized in equilibrium during

a particular metamorphic event.

- peakPressureValue A numerical value to indicate the estimated pressure

at peak metamorphic conditions

- peakTemperatureValue A numerical value to indicate the estimated

temperature at peak metamorphic conditions

- protolithLithology An interpretation of the EarthMaterial that

constituted the pre-metamorphic lithology for this

metamorphosed CompoundMaterial.

Orogenic event as a geologic event

Genetic aspects:

If only “CompositionPart / lithology” is used:

- Geologic event / Event process.

A geologicProcess is a function, possibly complex,

that acts on one geologic entity to produce another

geologic entity at a later time. GeologicProcess is

time independent; some GeologicProcesses are

presently observable in the world or in the laboratory,

others can only be inferred from observing the results

of the process. Processes take one or more of

EarthMaterial, GeologicUnit, or GeologicStructure as

input and have one or more of EarthMaterial,

GeologicUnit or GeologicStructure as output.

If “CompositionPart /material” is used:

- CompoundMaterial / geneticCategory

A term that represents a summary geologic history of

the material. (ie, a genetic process classifier term)

Examples include igneous, sedimentary,

metamorphic, shock metamorphic, volcanic,

pyroclastic.

Geologic unit composed of various units:

GeologicUnit/part/GeologicUnitPart: GeologicUnitPart associates a GeologicUnit with

another GeologicUnit that is a proper part of that

unit. Parts may be formal or notional . Formal parts

refer to a specific body of rock, as in formal

stratigraphic members. Notional parts refer to

assemblages of particular EarthMaterials with

particular internal structure, which may be repeated

in various places within a unit (e.g. 'turbidite

sequence', 'point bar assemblage', 'leucosome veins')

- role Nature of the parts, e.g. facies, stratigraphic,

interbeds, geographic, eastern facies

- proportion Quantity that specifies the fraction of the geologic

unit formed by the part.

Physical properties of the geologic unit:

Physical Description:


31/08/2009 of 84

- density, See above

- permeability See above

Bedding:

Bedding description: Geologic unit that has stratification, allowing

specification of thickness and bedding-related

properties. Note that while this usage corresponds to

the formally definition of 'Lithostratigaphic unit' as

defined in the North American Code of Stratigraphic

Nomenclature, usage of this element does not denote

definition or description of a unit in the sense of the

code, only that stratification is present and can be

described.

- pattern, Term(s) specifying patterns of bedding thickness or

relationships between bedding packages,

Examples: thinning upward, thickening upward

- style, Term(s) specifying the style of bedding in a stratified

geologic unit, e.g. lenticular, irregular, planar, vague,

massive

- thickness Term(s) or numeric values characterizing the

thickness of bedding in the unit

Weathering character:

Weathering description: Data type is a container for properties describing the

nature of a GeologicUnit at its interface with the

atmosphere. Soil profile description would have to be

constructed as a GeologicUnit with parts representing

the various horizons in the profile.

- environment, Terms to specify the environmental context of the

weathering description. Typically would be specified

by terms for climate (tropical, arid, termperate,

humid, polar..)

- degree, term to specify degree of modification from original

material, e.g. slightly weathered, strongly weathered,

weathered rock grade III

- process, Weatheirng process, e.g. leaching, accumulation

- product Material result of weathering processes, e.g.

saprolite, ferricrete, clay, calcrete. Materials observed

in a soil profile could be identified using this

property, but EarthMaterial content model does not

allow representation of relationships between

materials in a soil profile

Mineral composition:

Earth material / Mineral / mineral name A naturally occurring inorganic element or

compound having a periodically repeating

arrangement of atoms and a characteristic chemical

composition or range of compositions, resulting in

distinctive physical properties. Includes mercury as a

general exception to the requirement of crystallinity.

Also includes crypto-crystalline materials such as

chalcedony and amorphous silica.

Name of the mineral (eg: orthoclase) or mineral

family (eg: feldspar), approved by the International

Mineralogical Association. (eg:

http://www.mindat.org/mineralindex.php)

Polygons of the unit:

MappedFeature with: A MappedFeature is part of a geological

interpretation.

It provides a link between a notional feature


31/08/2009 of 84

(description package) and one spatial representation

of it, or part of it. (Exposures, Surface Traces and

Intercepts, etc); the specific bounded occurrence,

such as an outcrop or map polygon. The Mapped

Feature carries a geometry or shape. The association

with a Geologic Feature (legend item) provides

specification of all the other descriptors. The

association with a Sampling Feature provides the

context and dimensionality.

A Mapped Feature is always associated with some

sampling feature - e.g. a mapping surface, a section, a

Borehole (see BoreHolesAndObservation) etc. As

noted on the diagram, if the associated sampling

feature is a Borehole, then the shape associated with

the MappedFeature will usually be either a point or

an interval. This reconciles the 2-D ("map", section)

and 1-D (borehole, traverse) viewpoints in a common

abstraction.

- ObservationMethod Specifies the method that was used to identify the

MappedFeature. Examples: digitised, Global

Positioning System, published map, fieldObservation,

downhole survey, aerial photography, field survey.

- PositionalAccuracy Examples: accurate, approximate, diagramatic,

indefinite, unknown, 5 m. Corresponds to ISO19115

DQ_ThematicAccuracy (either quantitative or non

quantitative).result.value

- SamplingFrame Specifies the sampling frame associated with the

MappedFeature

SamplingFrame is MapHorizon or other reference

frame within which the MappedFeature is located.

Map sheet, outcrop, borehole, flightline, swath,

specimen, section, etc

SampledFeature is usually a GSML collection that

represent the geology of interest.

- Shape Points to the GML shape object that describes the

geometry of the MappedFeature. The shape object

may have any dimensionality.

The shape of a mapped feature is determined by

observation, not assertion


31/08/2009 of 84

8.2.2 For Geologic Structures

GeoSciML Features and attributes Description

Geologic Structure (Fault) and Contacts A configuration of matter in the Earth based on

describable inhomogeneity, pattern, or fracture in

an EarthMaterial The identity of a

GeologicStructure is independent of the material

that is the substrate for the structure.

GeologicStructures are more likely to be found in,

and are more persistent in, consolidated materials

than in unconsolidated materials. Properties like

"clast-supported", "matrix-supported", and

"graded bed" that do not involve orientation are

considered kinds of GeologicStructure because

they depend on the configuration of parts of a

rock body. Includes: sedimentary structures

GeologicStructureID

Name

ObservationMethod Term(s) that specify the method by which the

values for the GeologicFeature were obtained

(e.g. point count, brunton compass on site, air

photo interpretation, field observation, hand

specimen, laboratory, aerial photography, creative

imagination...).

Purpose Specification of the intended purpose/level of

abstraction for a given feature or object instance.

Scoped name because intention is asserted by

author of the data instance. Values: Instance,

TypicalNorm, IdentifyingNorm.

For Faults : type with movement and sense:


Total Displacement/

A generalized shear displacement structure

without any commitment to the internal nature of

the structure (anything from a simple, single

'planar' brittle or ductile surface to a fault system

with 10's of strands of both brittle and ductile

nature). This surface may have some significant

thickness (a deformation zone) and have an

associated body of deformed rock that may be

considered a DeformationUnit.

Fault: a discrete surface, or zone of discrete

surfaces, with some thickness, separating two

rock masses across which one mass has slid past

the other and characterized by brittle deformation.

Fault is a map-scale feature. When observed in

outcrop, some faults are just big breccia/gouge

zones with no discrete surfaces, sometimes they

are breccia/gouge zones bounded by discrete fault

surfaces, sometimes a discrete surface in

relatively unbroken rock (at the scale of

description).

- Movement Sense Direction of movement of the plates for sub-

vertical faults (typically 'sinistral', 'dextral', 'left-

lateral', 'dip-slip', 'unknown')

- Movement Type Defines the type of movement (eg dip-slip, strike-


31/08/2009 of 84

slip)

For Contacts: Very general concept representing any kind of

surface separating two geologic units including

primary boundaries such as depositional contacts,

all kinds of unconformities, intrusive contacts,

and gradational contacts, as well as faults that

separate geologic units.

- ContactType, Classifies the contact (eg intrusive, unconformity,

bedding surface, lithologic boundary, phase

boundary); if a vocabulary of named contacts

exists that might be used to classify as well.

Lines of structures or contacts: See MaapedFeature described for Geologic Units

MappedFeature with:

- ObservationMethod

- PositionalAccuracy

- SamplingFrame

- Shape

8.3 Documentation, UML data model and XSD files for GeoSciML

As we define a profile on GeoSciML, all documentation and resources can be found in

the GeoSciML web site (http://www.geosciml.org/).

Once the 1GE profile is implemented and stable, it will be available for data and service

providers on the OneGeology-Europe technical web site with some examples

(http://onegeology-europe.brgm.fr/servicesProviders/servicesToProvide/index.html)

.

Summary of available information about GeoSciML

1. Documentation

Full documentation of the model may be viewed from

http://www.cgi-iugs.org/tech_collaboration/geosciml.html

2. UML Model

GeoSciML is formally defined by a UML model, also known as an "Application

Schema" (following the terminology of ISO 19109). In addition, the domain for certain

feature-properties will be provided, typically serialized as GML Dictionaries.

Designators for key components that are required for deployment in a distributed

environment follow the CGIIdentifierScheme:

https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/CGIIdentifierScheme

The reference version of the Application Schema is provided as XMI documents. (XMI

is an XML serialization of UML).

The UML profile used follows the ISO 19103 profile, and in particular using the rules

from ISO 19136:2007 (GML 3.2.1)

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/IsoTc211Standards#Modellin

g_and_Encoding_UML_and_G


31/08/2009 of 84

GeoSciMLv2 is available as a set of XMI documents at

http://www.geosciml.org/geosciml/2.0/xmi/

The GeoSciML design team uses the Enterprise Architect (EA) UML tool to maintain

the model. A free EA viewer (EAViewer.exe, intended for distribution with such

models) can be obtained from

http://www.sparxsystems.com/products/ea_downloads.html.

When loaded in EA, the model is found under [Model]->[GeoScience Resources]-

>[CGIWorld]->[GeoSciML]

3. XML Schema

The schema is automatically generated from the UML model following the rules

described in ISO 19136:2007 (GML 3.2.1) Annex E with the following variations:

- GeoSciML v2 is currently bound to GML v3.1.1.

- The rule for encoding <<Union>> classes follows :

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmL2GMLAS#4_Class_

association_pattern_targ

- Additional stereotypes are used as described in :

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGml#ISO_TC_211_P

rofile_of_UML

The XML Schema representation of GeoSciML can be used to validate GeoSciML

instance documents. The GeoSciMLv2 specific schemas are available at:

http://www.geosciml.org/geosciml/2.0/xsd/

These import schemas from other namespaces which can be found at a number of

locations.

During development successful validation can be dependent on using particular versions

of these other schemas. You may need to configure your validation environment

specially to do this – for notes on this see:

https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/ConfiguringXmlValidatorsForG

eoSciML.


31/08/2009 of 84

9 Conclusion and next steps

The OneGeology-Europe data model can be built on GeoSciML, as it fits to almost all

1GE requirements. The goal of the IWG/CGI was to develop an international data

model able to improve the interoperability of geological data. We have demonstrated

that this data model can be used by 20 European geological Surveys, with some

extensions suggested during this 1GE data model design phase.

The use of GeoSciML during the next implementation phase across European

Geological Surveys will contribute significantly to a wide deployment of GeoSciML in

Europe. During this second phase we expect some requests that will improve the 1GE

profile and also the quality of GeoSciML. Some proposals have already been identified

during the design phase, and they will be discussed during the next IWG/CGI meeting

in Québec, September 2009.

A few examples of mapping national data bases to GeoSciML are given to illustrate

how a Geological Survey could provide geological data in GeoSciML with minor

adaptations; mainly it is necessary to add a few new fields to the data base to facilitate

the mapping, and to improve performance.

Regarding INSPIRE, GeoSciML appears to be a good candidate to become the data

model of the Geology data theme. The comparison with the INSPIRE requirements

defined in the Generic Conceptual Model shows that GeoSciML is very close to what a

data model should be for INSPIRE.

For the other data themes of the geological domain (groundwater, mineral resources,

landslides, …) WP5 has identified some data models that could be good candidates for

INSPIRE data models.


31/08/2009 of 84

10 ANNEXE A – GeoSciML and INSPIRE

Comparison between GeoSciML and INSPIRE requirements for data specification

Table A1 is the list of requirements for the data specification. They must be read with

knowledge of the document “D2.5 Generic Conceptual Model”. The table contains the

requirement id and the chapter number to locate each requirement in this document.

The “1GE” column specifies if the INSPIRE requirement is relevant for 1GE project.

It is possible to comment on each requirement using the line below the requirement.

Table A1: INSPIRE requirements for data specification

1GE comments:

- To do = not available but no problem to do it and fulfil the requirement (INSPIRE Geological TWG task?)

- To check = not sure with GeoSciML, must be checked, needs more expertise from an expert of the Data Specification Drafting Team

- OK : GeoSciML fits to the requirement - n/a : not applicable for GeoSciML

Id INSPIRE Requirements and recommendations 1GE

5. Overview

1 INSPIRE application schemas shall import the definitions of the Generic Conceptual Model (and transitively from the ISO 19100 series of International Standards). By defining an application schema that imports the Generic Conceptual Model, this application schema has to conform to the Generic Conceptual Model as specified in Clause 25.

To do

GeoSciML is based on ISO 19100 but does not import GCM

2 Spatial data sets in INSPIRE shall always be structured according to an INSPIRE application schema

In 1GE geological datasets are structured according to GeoSciML AS

3 No concept shall be modelled as part of a INSPIRE application schema, if it is competing with a concept already established as part of the Generic Conceptual Model. Similarly, all concepts which are of general utility and not limited to a theme shall lead to a change proposal for the Generic Conceptual Model and should not be modelled in a INSPIRE application schema

To check

To compare GeoSciML concepts and GCM concepts. (might affect GeoSciML modelling of vocabularies)

7. Terminology

4 General terms and definitions in all INSPIRE data specification shall be drawn from the INSPIRE Glossary. Terms that are important in the context of a theme, but which are not already part of the common feature concept dictionary (see 9.2), i.e. which are not spatial object types or spatial object property types, shall be defined in the “Glossary of Generic Geographic Information Terms in Europe.

To do

8. Reference model

5 The reference model specified in ISO 19101 shall be used as the reference model of the INSPIRE data specifications.

OK


31/08/2009 of 84

9. Rules for INSPIRE application schemas

9.1 General Feature Model

6 INSPIRE application schemas shall conform to the General Feature Model as specified in ISO 19109 Clause 7.

OK

9.2 Feature Concept Dictionaries

7 In order to provide a harmonized view to concepts of spatial object types, attribute types, association types and coded values a common feature concept dictionary as specified in ISO 19126 (Feature concept dictionaries and registers) shall be maintained for INSPIRE in an ISO 19135 conformant register. In addition, the name, definition and description of all themes shall be maintained in the feature concept dictionary. The conceptual schema of ISO 19126 shall be extended to include these items.

To do

The GeoSciML scope notes should help with this

9.3 Feature Catalogues

8 The spatial object types of an INSPIRE application schema shall be expressed in a feature catalogue as specified in ISO 19110. An amendment of ISO 19110 is currently in Committee Draft stage in the ISO standardisation process. As soon as the amendment reaches the Draft International Standard stage, this version shall be used as the basis for feature catalogues in INSPIRE. The amendment will provide an XML encoding for feature catalogues. This XML encoding shall be used to encode feature catalogues.

To do

9 Every feature catalogue shall contain the information for all spatial object types that are relevant for the particular application schema.

To do

9.4 Modelling application schemas

10 Each spatial object in a spatial data set shall be described in an application schema. OK

11 An application schema shall contain a complete and precise description of the semantic content of its spatial object types following the concepts and structure defined in the General Feature Model. I.e., the application schema shall contain concepts that can be mapped to the meta-model of the General Feature Model.

To do

12 Every INSPIRE data specification shall include an INSPIRE application schema that is modelled according to ISO 19109 8.2.

To check

13 The spatial object types and their properties specified in an application schema shall be drawn from the common feature concept dictionary.

To do

14 Spatial object types shall be modelled according to ISO 19109 7.1-7.2, 8.1, 8.5-8.9 and according to the additional rules in Clauses 9, 10, 11, 13, and 22 of this document.

To check

15 The profile of the conceptual schema defined in the ISO 19100 series that is used in the application schema shall conform with ISO 19109 8.4.

To check

16 Every INSPIRE application schema shall clearly document the profile to be used for the different properties of spatial object types.

OK

17 Basic types as specified in ISO/TS 19103 6.5 shall be used in an INSPIRE application schema whenever applicable.

To check


31/08/2009 of 84

9.5 Conceptual schema language

18 In INSPIRE, every application schema shall be specified in UML. OK

19 All spatial object types and their properties shall be shown in class diagrams in the UML package describing the application schema.

OK

20 The use of UML shall conform to ISO 19109 8.3 and ISO/TS 19103. To check

21 To model constraints on the spatial object types and their properties, in particular to express data/dataset consistency rules, OCL shall be used as described in ISO/TS 19103. In addition, all constraints shall also be described in natural language in the feature catalogue.

To do To check

9.6 Base application schema

9.6.1 Spatial Object

22 All spatial object types specified in INSPIRE application schemas shall be a direct or indirect specialisation of SpatialObject.

OK

9.6.2 Object with Identifier

23 All spatial object types whose instances are identifiable (see Clause 16) shall inherit from ObjectWithIdentifier

To check

This inheritance is from the INSPIRE General Feature Model which GeoSciML doesn’t inherit from – not sure if that will be a problem

24 All spatial object types whose instances may participate in feature associations or that may be used as targets in object referencing (see Clause 13) shall inherit from ReferencableSpatialObject

To check

This inheritance is from the INSPIRE General Feature Model which GeoSciML doesn’t inherit from – not sure if that will be a problem

9.6.3 Spatial Data Set

25 All spatial data sets shall be instances of SpatialDataSet or of any of its subtypes defined in INSPIRE application schemas.

To check

9.6.4 Versioned Objects

26 In the case where a spatial object may change in a way where it is still considered to be the same object and user requirements for the support of versioning information are identified, versioning information shall be contained in the modelling of the spatial object type as specified in this sub-clause.

No versioning system managed in GeoSciML

27 Versioning information of a spatial object type shall be modelled in a way that allows data providers who do not maintain versions of spatial objects to still conform to the data specification. This requirement does not apply in cases where applications with a strong requirement for versioning of spatial objects are known.

28 Different versions of the same spatial object shall always be instances of the same spatial object type.

29 Different versions of the same spatial object shall always have the same external object identifier. See Clause 16.

30 If in an application schema an association role ends at a spatial object type, this shall denote that the value of the property is the spatial object unless the role has


31/08/2009 of 84

the stereotype <<version>> to denote that the value of the property is a specific version of the target object.

9.6.5 Gazetteers n/a

31 The application schema for gazetteers specified in this sub-clause shall be used in INSPIRE.

32 The spatial object types that are location types for gazetteers, e.g. geographical names and administrative units, shall be specified in application schemas as part of the INSPIRE data specifications. These application schemas may also specify theme-specific subtypes of the spatial object types "Gazetteer" and "LocationInstance", if required.

10. Spatial and Temporal aspects

10.1 Spatial and Temporal characteristics of spatial objects

33 Spatial characteristics of a spatial object shall be expressed in an application schema in one of the following ways depending on the requirements: - by specifying properties of the spatial object type with a value that is a spatial geometry or a topology (see ISO 19109 8.7) - by specifying properties of the spatial object type with a value that is a geographic identifier in a gazetteer (see 9.6.5 and ISO 19109 8.9) - by specifying spatial object types that are coverages (see 10.4) - by specifying references to other spatial objects (see Clause 13)

OK

34 Temporal characteristics of a spatial object shall be expressed in an application schema in one of the following ways depending on the requirements: - by specifying properties of the spatial object type with a value that is a temporal

geometry or a temporal topology (see ISO 19109 8.6; note that time is a dimension analogous to any of the spatial dimensions and that time, like space, has geometry and topology);

- by specifying properties of the spatial object type with a value that is one of the basic types Date, DateTime and Time. However, this makes the attribute a “thematic attribute” instead of a “temporal attribute” in terms of the General Feature Model, as there is no temporal reference system connected to them (see note in ISO 19109 8.6.1). As a result, using this method is only allowed if these properties are not intended to relate two spatial objects temporally based on the values of this property. The Gregorian calendar shall be the default calendar, UTC the default time zone.

To check

10.4 Rules for use of coverages n/a

35 Any description of coverages shall be in accordance with the specifications given by ISO 19123.

36 An application schema package that uses coverages shall follow the rules of ISO 19109 8.2.5 for referencing standardized schemas, i.e. import the coverage schema specified by ISO 19123.

37 A coverage shall be defined as a subtype of CV_Coverage. Valid coverage types, which shall be applied if applicable, are given in Table 2.

10.6 Geographic identifiers n/a

38 At least, a multilingual gazetteer of geographic names (or a harmonised set of such gazetteers) shall be established as part of INSPIRE.


31/08/2009 of 84

11. Multilingual text and cultural adaptability

11.1 Multilingual and multicultural requirements 39 For all geographical names and exonyms the support for multilingual text shall be

considered. n/a

40 Geographical names shall not be translated. Only exonyms should be used, if any. n/a

41 There shall not be a limitation to the number of names in different languages for

one spatial object. OK

42 The types specified in 11.2 shall be used in application schemas whenever the

value of a property is linguistic text, i.e. text in one or more languages.

43 Mixing different languages in a single character string is not allowed.

44 Free text attributes in application schemas shall be avoided as far as possible; the

use of controlled lists and thesauri is recommended whenever possible.

45 Object properties which are linguistic text shall be analysed, if the property needs

to support a single language text or if the property is of 'multilingual' interest.

46 Codelists in INSPIRE application schemas shall be multi-lingual and use short

names for every entry in the codelist. OK

47 In an INSPIRE application schema, English shall be used for class, attribute and

association role names throughout the UML model. OK

11.2 Multilingual extensions 48 PT_FreeText from the conceptual model specified in ISO/TS 19139 shall be used

as the data type for multilingual text and LocalisedCharacterString for linguistic text. LocalisedCharacterString is a character string with a locale. A locale is a combination of language, potentially a country, and a character encoding (i.e., character set) in which localised character strings are expressed.

49 The conceptual model for multilingual dictionaries for coordinate reference

systems, units of measurement, and codelists shall use the conceptual model for such dictionaries specified in ISO/TS 19139.

To check

To check if GeoSciML vocabulary are ISO 19139. GeoSciML vocabularies inherit from AnyDictionary defined in ISO 19136.


31/08/2009 of 84

12. Coordinate referencing and units of measurement model

12.2 Spatial coordinate reference systems and coordinate operations 50 Spatial coordinate reference systems shall be described using the current revision of

ISO 19111 where the spatial reference system falls within the scope of ISO 19111. OK

51 To support the ESDI, an ISO 19135 conformant register and registry for spatial

reference systems and transformations between the systems shall be established as part of INSPIRE.

52 The register shall at least contain reference systems that are valid across Europe.

The EUREF list of coordinate reference systems (see Clause 2) shall be part of the starting set of the register.

To do

53 Every INSPIRE data specification shall specify the list of coordinate reference

systems that may be used in the encoding of spatial objects defined by that data specification.

54 Every INSPIRE data specification shall specify the list of reference systems that may

be used to query spatial objects defined by that data specification in a request to a download service.

To do

12.3 Temporal reference systems 55 Temporal reference systems shall be described using the model specified in ISO

19108 5.3 (TM_ReferenceSystem). To check

56 To support the ESDI, an ISO 19135 conformant register and registry for temporal

reference systems and conversions between the systems shall be established as part of INSPIRE.

57 The register shall contain as the base temporal coordinate reference system the

current calendar (with support for the different time zones). INSPIRE data specifications shall define their required additional reference systems, if any

58 Every INSPIRE data specification shall specify the list of temporal reference systems

that may be used in the encoding of spatial objects defined by that data specification. To do

12.4 Units of measurement 59 Units of measurements shall be described using the model contained in ISO 19136

D.3.15. OK

60 To support the ESDI, an ISO 19135 conformant register and registry for units and

conversions for commonly used units shall be established as part of INSPIRE.

61 Every unit that may be used in spatial data sets shall be registered during the

development of the INSPIRE data specifications. To do

12.5 Geographical grid systems 62 Every INSPIRE data specification that specifies gridded coverages shall specify the

geographical grids that may be used in the encoding of spatial objects defined by that data specification.


31/08/2009 of 84

63 The coordinate reference system used in any grid shall be registered in the INSPIRE coordinate reference system register.

16. Identifier management

16.1 General requirements 64 Unique identification shall be provided by external object identifiers, i.e. identifiers

published by the responsible data provider with the intention that they may be used by third parties to reference the spatial object within INSPIRE.

OK

65 All spatial objects of Annexes I and II of the INSPIRE Directive shall carry a unique

object identifier property, unless it is known that no requirement exists to identify or reference such object instances.

OK

66 Uniqueness: No two spatial objects of spatial object types specified in INSPIRE

application schemas shall have the same identifier. OK

67 Persistence: The identifier shall remain unchanged during the life-time of an object.

The definition of every spatial object type in an INSPIRE application schema shall state which modifications (e.g. attribute changes, merging with another spatial object) do or may change the identity of a spatial object, i.e. when the existing object is "retired" and a new object with a new identifier is created, and which changes do not change the identity of a spatial object.

68 The life-cycle rules for spatial object types in a spatial dataset shall be documented in

the metadata of the dataset. To do

69 Traceability: Since INSPIRE assumes a distributed, service-based SDI, a mechanism

is required to find a spatial object based on its identifier. I.e. the identifier shall provide sufficient information to determine the download service that provides access to the spatial object.

To do

16.2 Structure of unique identifiers 70 Unique identifiers of spatial objects shall consist of two parts:

- a namespace to identify the data source (owned by a data provider) - a local identifier, assigned by the data provider (must be unique within the namespace)

OK

GeoSciML suggest the use of urn 71 For all spatial objects, the namespace shall include all relevant information to

guarantee uniqueness of the full identifier.

Cf 70 72 All namespaces shall start with a code that unambiguously identifies the data provider Cf 70

73 In case of a data provider associated with a member state this shall be the two letter ISO 3166 code which shall be registered in a register for object identifier namespaces in INSPIRE.

To do

74 In case of a multinational data provider it shall be a six letter code starting an

underscore ("_") to avoid conflicts with ISO 3166. The codes shall be registered in a register for object identifier namespaces in INSPIRE.

To do

75 All remaining characters of the namespace shall uniquely identify the data source

within the member state (or multinational organisation).


31/08/2009 of 84

76 To support the ESDI, an ISO 19135 conformant register and registry for identifier namespaces shall be established as part of INSPIRE. The register shall provide sufficient information about the data provider and about the download service that provides access to these spatial objects.

To do

77 As a result, the identifier management will be co-ordinated in the sense that every

data provider in INSPIRE - shall register their identifier namespaces in the appropriate INSPIRE identifier namespace register, - can assign local identifiers arbitrarily within namespaces owned by the data provider as long as each identifier is used only once.

To do

16.4 Spatial datasets 78 The rules for unique identifiers of spatial objects shall apply for spatial datasets, too. To do

16.5 Coverages 79 The rules for unique identifiers of spatial objects shall apply for coverages, too.

16.6 Versions of spatial objects 80 In case the application schema supports versioning of a spatial object type, a version

identifier shall be used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier shall be unique.

To do

81 The version identifier shall be a character string with a maximum length of 25

characters.

82 The version identifier shall not be considered part of the unique identifier of a spatial

object.

18. Metadata 83 Metadata associated with individual spatial objects shall be specified as part of the

INSPIRE data specifications as required by the application and by ISO 19131. To do

84 The rules specified in ISO 19109 8.5.2 shall apply for INSPIRE application schemas. To do

19. Maintenance 85 Maintenance requirements shall be specified as part of every INSPIRE data

specification as required by ISO 19131. To do

86 In particular, it shall be specified for every spatial object type by every data provider

as part of the data set metadata which properties of a spatial object type are invariant for a spatial object type (if any); i.e., a change of these properties will lead to a new object instance with a new unique object identifier.

To do

20. Data & Information quality 87 Quality requirements for spatial data sets shall be specified as part of every INSPIRE

data specification as required by ISO 19131. To do

22. Consistency between data 88 The first consistency to check is the conformance to data specifications including the

data capturing rules. Before checking the consistency between different data sets, To do


31/08/2009 of 84

each data set shall be verified to conform to the corresponding INSPIRE application schema, in particular complying to the same set of constraints.

89 For the consistency checks, an interlinked and agreed vocabulary is needed.

Therefore, the rules governing consistency shall be modelled as far as possible in the INSPIRE application schemas as constraints. The constraint language OCL shall be used to express these constraints, associated with natural language to give the complementary explanation. The constraints shall be identified as part of the development of the INSPIRE data specifications.

To do

23. Multiple representation 90 Multiple representations of the same real-world phenomenon shall be modelled

explicitly in the application schemas. For consistency between the representations, the rules specified in Clause 22 shall apply.

91 In principle, as few levels of detail as necessary should be defined per theme. In

cases where multiple levels of detail are required, the requirement for the different levels shall be justified and documented as part of the data specification

24. Data capturing rules 92 Capturing rules describing the data specification-specific criteria which spatial objects

are part of spatial data sets conforming to the data specification shall be specified for every spatial object type as part of every INSPIRE data specification in conformance with ISO 19131.

To do

25. Conformance 93 Every INSPIRE data specification shall conform to all mandatory requirements in this

document that relate to INSPIRE data specifications and pass all relevant test cases of the Abstract Test Suite in A.1.

To do

94 Every spatial data set shall conform to all mandatory requirements in this document

that relate to data sets and pass all relevant test cases of the Abstract Test Suite in A.3.

To do


31/08/2009 of 84

11 ANNEXE B – Examples of mapping to GeoSciML

Examples of mapping between national data models to GeoSciML

In this annexe several Geological surveys explain how they mapped their national data

(structure and content) to GeoSciML. This mapping is both a structure mapping and a

semantic mapping. It seems difficult to separate them because some national terms

could be mapped using two GeoSciML elements (for example Lithology and Genesis).

During the implementation phase, there is a need to agree how the mapping is done to

resolve this.

11.1 Example from BRGM (France)

Authors: Dominique Janjou, Florence Cagnard (BRGM)

This chapter provides an example of mapping between the French national data model

to GeoSciML. The mapping needs two kinds of operations:

- to map the national data structure to the GeoSciML data structure. During this

operation some fields from the database have to be divided or merged

- to map national values to 1GE common values

Within the project (and especially within the Work Package 3), it has been suggested

that common data which will be shared are:

- The lithology

- The age

- The genetic category

- The event-process & event-environment.

11.1.1 Lithology

The main goal of this work is to find correspondences between “initial” lithologies from

the European geological maps and terms in GeoSciML (Figure 1). It is firstly required

to split complex “initial” lithologies in different single lithologies (ex: aplopegmatites

become aplites and pegmatites) (Figure 1).


31/08/2009 of 84

Figure 1: Process for providing correspondence for lithologies between geological maps and GeoSciML

The GeoSciML’s glossary for lithologies is very synthetic, and does not provide all the

lithological terms used in different geological maps of European countries.

►For some lithologies (and especially for magmatic rocks), corresponding terms exist

between GeoSciML and geological maps.

Examples: - Granite (BRGM) → Granite (GeoSciML)

- Andesite (BRGM) → Andesitic rock (GeoSciML)

- Breccia (BRGM) → Breccia (GeoSciML)

- Mylonite (BRGM) → Mylonitic rock (GeoSciML)

► However, sometimes there is no direct correspondence between the lithological

terms from geological maps and lithologic glossary from GeoSciML. In such case, it

is necessary to find the most relevant term within the “Simple-Lithology” glossary and

to specify this term with attributes from other glossaries, like “Metamorphic-

Description”, “Physical-Description”, “Compound-Material”, “Fabric-Description”,

“Rock-Material”, “Constituent-Part” (Figure 1). We will consider few examples.


31/08/2009 of 84

Example 1: Blueschists (Figure 2)

- Blueschists (BRGM) → ? (GeoSciML)

Because of the absence of the concept of “blueschists” in lithological glossary from

GeoSciML, we considered that a blueschist is at first order schist (“Simple-Lithology” -

GeoSciML). Characteristics of such schist can be specified by the “Metamorphic-

Grade”, the “Metamorphic-Facies”, the “P-T peak conditions” and the “Protolith-

Lithology”, as well as by the “Genetic-Category” (Figure 2). With such attributes, we

obtain that the considered rock is a schist, with glaucophane, of low metamorphic grade

(and eventually with the defined nature of protolith and PT conditions), formed during a

regional metamorphism (Figure 2). At the end of the process, the name of “blueschists”

disappears but can be deduced from the attributes.

Figure 2: Example of GeoSciML use to define a complex lithology (ex: blueschists)

Example 2: Eclogite-facies metagabbros (Figure 3)

- Eclogite-facies metagabbros (BRGM) → ? (GeoSciML)

Because of the absence of the concept of “eclogite-facies metagabbros” in lithological

glossary from GeoSciML, we considered that such rocks are at first order metamorphic

rocks (“simple lithology” - GeoSciML). Characteristics of such metamorphic rock can

be specified by the “Metamorphic-Grade”, the “Metamorphic-Facies”, the “P-T peak

conditions” and the “Protolith-Lithology”, as well as by the “Genetic-Category” (Figure

3). With such attributes, we obtain that the considered rock is a metamorphic rock, with

an eclogitic metamorphic facies, of high metamorphic grade and with a protolith of

gabbroic nature, formed during a regional metamorphism (Figure 3). At the end of the

process, the name of “eclogite-facies metagabbros” disappears but can be deduced from

the attributes.


31/08/2009 of 84

Figure 3: Example of GeoSciML use to define a complex lithology (ex: eclogite-facies

metagabbros)

Example 3: Gypsum (Figure 4) - Gypsum (BRGM) → ? (GeoSciML)

Because of the absence of the concept of “gypsum” in lithological glossary from

GeoSciML, we considered that such rocks are at a first order an evaporite (“Simple-

Lithology” - GeoSciML). Characteristics of such evaporite can be specified by the

“Composition-Category”, the “Genetic-Category” and could be thoroughly specified by

their mineralogy (not represented on the figure 4) (Figure 4). With such attributes, we

obtain that the considered rock is an evaporite, with sulphate chemistry, a chemical

sedimentary genesis (Figure 4), and a defined mineralogy. At the end of the process, the

name of “gypsum” disappears but can be deduced from the attributes.


31/08/2009 of 84

Figure 4: Example of GeoSciML use to define a complex lithology (ex: gypsum)

► Such examples underline the necessity to use different attributes in the

Earthmaterial package of GeoSciML. The use of the only “Simple-Lithology”

glossary of GeoSciML is a strong limitation in the definition of lithologies from

geological maps. In order to conserve the initial information, we need to specify the

generic concepts of lithologies in GeoSciML by associated available attributes.

11.1.2 Age

GeoSciML provides a structure to the age (through a GeologicalEvent) :

preferredAge / GeologicEvent:

- eventAge

- eventProcess (see following chapter)

- eventEnvironnement (see following chapter)

The operation of mapping the age is to find a correspondence between the “national”

age stored in the BRGM database and an age defined in the International Chart of

Stratigraphy (2008) used in GeoSciML.


31/08/2009 of 84

There are two possible issues for this mapping:

- the age used is a “local” age, so we should find the acceptable term in the ICS (ex:

the French “Stampien” corresponding to “Rupelian” in the ICS

- the accuracy of the ICS does not fit with our requirements (ex: for Scandinavian

countries the Precambrian is not detailed enough) then we should ask for an

update of the ICS. And waiting this 1GE / WP3 will update the ICS for the

project.

11.1.3 Genetic category

The attributes from the GeoSciML’s “Genetic-Category” summarize the geologic

history of an Earth material. Such attributes include igneous, sedimentary,

metamorphic, shock metamorphic, volcanic, pyroclastic genetic process.

No major problem exists concerning such glossary and the correspondence between

lithologies of the geological maps and “Genetic-Category” from GeoSciML is often

obvious. Some examples are as follows:

Lithologies (BRGM) GeneticCategory (GeoSciML)

Granitoid 2.2. Igneous intrusive genesis

Basalts 2.1. Igneous extrusive genesis

Breccia 6.2. Cataclastic genesis

Reef limestone 4.2. Biological sedimentary genesis

Calcschists 8.3. Metasedimentary genesis

Metadiorites 8.2.2. Metaplutonic genesis

Orthogneiss 8.2. Metaigneous genesis

Sand 4.1. Clastic sedimentary genesis

Tuffites 8.1.1 Volcaniclastic genesis

Eclogites 5.2. Regional metamorphic genesis

Impactites 7. Impact genesis

11.1.4 Event process and Event environment

Event-Process

In this glossary, we find vocabulary concerning geological process associated with a

special geologic event. Any geologic age assignment is associated with an event, the

process property values specifies what happened during that event. The vocabulary used

in this glossary represents the most significant feature in the genesis of geologic

structures or geologic units.

An “Event-Process” is a function, possibly complex, that acts on one geologic entity to

produce another geologic entity at a later time. An Event-Process is time independent;

some “Event-Processes” are presently observable in the world or in the laboratory,

others can only be inferred from observing the results of the process. Processes take one

or more of “Earth-Material”, “Geologic-Unit”, or “Geologic-Structure” as input and

have one or more of “Earth-Material”, “Geologic-Unit” or “Geologic-Structure” as

output.

Some examples of correspondence between geological maps and GeoSciML are as

follows:


31/08/2009 of 84

Geodynamics (BRGM) Event-Process (GeoSciML)

Oceanic accretion 10.6. Spreading

Continental collision 10.2. Continental collision

Continental extension 10. Tectonic process

Event-Environment

In this glossary, we find vocabulary concerning populating event environment

properties in GeoSciML documents. Such vocabulary describes the physical settings

within which a “Geologic-Event” takes place. The glossary “Event-Environment” is

built broadly to include physical settings on the Earth surface specified by climate,

tectonics, physiography or geography, and settings in the Earth’s interior specified by

pressure, temperature, chemical environment, or tectonics.


follows:

Geodynamics (BRGM) Event-Environment (GeoSciML)

Continental 1.2.0 Terrestrial setting

Littoral 05.0.0 Shoreline settings

Continental shelf 03.01.14 Continental shelf setting

11.2 Example from SGU (Sweden)

Authors: Stefan Bergman, Claes Mellqvist, Benno Kathol (SGU)

The objective of this document is to provide three examples of mapping between a

national data set to GeoSciML. We have chosen one simple and two complex

geological units from Geological map of the Fennoscandian Shield (Koistinen, T., Stephens, M.B., Bogatchev, V., Nordgulen, Ø., Wennerström, M., Korhonen, J., 2001. Geological map of the Fennoscandian Shield, scale 1:2 000 000. Geological Surveys of Finland, Norway and Sweden and the North-West Department of Natural Resources of Russia). Working material from the data specification provided by Work Package 3 has

been used. This includes terms from the CGI Geoscience Concept definitions working

group vocabularies listed below:

GeoSciML data structure Vocabulary used Header in Examples 1-3

"GEOLOGIC UNIT" Composition Part / Lithology

SimpleLithology200811 Lithology

"GEOLOGIC UNIT" Metamorphic description / Metamorphic grade

MetamorphicGrade (from discussion page)

Met. Grade

"GEOLOGIC UNIT" Metamorphic description / Protolith lithology

SimpleLithology200811 Protolith

"EARTH MATERIAL" Compound material / Composition category

CompositionCategory200811 Composition

"EARTH MATERIAL" Compound material / Genetic

GeneticCategory200811 Genetic


31/08/2009 of 84

category

"GEOLOGIC AGE" Geologic event / Event process

EventProcess200811 Process

"GEOLOGIC AGE" Geologic event / Event environment

EventEnvironment200811 Environment

"GEOLOGIC AGE" Geologic event / Event age

ICS Stratigraphic Chart (extended with WP3 working material Precambrian Epochs)

Max age / Min age

Within the project ONE GEOLOGY EUROPE (and especially within the Work

Package 3), it has been suggested that common data which will be shared are:

- The lithology

- The age



- The metamorphic grade

WP3 decided that to each polygon one main rock type and up to four secondary rock

types should be assigned.

In the following three examples we suggest how some parts of the legend could be

mapped. We also give some comments on the different obstructions we have

experienced..

Ages for major tectonic events are included in the map database but not in the map

legend. These ages are used as metamorphic ages in the mapping.

We also found it useful to include the protolith of metamorphic rocks and a description

of the composition of the lithology

11.2.1 Results of the mapping exercise

Example 1: Granite, pegmatite (c. 1.85-1.75 Ga)

Granite is chosen as the main rock type and pegmatite as the secondary rock type.

Identical attributes for genetic category, process, environment and age are applicable

for both rock types

Example 2a: Granite, granodiorite, quartz monzonite, monzonite, syenite and

metamorphic equivalents, in parts hypersthene-bearing (1.86-1.84 and 1.82-1.76 Ga)

The result is a total of twenty rocks depending on the expression “metamorphic

equivalents” and the two ranges of ages. We did not find a way to account for “in part

hypersthene-bearing” and the information was lost. If this information was available in

a separate list of minerals, another twenty rocks would have to be added. Complex age

designation such as “1.86-1.84 and 1.82-1.76 Ga” cannot be accounted for precisely.

Consequently, a repetition of the different rocks was necessary to describe both ranges

of ages. “Quartz monzonite” is not included in SimpleLithology200811 so a more

general term must be used and information is lost. This also affects the name of the


31/08/2009 of 84

protolith for the metamorphic equivalent. In example 2b, the description above is

simplified to be presented by only four different rock types. The restriction in 1GE to

use only five rock types for a geologic unit leads to loss of information. We have used

Granitic and Syenitic rock and metamorphic equivalents. The two age-ranges are

combined which makes the age description less specific.

Example 3: Red sandstone and mudstone, conglomerate, metasandstone, quartzite,

phyllite, volcanic and metavolcanic rocks

It is the most complete mapping that describes these eight rock types. The sedimentary

rocks are mapped without major problem, although the colour of the sandstone remains

undescribed. Also, it is not clear whether the best genetic category is the depositional

Clastic sedimentary genesis or the Diagenetic genesis, which relates to the lithification.

Metasandstone is mapped as Metamorphic rock with Sandstone as protolith. We did not

find a way to further describe e.g. the depositional environment and depositional age of

the protolith. The genetic category can be either Metasedimentary genesis or Regional

metamorphic genesis. Volcanic rock is not in the SimpleLithology200811 vocabulary

but can be mapped as Fine grained igneous rock with Igneous extrusive genesis.

Metavolcanic rock is best described as Metamorphic rock with Fine grained igneous

rock as protolith and Metavolcanic genesis. As in the metasandstone case the

depositional age cannot be given.

The additional requirement of a maximum of five lithologies can be handled in two

ways. One way is to choose the five most important lithologies and omit the remaining

three. The other way is to include two or more lithologies into a broader description.

This alternative is given as Example 3b. It is clear much information (e.g. grain size) is

lost using this approach.

11.2.2 Comments

The problems we found were of two main categories. The first is loss of information

because of high detail of original description:

- List of mineral names is missing which leads to information loss.

- Complex age designations cannot be accounted for precisely.

- Many names of rocks are not included in SimpleLithology200811 in some cases a

more general term must be used and the detailed information is lost.

- The way to describe the protolith of a metamorphic rock is highly restricted.

- The restriction in 1GE to use only five rock types for a geologic unit leads to loss

of information.

The second kind of problem concerns ambiguity of classification:

- For genetic categorisation of e.g. a regionally metamorphosed sandstone, there is

the choice to use “metasedimentary genesis” or “regional metamorphic genesis”.

Which one (or both ?) should be used?

- For lithified sedimentary rocks there is the choice to use a primary genetic

category (e.g. clastic sedimentary) or a secondary genetic category (diagenetic).

Which one (or both?) should be used?


31/08/2009 of 84

11.3 Example from Czech and Slovak Geological Surveys

Authors: Petr Coupek, Robert Tomas, Lucie Kondrova (CGS)

The main focus during this work was on the mapping of the data from the map legends

of two overview geological maps.

Data sources: - Digital maps

� Geological Map of the Czech Republic , ISBN: 978-80-7075-699-7 (Cháb et

all.) at a scale of 1: 500 000

� the digital version of The West Carpathians map and adjacent areas (2000,

Lexa et all) at a scale of 1:500 000

- Geological legends

� text legend of the Czech geological map as connected feature table,

� text legend of the Slovak geological map as connected feature table

- Codebooks (the source map legends were available only as simple feature tables,

with no detailed structure and without any database relation)

� codebook HORNINY for lithology classification

� codebook STRAT_VSE for (chrono-) stratigraphy terms

11.3.1 Process of the mapping into GeoSciML

Construction of the GeoSciML vocabularies for (chrono-) stratigraphy and

lithology description

At the Czech Geological Survey there exists a set of national widely used codebooks for

description and classification of geological terms. The tables HORNINY (291 items in 8

categories of rocks) and STRAT_VSE (223 stratigraphics items) from this set were the

data sources for appropriate GeoSciML vocabularies but the correct English translation

of each term was needed. Vocabularies were registered at BRGM:

urn:cgi:classifierScheme:CGS:CzechLithology:2009.xml

urn:cgi:classifierScheme:CGS:CzechStratigraphy:2009.xml

Technically, the GeoSciML vocabulary is an XML document generated directly from

the existing database schema KODOVNIK_GEO using server scripting. The primary index for terms is a unique number with defined internal structure – this differs from the

BGS philosophy to use the term name as the primary index.

Conclusion: the plan is to make all the national codebooks as GeoSciML vocabularies

to support wide range of GeoSciML documents. To be able to do that, it is necessary to

translate all terms into English.

The categorization

The text terms from the map legend were mapped into appropriate set of terms from the

vocabulary with an essential help of an expert geologist.

Conclusion: Using the categorization is essential for the support of the appropriate

GeoSciML output.

Generating the WFS service with GeoSciML content

Map legend is served in GeoSciML according to the Cookbook[1]

recommendations:


31/08/2009 of 84

- Mapped Features have text descriptions and the following categorization:

� (Chrono-)Stratigraphy is represented as one term or an interval “from-to” using

categories from the vocabulary,

� Lithology is a (non-empty) set of lithology items (=rocks descriptions) from

vocabulary (no relations or attributes).

- WFS is generated with an essential help of the PostGIS database (space tasks) using

custom written script. The technical solution may differ in the final solution.

[1]

GeoSciML Cookbook : How To Serve a GeoSciML Version 2 Web Feature Service

(WFS) using Open Source Software (version 1.1)


31/08/2009 of 84

Example:

<gsml:specification> <gsml:GeologicUnit gml:id="gu.id.6335">

<gml:description> UPPER CRETACEOUS (Turonian) glauconite-bearing, calcareous and clayey sandstones, marlstones, locally siliceous (grading into spiculites), with chert beds

</gml:description> <gsml:observationMethod>

<gsml:CGI_TermValue> <gsml:value codeSpace="urn:cgi:classifier:CGS:ObservationMethod"> Summary of published description</gsml:value>

</gsml:CGI_TermValue> </gsml:observationMethod> <gsml:purpose>instance</gsml:purpose> <gsml:preferredAge>

<gsml:GeologicEvent> <gsml:eventAge>

<gsml:CGI_TermValue> <gsml:value codeSpace="urn:cgi:classifierScheme:CGS:CzechStratigraphy"> SXK2T</gsml:value>

</gsml:CGI_TermValue> </gsml:eventAge> <gsml:eventProcess>

<gsml:CGI_TermValue> <gsml:value codeSpace="http://urn.opengis.net"> urn:ogc:def:nil:OGC:unknown</gsml:value>

</gsml:CGI_TermValue> </gsml:eventProcess>

</gsml:GeologicEvent> </gsml:preferredAge> <gsml:geologicUnitType xlink:href="#lithostratigraphic_Unit"/> <gsml:rank codeSpace="urn:cgi:classifierScheme:CGS:Rank">FORMATION</gsml:rank> <gsml:classifier xlink:href=""/> <gsml:composition>

<gsml:CompositionPart> <gsml:role codeSpace="urn:cgi:classifier:CGI:GeologicUnitPartRole">only_part</gsml:role> <gsml:lithology xlink:href="urn:cgi:classifierScheme:CGS:CzechLithology:143"/>

</gsml:CompositionPart> <gsml:CompositionPart>

<gsml:role codeSpace="urn:cgi:classifier:CGI:GeologicUnitPartRole">only_part</gsml:role> <gsml:lithology xlink:href="urn:cgi:classifierScheme:CGS:CzechLithology:131"/>

</gsml:CompositionPart> <gsml:CompositionPart>

<gsml:role codeSpace="urn:cgi:classifier:CGI:GeologicUnitPartRole">only_part</gsml:role> <gsml:lithology xlink:href="urn:cgi:classifierScheme:CGS:CzechLithology:126"/>

</gsml:CompositionPart> </gsml:composition>

</gsml:GeologicUnit> </gsml:specification>

The Slovak map uses the same set of vocabularies as the Czech one.


31/08/2009 of 84

11.3.2 Used technology

- Postgres SQL 8.3 with PostGIS 1.3.6 extension (essential)

- Perl 5.8 using DBI, XML::Twig (essential), Locale:Recode etc. Libraries

- Geoserver 1.7.3 for supporting WMS

- Apache TomCat , pre cached map tiles GWC

- own WFS script written in Perl and supporting OCG filter and read only WFS

- Map cache for caching generated map tiles

- On client side supporting XHTML application based on OpenLayers javascript

library

11.4 Example from ISPRA (Italy)

Authors: Carlo Cipolloni, Marco Pantaloni (ISPRA)

This part of the document provides how Geological Survey of Italy could map the

national database builds with the Geological Map of Italy at the scale 1:1.000.000

(Bonomo et alii, 2004) with the GeoSciML Model.

To map the national data structure to the GeoSciML data structure we need to identify

which fields have information useful for GeoSciML. During this operation some fields

from the database have to be divided or merged specially for the lithology and event-

process.

The information useful for GeoSciML model should be properly stored in different

table build we the source dataset.

Within the project (the deliverable D3.1 from Work Package 3 that show in detail the

geologic information useful), it has been suggested that common data which will be

shared are:

- The lithology

- The age



- The metamorphic grade

We present in below section some examples how Italian database was mapped.

11.4.1 Lithology

The main goal of this example is to show how re-build the correspondences between the

Italian database lithological information (mainly not stored as single term the lithology)

and the project common schema, so we have split our lithostratigraphic information in 5

order of lithology using directly the CGI vocabulary terms. Sometimes the terms not

found a perfect correspondence with CGI vocabulary, in this case we have developed an

ontology mapping file to easily match the correspondence. To map in this project

directly the URN lithology we have create a “bridge” table also to reproduce the

attribute. The main problem in the construction of the database is concerning the role

that each lithology have in the geologic unit, because the order not almost is correlate


31/08/2009 of 84

with the importance of proportion. In our case the lithology order is due to the order of

appearance in the geologic unit description and the role is stored in analogical form as

map procedure building method. In this case we have need of a bridge table between the

original database and GeoSciML using the Cod_Lege identification number that is

strongly correlated to geologic field information and the Lithology attribute take from

the lithostratigraphic. In the schema of procedure (shown in figure 1) the blue line

identifies the process to build lithology urn, while the red line represents the procedure

to recover the proportion role of each lithology.

Figure 1: Procedure schema for providing correspondence for lithology between geological maps and GeoSciML.

We present 3 examples of the lithology mapping:

Example 1: Detrital and organogenic limestones, marly limestones, marls, pelites, sands and conglomerates, locally with olistostromes.

Before we have split the lithostratigraphy description in order of appraising in 5 order

and we have found the first problem due to the complexity of our information that are

more then the simple 5 lithology classification. We have decided to unify the pelites and

the marls in one term: “marls”. The results based on the ontology map file (shown as

example in the figure1) are:


31/08/2009 of 84

Lithologies (ISPRA)

Mapped terms (CGI SimpleLithology200811 vocabulary)

Final URN CGI:SimpleLithology200811

Limestones (Calcari)

calcareous carbonate sedimentary rock

urn:cgi:classifier:CGI:SimpleLithology:200811: calcareous_carbonate_sedimentary_rock

Marly limestones (Calcare marnoso)

Mudstone urn:cgi:classifier:CGI:SimpleLithology:200811:mudstone

Marls (marna) Marl (proposed by WP3 in pending for CGI-GeoSciML)

urn:cgi:classifier:CGI:SimpleLithology:200811:mud

Sands (sabbia) sand urn:cgi:classifier:CGI:SimpleLithology:200811:sand

Conglomerates (conglomerato)

conglomerate urn:cgi:classifier:CGI:SimpleLithology:200811:conglomerate

Example 2: Diorites and gabbros

This example is an easily match situation, because both the terms are already present in the

CGI SimpleLithology200811 vocabulary.

Lithologies (ISPRA)


Final URN CGI:SimpleLithology200811

Diorites (diorite) diorite urn:cgi:classifier:CGI:SimpleLithology:200811:diorite

Gabbros (gabbro) gabbro urn:cgi:classifier:CGI:SimpleLithology:200811:gabbro

Example 3: Monzonites, quartz diorites, monzodiorites and monzogabbros

The last example not has a simple correspondence in the CGI vocabulary, because some

facies conditions are not directly stored in the lithology terms in the GeoSciML model. These

information is allocated in the MetamorphicFacies attribute in the

EarthMaterial/MetamorphicDescription structure part (as shown figure1).

In the WP3 are proposed as extend of SimpleLithology vocabulary the use of some new terms

as suggests the blue row in the table. The red line identifies how without the new terms we

have decided to map the national lithologies in CGI terms.

Lithologies (ISPRA)


Final URN CGI:SimpleLithology200811:

Monzonites (monzonite)

Monzonite urn:cgi:classifier:CGI:SimpleLithology:200811:monzonite

Quartz diorites Dioritic rock urn:cgi:classifier:CGI:SimpleLithology:200811:dioritic_rock

Monzodiorites (monzodiorite)

monzodiorite (proposed by WP3 in pending for CGI-GeoSciML)

urn:cgi:classifierScheme:ISPRA:SimpleLithology:2009:monzodiorite?

Monzogabbros monzogabbro (proposed by urn:cgi:classifier:CGI:SimpleLithology:200811:gabbro


31/08/2009 of 84

(monzogabbro) WP3 in pending for CGI-GeoSciML)

urn:cgi:classifierScheme:ISPRA:SimpleLithology:2009:monzogabbro?

11.4.2 Age

The GeoSciML model provides a structure to the age (through a GeologicEvent class):

preferredAge / GeologicEvent:

- eventAge

The eventAge is expressed by a numerical value that defining the start and the end of an

event that depends to the preferredAge which use a CGI term defined in the

International Chart of Stratigraphy (2008) used in GeoSciML.

To identify a correspondence between the “national” age terms stored in the our

database and the CGI SimpleLithology200811 vocabulary we have build an ontology

mapping file that trough a procedure transforms the national terms in Italian language

directly in CGI SimpleLithology200811 URN.

The mapping ontology file allows matching the age using the time period consideration

and the composition of the chronostratigraphy chart, in figure 2 is shown an example

how Italian database is configured to match data in GeoSciML and an example of part

of the ontology mapping file.

Figure 2: Process for providing correspondence for age between national stratigraphy and the International Chart of the stratigraphy adopted by the GeoSciML.


31/08/2009 of 84

11.4.3 Genetic category

The attributes from the GeoSciML’s “Genetic-Category” summarize the geologic

history of an Earth material and use such attributes include igneous, sedimentary,

metamorphic, shock metamorphic, volcanic, pyroclastic genetic process.

In our database the genetic category are stored in multiple-items as: depositional

environment, genetic-category, sometimes as metamorphic grade and, not find a direct

correspondence with the GeoSciML terms. Moreover we have more features stored in

an single field that are represented a composite of lithology and normally we have

decided to classify as base level of categories such Sedimentary, Metamorphic,

Volcanic and Plutonic. To explain better in table below we will show some examples.

Lithostratigraphic Unit (ISPRA)

Genetic category plus depositional environment (ISPRA)

GeneticCategory (GeoSciML)

Marls, pelites, sands and conglomerates, with gypsum

Sedimentary rocks/Marine deposits

4.0 Sedimentary genesis

Andesites, latiandesites and alkaline basalts: lavas and pyroclastic rocks

Volcanic rocks/Extrusive-volcanic

2.1. Igneous extrusive genesis (Not-totally correspondence)

Granites and granodiorites

Plutonic rocks/Intrusive-volcanic

2.2.1 Plutonic genesis

Micaschists, gneisses and migmatites

Metamorphic rocks/Various-grade

5.2 Regional metamorphic genesis (Not-totally correspondence)

Eclogitic schists and eclogites

Metamorphic rocks/Medium-grade (high pressure)

5.2 Metamorphic genesis

Alternating sandstones, quartzites and phyllites

Sedimentary rocks/Terrigenous Platform deposits with low-grade metamorphism (metamorphic grade associated)

8.3 Metasedimentary genesis

11.4.4 Event-Process

The geological process correlate to a geologic event is not a simple attribution, in fact to

a geologic unit corresponding one or more event-process. In our database the event-

process aren’t directly stored, however the information concerning the geologic process

are inside multi-attribute like the geologic unit description, environment of depositions,

orogeny cycle and specially in tectonic units table of the attribute.

We provide in follow table how the information stored of the event-process in our

database is transformed to match GeoSciML Model:

Geodynamics system (ISPRA)

Orogenitic Cycle (ISPRA)

Enviroment/ Metamorphic Grade (ISPRA)

Event-Process (GeoSciML)

Units descending from European

Alpine Orogeny

Medium-grade High Pressure

10.2. Continental collision


31/08/2009 of 84

continental crust Domains

Units descending from the Thetyan Ocean Domains

Pre-Alpine Orogeny Alpine Orogeny

Basinal and Slope deposits Low-grade

06.0 Deposition 11.0 Metamorphic process

Plutonic rocks Alpine Orogeny Intrusive-volcanic 09.1 Intrusion

11.4.5 Event-Environment

The Event-Environment in GeoSciML vocabulary represents the information

concerning the physical settings within which a “Geologic-Event” takes place.

The Italian database, generally presents a specific attribute filed or table where these

descriptions are stored; in particular the database of 1:1.000.000 Geological Map

(Geo1MDB) have a field that describes the environment of deposition or formation of

the specific geologic unit.


follows:

Environment (ISPRA) Event-Environment (GeoSciML) Continental deposits 1.2.0 Terrestrial setting

Marine deposits 03.01.0 Marine settings

Continental platform 03.01.16 Marine carbonate platform setting

Basinal, pelagic Platform 03.01.11 Basin plain setting

11.5 Example from BGS (UK)

Author: John Laxton (BGS)

BGS has decided that its primary input to 1GE will be the published 1:625k digital map,

which exists in bedrock and superficial deposit versions. The attributes available in this

data set will therefore be the starting point for mapping to GeoSciML. Table 1 lists the

attribute fields for the bedrock polygons of the 1:625k map and provides an explanation

of the content of each field.

Data field Explanation of data field

SHAPE Necessary for the ESRI shapefile format indicating polygon, polyline or point data.

LEX_ROCK A two-part code, LEX & ROCK, formerly used to label each polygon of DiGMapGB data and for creating map keys or legends.

LEX Lexicon (or LEX) code. First part of the LEX_ROCK label. Up to 5 characters (mostly letters). An abbreviation of the rock unit or deposit as listed in the BGS Lexicon of Named Rock Units: e.g. GOG.

LEX_D Description of the Lexicon code above giving the name of the unit: e.g. GREAT


31/08/2009 of 84

OOLITE GROUP is the full name of the unit coded as GOG.

LEX_RCS The two-part code, LEX & RCS, used to label each polygon of DiGMapGB data.

RCS The RCS code (or an abbreviation for the string of RCS codes given in full in RCS_X).

RCS_X RCS codes. An alternative code abbreviation (or a string of such codes joined by + signs with square brackets used for subordinate types), each up to 6 characters, for the type of rock or lithology as based on the hierarchical BGS Rock Classification Scheme (RCS): e.g. MDST + [CONG].

RCS_D Description of the RCS code(s) above giving the lithology of the unit: e.g. MUDSTONE (UNDIFFERENTIATED) with CONGLOMERATE is the description of the rock coded as MDST + [CONG].

RANK Rank of the unit in the lithostratigraphical or lithodemic hierarchy: e.g. GROUP or SUITE.

BED_EQ Bed equivalent. Lexicon code for the unit at bed or equivalent level where applicable.

BED_EQ_D Description of BED_EQ above; name of unit at bed level.

MB_EQ Member equivalent. Lexicon code for the unit at member or equivalent level where applicable.

MB_EQ_D Description of MB_EQ above; name at member level.

FM_EQ Formation equivalent. Lexicon code for the unit at formation or equivalent level where applicable.

FM_EQ_D Description of FM_EQ above; name at formation level.

SUBGP_EQ Subgroup equivalent. Lexicon code for the unit at subgroup or equivalent level where applicable.

SUBGP_EQ_D Description of SUBGP_EQ above; name at subgroup level.

GP_EQ Group equivalent. Lexicon code for the unit at group or equivalent level where applicable.

GP_EQ_D Description of GP_EQ above; name at group level.

SUPGP_EQ Supergroup equivalent. Lexicon code for the unit at supergroup or equivalent level where applicable.

SUPGP_EQ_D Description of SUPGP_EQ above; name at supergroup level.

MAX_TIME_D Maximum age of the unit, to the most accurate time (or geochronological) division possible: e.g. ASBIAN.

MIN_TIME_D Minimum age of unit, to the most accurate time (or geochronological) division possible: e.g. ALPORTIAN.

MAX_TIME_Y Maximum age, in years, of the oldest time division during which the geological unit was formed: e.g. 333800000.

MIN_TIME_Y Minimum age, in years, of the youngest time division during which the geological unit was formed: e.g. 320710000.

MAX_INDEX Maximum index. A number representing the maximum age (earliest time) of the unit: MAX_TIME_D field. Used for GIS querying and legend building: e.g. 1322120.


31/08/2009 of 84

MIN_INDEX Minimum index. A number representing the minimum age (latest time) of the unit: MIN_TIME_D field. Used for GIS querying and legend building: e.g. 1321340.

MAX_AGE Maximum age. Name of the age of maximum geochronological time applicable: e.g. ASBIAN.

MIN_AGE Minimum age. Name of the age of minimum geochronological time applicable: e.g. ALPORTIAN.

MAX_EPOCH Maximum epoch. Name of the epoch of maximum geochronological time applicable: e.g. VISEAN.

MIN_ EPOCH Minimum epoch. Name of the epoch of minimum geochronological time applicable: e.g. NAMURIAN.

MAX_SUBPER Maximum sub-period. Name of the sub-period of maximum geochronological time applicable: e.g. DINANTIAN.

MIN_SUBPER Minimum sub-period. Name of the sub-period of minimum geochronological time applicable: e.g. SILESIAN.

MAX_PERIOD Maximum period. Name of the period of maximum geochronological time applicable: e.g. CARBONIFEROUS.

MIN_ PERIOD Minimum period. Name of the period of minimum geochronological time applicable: e.g. PERMIAN.

MAX_ERA Maximum era. Name of the era of maximum geochronological time applicable: e.g. PALAEOZOIC.

MIN_ERA Minimum era. Name of the era of minimum geochronological time applicable: e.g. MESOZOIC.

MAX_EON Maximum eon. Name of the eon of maximum geochronological time applicable: e.g. PROTEROZOIC.

MIN_EON Minimum eon. Name of the eon of minimum geochronological time applicable: e.g. PHANEROZOIC.

PREV_NAME Previous name(s) for the unit as listed in the BGS Lexicon of Named Rock Units.

BGSTYPE The DiGMapGB theme e.g. bedrock, superficial, mass movement or artificial.

LEX_RCS_I Concatenation of Lexicon and RCS codes, plus the maximum index number.

LEX_RCS_D Description of Lex_RCS above.

BGSREF BGS Reference colour for the polygon based on the LEX_ROCK code pair. The default printing colour defined as a 3-digit number: e.g. 434 (for Claygate Member_mudstone and sandstone). Used for legend building to give a similar appearance to the published map.

BGSREF_LEX Alternative BGS reference colour at the Lexicon code level, LEX, as defined above: e.g. 434 (no alternative needed as no clashes so same as above).

BGSREF_FM Alternative BGS reference colour at the formation level, FM_EQ, as defined above: e.g. 323 for London Clay Formation which includes Claygate Member.

BGSREF_GP Alternative BGS reference colour at the group level, GP_EQ, as defined above: e.g. 424 for Thames Group which includes London Clay Formation.

BGSREF_RK Alternative BGS reference colour for the lithology ROCK code, as defined above: e.g.


31/08/2009 of 84

822 for mudstone and sandstone lithology of Claygate Member.

SHEET Geological map sheet number, map sheet name and the tile version that the polygon appears on: e.g. EW069_BRADFORD_V4; SC032E_EDINBURGH_V4.

VERSION Version number and attribute level of the digital data: e.g. V4_16 is version 4, with attribute level 16. The version number is changed when a new dataset is released following major changes or periodic update. Data with the same attribute level have the same structure. As fields are added, renamed or removed so the attribute level is changed.

RELEASED Date the DiGMapGB data were converted into release format.

NOM_SCALE Nominal scale of the published (or compiled) information used to prepare the digital data: e.g. 10000 for 1:10 000 [including 1:10 560], 25000 for 1:25 000, 50000 for 1:50 000 [including 1:63 360 and 1:100 000 maps].

NOM_OS_YR The latest year date of Ordnance Survey information contained in the topographical base used for the original printed geological map (or the base used for DiGMapGB compilations). Fuller details are available if required.

NOM_BGS_YR The latest year date of the principal BGS geological information contained in the digital tile. This is usually the year of publication of the most up-to-date map sheet. Where no published map was available it is the year of compilation for DiGMapGB. Fuller details are available if required.

MSLINK Used for BGS QA purposes.

Table 1: Description of the attributes used on the BGS 1:625k bedrock geology

map

Table 2 lists the proposed GeoSciML features and attributes that are required for

Geologic Units in 1GE, from section 7.1, and describes how BGS intends to populate

these fields for the BGS 1:625k bedrock geology map. For some fields more than one

option is provided. Note that where it is stated that a field should be left blank this refers

simply to BGS data provision, not 1GE more generally. Reference is made to the CGI

200811 suite of vocabularies, but these are being revised in light of 1GE requirements

and it is the revised vocabularies that will be used in 1GE. Note that the mapping

described here refers only to Bedrock Geologic Units and doesn’t consider Geologic

Structures, including Contacts.


31/08/2009 of 84

Required

Features and

attributes

GeoSciML Features

and attributes

Proposed BGS mapping

Geologic

Unit

Geologic Unit

Name Name The LEX_D field of the 1:625k bedrock geology map contains the

full name of the Geologic Unit held in the BGS Stratigraphic Lexicon

eg Great Oolite Group.

Description Description There is no further general descriptive information about the

Geologic Unit held in the BGS 1:625k bedrock geology map. This,

optional, field could therefore be left blank or it could be populated

with the lithological description of the unit in the BGS Stratigraphic

Lexicon eg’ Calcareous (rarely oolitic) and argillaceous formations’.

Geologic Unit

Type

GeologicUnitType The BGS 1:625k bedrock geology map contains a mixture of

lithostratigraphic and lithodemic Geologic Units. These cannot be

distinguished on the basis of a simple query against any of the map

attributes. All Geologic Units could be classified using the broader

term ‘Lithologic Unit’, or a geologist could review each unit and

classify it correctly as Lithostratigraphic or Lithodemic.

ObservationMethod The BGS 1:625k bedrock geology map is produced as a synthesis of

larger scale published maps. The term ‘Synthesis of multiple

published descriptions’ from the FeatureObservationMethod200811

vocabulary should be used for all Geologic Units.

Purpose The BGS 1:625k bedrock geology map does not provide local

descriptions for Geological Units, as you might find on a field map,

rather it uses descriptions of Geologic Units drawn from the BGS

Stratigraphic Lexicon. These descriptions are the BGS definitions of

the units and the Purpose field should therefore be set to

‘definingNorm’ from the DescriptionPurpose_CodeList200811

vocabulary for all Geologic Units.

Thickness UnitThickness This information is not held in the BGS 1:625k bedrock geology

map. This, optional, field could therefore be left blank. There is

thickness information available for Geologic Units in the BGS

Stratigraphic Lexicon eg ‘c.23m in Grantham area’ but this is as a

text field, not numeric as required by GeoSciML. Translating from

text to numeric would probably have to be done manually.

Rank Rank The RANK field of the 1:625k bedrock geology map contains the

rank of the GeologicUnit and uses terms from the

StratigraphicRank200811 vocabulary.

The MAX_TIME_D and MIN_TIME_D fields of the 1:625k bedrock

geology map contain the age range for the Geologic Unit expressed

as geochronologic units. Where the Geologic Unit falls entirely

within a single geochronologic unit the values of MAX_TIME_D

and MIN_TIME_D are the same. The geochronologic units

generally relate to terms in the ICS geologic time scale. In some

cases local or regional terms are used (eg ASBIAN) and these must

be mapped to the equivalent or broader ICS term (eg the ASBIAN is

within the VISEAN). We will also need to map relevant Geologic

Units to the proposed new 1GE Pre-Cambrian geochronologic units.

Age (as a

term range)

preferredAge /

GeologicEvent:

- eventAge

- eventProcess

This information is neither held in the BGS 1:625k bedrock geology

map nor in the BGS Stratigraphic Lexicon. This property is

mandatory but it could be set to ‘Geologic Process’ for all Geologic

Units. Alternatively a geologist could review each Geologic Unit and

allocate a more specific event process from those defined in the

EventProcess200811 vocabulary.


31/08/2009 of 84

- eventEnvironment This information is neither held in the BGS 1:625k bedrock geology

map nor in the BGS Stratigraphic Lexicon. This property is not

mandatory so it could be left blank. Alternatively a geologist could

review each Geologic Unit and allocate a more specific event

environment from those defined in the EventEnvironment200811

vocabulary.

Information on Orogenic Events relating to Geologic Units is neither

held in the BGS 1:625k bedrock geology map nor in the BGS

Stratigraphic Lexicon. This property is not mandatory and should be

left blank.

The MAX_TIME_Y and MIN_TIME_Y fields of the 1:625k bedrock

geology map contain the age range for the Geologic Unit expressed

in years. This is potentially a way of providing a more accurate age

for the unit where local or regional geochronologic units have had to

be mapped to broader ICS units in preferredAge. However the ages

in the MAX_TIME_Y and MIN_TIME_Y fields are not always

updated to reflect the latest age interpretations in the ICS time chart

so inconsistencies may result between these ages and the ages in the

MAX_TIME_D and MIN_TIME_D fields.

One or more

Geologic

Events

(age as a

numeric

value)

geologicHistory /

GeologicEvent:

- name

- eventAge

- eventProcess This information is neither held in the BGS 1:625k bedrock geology

map nor in the BGS Stratigraphic Lexicon. This property is

mandatory, if an eventAge is provided, but it could be set to

‘Geologic Process’ for all Geologic Units. Alternatively a geologist

could review each Geologic Unit and allocate a more specific event

process from those defined in the EventProcess200811 vocabulary.

The role of a particular lithology component in the Geologic Unit is

not specifically held in the BGS 1:625k bedrock geology map.

However in the BGS Rock Classification System (RCS), to which the

RCS field in the BGS 1:625k bedrock geology map is related, role

information is provided by the RELATION_CODE field. This field

is constrained by concepts in the BGS DIC_RELATION_CODE

vocabulary which will need to be mapped to equivalent concepts in

the GeologicUnitPartRole200811 vocabulary. If the code in the RCS

field refers to a single, rather than a composite, lithology then role

should be set to ‘Only part’. Where the RCS field refers to a

composite lithology, but the RELATION_CODE field of the RCS is

left blank, then role should be set to ‘Unspecified part role’.

The RCS field in the BGS 1:625k bedrock geology map provides the

code for the lithology of the Geologic Unit. This is described fully in

the BGS Rock Classification System (RCS), to which the RCS field

is related. The lithology code may refer to a single lithology (eg

Sandstone) or a composite lithology (eg Sandstone and Siltstone).

The lithologies described in the RCS will need to be related to

lithologies described in the SimpleLithology200811 vocabulary. This

may be achieved through mapping to analogous concepts, where

these exist in the SimpleLithology200811 vocabulary. Where an

analogous concept does not exist mapping should be to the narrowest

available broader concept into which the concept being mapped can

fit.

This is a possible requirement for high resolution maps (WP9) so is

not needed for mapping the BGS 1:625k bedrock geology map.

Lithology Composition /

CompositionPart:

- role

- lithology as a

ControlledConcept

- material as a

CompoundMaterial

- proportion

The proportion of a particular lithology component in the Geologic

Unit is not specifically held in the BGS 1:625k bedrock geology map.

However in the BGS Rock Classification System (RCS), to which the

RCS field in the BGS 1:625k bedrock geology map is related,

proportion information is provided by the RCS_AMOUNT_CODE

field. This field is constrained by the concepts ‘Main’, ‘Subsidiary’,

and ‘Trace’ in the BGS DIC_RCS_AMOUNT vocabulary. These will


31/08/2009 of 84

need to be mapped to equivalent concepts in the

GeologicUnitPartRole200811 vocabulary.

Metamorphic

description

(with

Orogenic

event)

MetamorphicProperties

or


MetamorphicDescription

- metamorphicFacies

- metamorphicGrade

- peakPressureValue

- peakTemperatureValu

e

- protolithLithology

This information is neither held in the BGS 1:625k bedrock geology

map nor in the BGS Stratigraphic Lexicon. These properties are not

mandatory so could be left blank. Alternatively a geologist could

review each relevant Geologic Unit and allocate values to the

metamorphicFacies and metamorphicGrade properties from the

MetamorphicGrade and MetamorphicFacies vocabularies (note that

no 200811 suite vocabularies exist for these concepts). Only the

metamorphicFacies and metamorphicGrade properties are relevant to

the BGS 1:625k bedrock geology map, as the other properties are

only required for high resolution maps (WP9).

Genetic

aspects

If only “lithology” is

used, then genetic

aspects (mandatory for

quaternary deposits) are

described with event

process of Geologic

event.

If “material” is used then

genetic aspects can be

described by Earth

Material /

CompoundMaterial /

geneticCategory.

See Geologic Event above.

Geologic

units with

various parts

GeologicUnit/part/Geolo

gicUnitPart

With role and proportion



Physical

properties of

the geologic

unit

Physical Description

with density and

permeability



Bedding Bedding description with

pattern, style and

thickness



Weathering

character

Weathering description

with environment,

degree, process and

product



More

description

for material

Compound Material / This is a possible requirement for high resolution maps (WP9) so is


ParticleGeometry/

ParticleGeometryDescrip

tion with size and shape



Physical Description

with density and

permeability



Mineral

composition

Earth material / Mineral /

mineral name



Polygons of

the unit

MappedFeature

ObservationMethod The BGS 1:625k bedrock geology map is produced as a synthesis of

larger scale published maps. The term ‘Published map’ from the

MappedFeatureObservationMethod200811 vocabulary should be

used for all Mapped Features..

PositionalAccuracy This information is not held specifically in the BGS 1:625k bedrock


31/08/2009 of 84

geology map. A value of 500m should be used for all Mapped

Features.

SamplingFrame This information is not held specifically in the BGS 1:625k bedrock

geology map. A value of ‘EarthBedrockSurface’ should be used for

all Mapped Features.

Geometry Shape This is the geometry for the polygon from the BGS 1:625k bedrock

geology map.

ecp-2007-geo-317001 onegeology-europe wp5: · pdf file- to provide a standard access to...

Documents