ECP-2007-GEO OneGeology-Europe. WP5: Informatics specification, data model, interoperability and standards

Transcription

1 ECP-2007-GEO 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 31 rd 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, , p.1 31/08/2009 Page 1 of 84

2 Table of content 1 Introduction Analysis of existing data models within the 1GE scope Identification of existing data models within the 1GE scope Scope of OneGeology-Europe data model List of existing data models GeoSciML description Purpose of the GeoSciML model Scope of the model Overview of the model Groundwater data model description Mineral Occurrence data model description Landslides data model description Earthquakes data model description Borehole data model description Boreholes in GeoSciML Boreholes in BoreholeML INSPIRE requirements for data specification Available INSPIRE documents to help data specification activity INSPIRE Data specification document for each theme INSPIRE requirements for data modeling WP2 requirements User needs summary for data modeling Proposal to address WP2 requirements WP3 requirements General review of WP3 requirements Requirements for Geologic Units Requirements for Geologic Contacts and Structures Requirements for Common Vocabularies WP9 requirements Requirements for Geologic Units and Structures for high resolution maps Need for Vocabularies Proposal to fit requirements from WP2, WP3, WP Proposal to fit requirements for Geologic Units Proposal to fit WP3 requirements for Geologic Structures Proposal to fit requirements for Vocabularies Conclusion Guidelines for a 1GE profile GeoSciML elements selected for OneGeology-Europe For Geologic units For Geologic Structures Description of GeoSciML elements (feature types and attributes) For Geologic units For Geologic Structures Documentation, UML data model and XSD files for GeoSciML Conclusion and next steps /08/2009 Page 2 of 84

3 10 ANNEXE A GeoSciML and INSPIRE ANNEXE B Examples of mapping to GeoSciML Example from BRGM (France) Lithology Age Genetic category Event process and Event environment Example from SGU (Sweden) Results of the mapping exercise Comments Example from Czech and Slovak Geological Surveys Process of the mapping into GeoSciML Used technology Example from ISPRA (Italy) Lithology Age Genetic category Event-Process Event-Environment Example from BGS (UK) /08/2009 Page 3 of 84

4 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 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 Page 4 of 84

5 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 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 Page 5 of 84

6 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 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 Ground water GroundWaterML Landslides Landslides data model Earthquakes QuakeML Mineral Occurences Mineral occurences GeoSciML v2 is primarily concerned with "interpreted" geology (units, structures, etc), but links to external schemas for the descriptions of observational data Extension of GeoSciML for GroundWater, using also O&M and SensorML GML application schema using O&M and SensorML Representing seismological data (but no use of ISO/OGC standards) GGIPAC Mineral Occurrence Model 31/08/2009 Page 6 of 84

7 Geotechnics/GeoEnv. DIGGSML Boreholes BoreholeML Data Interchange for Geotechnical and GeoEnvironmental Specialists Developed by German Geological Surveys 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) 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 Page 7 of 84

8 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 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 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 Page 8 of 84

9 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 Page 9 of 84

10 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 Page 10 of 84

11 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 Page 11 of 84

12 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 Page 12 of 84

13 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 Page 13 of 84

14 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 Page 14 of 84

15 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 Page 15 of 84

16 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 Page 16 of 84

17 (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 ( desurveyed ) 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/datacollection 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 Page 17 of 84

18 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 Page 18 of 84

19 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 Page 19 of 84

20 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 Page 20 of 84

21 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 Page 21 of 84

22 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 and 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 Page 22 of 84

23 Metadata : Figure 11: Summary UML diagram for the Metadata package 31/08/2009 Page 23 of 84

24 The GeoSciML Metadata package shows the metadata links from various GeoSciML classes. GeoSciML refers to the (externally maintained) ISO 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, subtypes 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 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 Page 24 of 84

25 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 r1) and Sampling Features (OGC r3) 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 and ISO 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 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: 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 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 Page 25 of 84

26 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 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 Page 26 of 84

27 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: 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 Boreholes in GeoSciML See GeoSciML, paragraph Boreholes & Observations 31/08/2009 Page 27 of 84

28 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 ( 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 ( 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 with documentation (in English with some German) available at 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 Page 28 of 84

29 3 INSPIRE requirements for data specification 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 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 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 Page 29 of 84

30 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 Page 30 of 84

31 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 Page 31 of 84

32 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 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) 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 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 Page 32 of 84

33 - 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 Page 33 of 84

34 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 GeoSciML Features and attributes (1) Comment attributes 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 Age (as a term range) One or more Geologic Events (age as a numeric value) Rank preferredage / GeologicEvent: - eventage eventprocess - eventprocess - eventenvironnement eventenvironnement geologichistory / GeologicEvent: - name - eventage - eventprocess Lithology Composition / CompositionPart: - role - lithology as a ControlledConcept - material as a CompoundMaterial - proportion Metamorphic description (with Orogenic event) MetamorphicProperties or MetamorphicCharacter/ MetamorphicDescription: x x eventage (as a term range) name: for Orogenic Events eventage (numeric) eventprocess role lithology : to describe simple lithology Material: to describe more attributes than simple lithology (CompoundMaterial/ CompositionCategory, and RockMaterial/ Lithology or other attributes Proportion If related to the Geologic Unit, then use MetamorphicCharacter/ 31/08/2009 Page 34 of 84

35 - 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 More description for material Compound Material / ParticleGeometry/ ParticleGeometryDescription with size and shape 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 Page 35 of 84

36 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 Page 36 of 84

37 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 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. ( The CGI reference for vocabularies is the version (November 2008). The discussion about lithology is here: 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 Page 37 of 84

38 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 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/ O 0..1 ParticleGeometryDescription: - size O 0..n CGI_Value - shape O 0..n CGI_Value Compound Material / Physical Description: O density, O 0..n CGI_Numeric - permeability O 0..n CGI_Value 31/08/2009 Page 38 of 84

39 Metamorphic Properties: Compound Material / MetamorphicProperties or MetamorphicCharacter / MetamorphicDescription: O 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 If only CompositionPart / lithology is used: O 1..n ControlledConcept x - 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: O 0..n CGI_TermValue x - CompoundMaterial / geneticcategory 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 density, O 0..n CGI_ Numeric - permeability O 0..n CGI_Value Bedding: Bedding description: O pattern, O 0..n CGI_TermValue - style, O 0..n CGI_TermValue - thickness O 0..n CGI_Value Weathering character: Weathering description: O 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 O 31/08/2009 Page 39 of 84

40 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: Shear Displacement Structure / O 0..1 Total Displacement/ - 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: ( For Geologic units GeoSciML Features and attributes Geologic Unit GeologicUnit ID Name Description GeologicUnitType ObservationMethod Purpose Description 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 Controlled concept defining the type of unit. Logical constraints of definition of unit and valid property cardinalities are contained in the definition. 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...). Specification of the intended purpose/level of abstraction for a given feature or object instance. 31/08/2009 Page 40 of 84

41 Rank UnitThickness Age: preferredage / GeologicEvent: Scoped name because intention is asserted by author of the data instance. Values: Instance, TypicalNorm, IdentifyingNorm. 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 Typical thickness of the geologic unit. A geologic age is related to a particular GeologicEvent, during which one or more geological processes act to modify geological entities 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 Page 41 of 84

42 Complementary ways to specify the age: geologichistory / GeologicEvent: - eventage (as numeric values) See above - eventprocess See above Lithology: Composition / CompositionPart: environment, or tectonics. Specification of setting may be a simple text description or a link to a complex description. A sequence of GeologicEvents with role geologichistory allow describing the Genesis of the GeologicFeature 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 Page 42 of 84

43 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 Page 43 of 84

44 (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. If CompositionPart /material is used: - CompoundMaterial / geneticcategory Geologic unit composed of various units: GeologicUnit/part/GeologicUnitPart: 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. 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. 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 Page 44 of 84

45 - 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 Polygons of the unit: MappedFeature with: 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: A MappedFeature is part of a geological interpretation. It provides a link between a notional feature 31/08/2009 Page 45 of 84

46 (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 Page 46 of 84

47 8.2.2 For Geologic Structures GeoSciML Features and attributes Geologic Structure (Fault) and Contacts GeologicStructureID Name ObservationMethod Purpose For Faults : type with movement and sense: Shear Displacement Structure / Total Displacement/ Description 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 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...). 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. 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 subvertical faults (typically 'sinistral', 'dextral', 'leftlateral', 'dip-slip', 'unknown') - Movement Type Defines the type of movement (eg dip-slip, strike- 31/08/2009 Page 47 of 84

48 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 ( 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 ( Summary of available information about GeoSciML 1. Documentation Full documentation of the model may be viewed from 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: 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 profile, and in particular using the rules from ISO 19136:2007 (GML 3.2.1) g_and_encoding_uml_and_g 31/08/2009 Page 48 of 84

49 GeoSciMLv2 is available as a set of XMI documents at 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 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 v The rule for encoding <<Union>> classes follows : association_pattern_targ - Additional stereotypes are used as described in : rofile_of_uml The XML Schema representation of GeoSciML can be used to validate GeoSciML instance documents. The GeoSciMLv2 specific schemas are available at: 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: eosciml. 31/08/2009 Page 49 of 84

50 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 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 Page 50 of 84

51 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 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. GeoSciML is based on ISO 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 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 To check To do 8. Reference model 5 The reference model specified in ISO shall be used as the reference model of the INSPIRE data specifications. OK 31/08/2009 Page 51 of 84

52 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 Clause 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 (Feature concept dictionaries and registers) shall be maintained for INSPIRE in an ISO 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 shall be extended to include these items. 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 An amendment of ISO 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. 9 Every feature catalogue shall contain the information for all spatial object types that are relevant for the particular application schema. OK To do To do 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. 12 Every INSPIRE data specification shall include an INSPIRE application schema that is modelled according to ISO The spatial object types and their properties specified in an application schema shall be drawn from the common feature concept dictionary. 14 Spatial object types shall be modelled according to ISO , 8.1, and according to the additional rules in Clauses 9, 10, 11, 13, and 22 of this document. 15 The profile of the conceptual schema defined in the ISO series that is used in the application schema shall conform with ISO Every INSPIRE application schema shall clearly document the profile to be used for the different properties of spatial object types. 17 Basic types as specified in ISO/TS shall be used in an INSPIRE application schema whenever applicable. To do To check To do To check To check OK To check 31/08/2009 Page 52 of 84

53 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 and ISO/TS 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 In addition, all constraints shall also be described in natural language in the feature catalogue. 9.6 Base application schema Spatial Object 22 All spatial object types specified in INSPIRE application schemas shall be a direct or indirect specialisation of SpatialObject Object with Identifier 23 All spatial object types whose instances are identifiable (see Clause 16) shall inherit from ObjectWithIdentifier 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 This inheritance is from the INSPIRE General Feature Model which GeoSciML doesn t inherit from not sure if that will be a problem 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 do To check OK To check To check To check 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 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 Page 53 of 84

54 the stereotype <<version>> to denote that the value of the property is a specific version of the target object 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 ) - by specifying properties of the spatial object type with a value that is a geographic identifier in a gazetteer (see and ISO ) - 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 ; 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 ). 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 An application schema package that uses coverages shall follow the rules of ISO for referencing standardized schemas, i.e. import the coverage schema specified by ISO A coverage shall be defined as a subtype of CV_Coverage. Valid coverage types, which shall be applied if applicable, are given in Table 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 Page 54 of 84

55 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. 47 In an INSPIRE application schema, English shall be used for class, attribute and association role names throughout the UML model. OK OK 11.2 Multilingual extensions 48 PT_FreeText from the conceptual model specified in ISO/TS 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 To check if GeoSciML vocabulary are ISO GeoSciML vocabularies inherit from AnyDictionary defined in ISO To check 31/08/2009 Page 55 of 84

56 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 where the spatial reference system falls within the scope of ISO OK 51 To support the ESDI, an ISO 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 Temporal reference systems 55 Temporal reference systems shall be described using the model specified in ISO (TM_ReferenceSystem). To do To check 56 To support the ESDI, an ISO 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 Units of measurement 59 Units of measurements shall be described using the model contained in ISO D To do OK 60 To support the ESDI, an ISO 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 Page 56 of 84

57 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. 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. 66 Uniqueness: No two spatial objects of spatial object types specified in INSPIRE application schemas shall have the same identifier. OK OK 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. 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 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) 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 All namespaces shall start with a code that unambiguously identifies the data provider Cf 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. 74 In case of a multinational data provider it shall be a six letter code starting an underscore ("_") to avoid conflicts with ISO The codes shall be registered in a register for object identifier namespaces in INSPIRE. To do To do OK To do 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 Page 57 of 84

58 76 To support the ESDI, an ISO 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. 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 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 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 To do 84 The rules specified in ISO 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 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. 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 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 To do To do To do 31/08/2009 Page 58 of 84

59 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 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 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 To do To do 31/08/2009 Page 59 of 84

60 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 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 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 Page 60 of 84

61 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 Page 61 of 84

62 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 Page 62 of 84

63 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 Page 63 of 84

64 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 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 Page 64 of 84

65 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 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) Granitoid Basalts Breccia Reef limestone Calcschists Metadiorites Orthogneiss Sand Tuffites Eclogites Impactites GeneticCategory (GeoSciML) 2.2. Igneous intrusive genesis 2.1. Igneous extrusive genesis 6.2. Cataclastic genesis 4.2. Biological sedimentary genesis 8.3. Metasedimentary genesis Metaplutonic genesis 8.2. Metaigneous genesis 4.1. Clastic sedimentary genesis Volcaniclastic genesis 5.2. Regional metamorphic genesis 7. Impact genesis 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 Page 65 of 84

66 Geodynamics (BRGM) Oceanic accretion Continental collision Continental extension Event-Process (GeoSciML) Spreading Continental collision 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. Some examples of correspondence between geological maps and GeoSciML are as follows: Geodynamics (BRGM) Continental Littoral Continental shelf Event-Environment (GeoSciML) Terrestrial setting Shoreline settings 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., Geological map of the Fennoscandian Shield, scale 1: 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 "GEOLOGIC UNIT" Composition Part / Lithology "GEOLOGIC UNIT" Metamorphic description / Metamorphic grade "GEOLOGIC UNIT" Metamorphic description / Protolith lithology "EARTH MATERIAL" Compound material / Composition category "EARTH MATERIAL" Compound material / Genetic Vocabulary used SimpleLithology MetamorphicGrade (from discussion page) SimpleLithology CompositionCategory GeneticCategory Header in Examples 1-3 Lithology Met. Grade Protolith Composition Genetic 31/08/2009 Page 66 of 84

67 category "GEOLOGIC AGE" Geologic event / Event process "GEOLOGIC AGE" Geologic event / Event environment "GEOLOGIC AGE" Geologic event / Event age EventProcess EventEnvironment ICS Stratigraphic Chart (extended with WP3 working material Precambrian Epochs) Process Environment 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 genetic category - The event-process & event-environment. - 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 Results of the mapping exercise Example 1: Granite, pegmatite (c 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 ( and 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 and 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 SimpleLithology so a more general term must be used and information is lost. This also affects the name of the 31/08/2009 Page 67 of 84

68 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 SimpleLithology 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 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 SimpleLithology 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 Page 68 of 84

69 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: (Cháb et all.) at a scale of 1: the digital version of The West Carpathians map and adjacent areas (2000, Lexa et all) at a scale of 1: 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 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 Page 69 of 84

70 - 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 Page 70 of 84

71 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=" 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 Page 71 of 84

72 Used technology - Postgres SQL 8.3 with PostGIS extension (essential) - Perl 5.8 using DBI, XML::Twig (essential), Locale:Recode etc. Libraries - Geoserver 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: (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 eventprocess. 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 genetic category - The event-process & event-environment. - The metamorphic grade We present in below section some examples how Italian database was mapped 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 Page 72 of 84

73 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 Page 73 of 84

74 Lithologies (ISPRA) Limestones (Calcari) Mapped terms (CGI SimpleLithology vocabulary) calcareous carbonate sedimentary rock Final URN CGI:SimpleLithology urn:cgi:classifier:cgi:simplelithology:200811: calcareous_carbonate_sedimentary_rock Marly limestones (Calcare marnoso) Marls (marna) Mudstone Marl (proposed by WP3 in pending for CGI- GeoSciML) urn:cgi:classifier:cgi:simplelithology:200811:mudstone urn:cgi:classifier:cgi:simplelithology:200811:mud Sands (sabbia) sand urn:cgi:classifier:cgi:simplelithology:200811:sand Conglomerates conglomerate urn:cgi:classifier:cgi:simplelithology:200811:conglomerate (conglomerato) Example 2: Diorites and gabbros This example is an easily match situation, because both the terms are already present in the CGI SimpleLithology vocabulary. Lithologies (ISPRA) Mapped terms (CGI SimpleLithology vocabulary) Final URN CGI:SimpleLithology 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) Monzonites (monzonite) Mapped terms (CGI SimpleLithology vocabulary) Monzonite Final URN CGI:SimpleLithology200811: urn:cgi:classifier:cgi:simplelithology:200811:monzon ite Quartz diorites Dioritic rock urn:cgi:classifier:cgi:simplelithology:200811:dioritic_ rock Monzodiorites monzodiorite (proposed by urn:cgi:classifierscheme:ispra:simplelithology:2009 (monzodiorite) WP3 in pending for CGI- :monzodiorite? GeoSciML) Monzogabbros monzogabbro (proposed by urn:cgi:classifier:cgi:simplelithology:200811:gabbro 31/08/2009 Page 74 of 84

75 (monzogabbro) WP3 in pending for CGI- GeoSciML) urn:cgi:classifierscheme:ispra:simplelithology:2009 :monzogabbro? 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 SimpleLithology vocabulary we have build an ontology mapping file that trough a procedure transforms the national terms in Italian language directly in CGI SimpleLithology 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 Page 75 of 84