Description of 3D Geological Models using INSPIRE and Semantic Web principles

2018-06-27, László Sőrés PhD, MBFSZ

latest update 2018-09-20

In the current state of information technology building 3D geological models has become a key issue in geoscience. It requires the coherent usage of large datasets from different domains and resources, including observation results from in situ and remote sensors, output of modelling and simulation software and human interpretation. As geology is not restricted by national borders creating 3D models is often an international effort. Sharing information in a meaningful way is a big challenge for both geoscientists and IT experts. The existing INSPIRE framework provides large number of conceptual data models to handle a wide range of spatial data types in a regular way and create harmonised information systems. Is it sufficient to support 3D geological models? The Mining and Geological Survey of Hungary (MBFSZ) has set up a test bed application to investigate the potentials of combining INSPIRE data models and linked data technology in order to describe and distribute 3D geologic Models in a more efficient way.

  1. Background
  2. Example Application
  3. Model Creation
  4. Query Example
  5. Conclusions

1. Background

The aim of this application is to demonstrate the use of semantic web and INSPIRE principles in documenting and publishing complex 3D geological models. It is based on three simplified ontologies created from the INSPIRE Geology and GeoSciML 3.2 data models.

Using the above ontologies a test bed RDF triplet store hosted by an Apache Jena Fuseky SPRQL server has been set up. Tables and graphics shown in this material has been generated from SPARQL query responses. The RDF triplets are available in N3 and RDF/XML format.

The example is reduced to one single model component extracted from a real 3D Modelling project. It is a geological contact, a cenizoic mezozoic boundary, corresponding with the top of a karstic aquifer. The model is using the results of a geothermal exploration project carried out in south west Hungary. Results are partially confidental, for this reason exact location and depth is blanked in the examples.

2. Example Application

In this application the 3D Model is a standard GeologicCollection with mapMembers having 3D geometry. The traditional geologic description is available behind the link called "specification" pointing to the Geologic Feature part. 3D results (voxel models, surfaces) and observation details are stored behind "samplingFrame" pointing to specialized SamplingFeatures. (as in GeoSciML 3.2)

object tree
Figure 1. Object tree of the 3D Model

Figure 1 shows the main components and relations of the example model. Ellipses contain class types and names of the modell elements, arrows show relations (object properties) as defined in the above ontologies.

report
Table 1. 3D Model metadata view

Table 1. contains a summery of the same elements in a metadata table view. Links provide quick access to key resources like images, services, INSPIRE gml dowloads, etc. The complete listing of the model elements generated from the RDF triplets can be found here.

view 3D Model download 3D Model view Strat. Point download GML

3. Model Creation

Creating a 3D geological model is a very complex mission. A project set up for such a big task may contain several work packages, each of them dedicated to one specific model component. In this example the work package of creating the geologic contact is described. The procedure follows a complex pattern:

Using the traditional project management approach we can set up tasks, milestones and define deliverables. Tasks and deliverables are listed in Table 2.

tasks
Table 2. Task list of creating a 3D Contact

Each deliverable in the list corresponds to one Sampling Feature, a sub product that has some role in the overall workflow. The task name refers to the process used to create the deliverable. Deliverables are packages containing the output produced by the tasks, in other words, results of the observations related to the corresponding Sampling Feature. The work package schedule is shown on a Gant chart in Table 3.

object tree
Table 3. Gant chart of the Model creation process chain

The linkage between tasks and deliverables is characteristic to the project and gives a high level overview of the work- and data flow. All this can be encoded in the RDF triplet store. An appropriate SPARQL query can be converted to the flowchart on figure 2.

work flow
Figure 2. Workflow of Creating a 3D geological Surface

4. Query Example

To demonstrate the power of the semantic approach an example search is explained below. Let us suppose that a user is looking for results related to the mesozioc basement. One SPARQL query can provide the URLs of all observation results. What is needed is to look for mapped geological contacts that correlate with the geochronological boundary just above the mesozoic era. Having those mapped features, all the geophysical objects that were targeted to observe that contact can be found. Here is the SPARQL code for such a complex query: 

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ns0: <http://mbfsz.gov.hu/rdf/tmp/>
PREFIX ge: <http://geonetwork.mfgi.hu/ontology/ge#> 
PREFIX om: <http://geonetwork.mfgi.hu/ontology/om#>
PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX gsmltrs: <http://xmlns.geosciml.org/TemporalReferenceSystem/3.0/>

SELECT  ?mf ?descr ?url
WHERE {
  ?bnd gsmltrs:previousEra <http://inspire.ec.europa.eu/codelist/GeochronologicEraValue/mesozoic> .
  ?cnt ge:correlatesWith ?bnd .
  ?mf ge:specification ?cnt .
  ?mf ge:samplingFrame ?sf .
  ?sf om:relatedObservation ?obs .
  ?obs om:result ?res .
  ?res dcat:downloadURL ?url . 
  ?mf dct:description ?descr .
}

The first part contains the namespace prefixes used in the query. The select part defines the output: the query should return the identifier, the description of the mapped feature, and the URL pointing to the result (GML coverage of the 3D surface). The where clause contains a chain of linked objects, a route from the boundary to the download URL. The query selects all objects from the RDF triplet store that are linked together as described in the where clause. The predicates are properties defined in the ontolgies and also shown on figure 1. Query results can be seen on figure 3.

fuseki
Figure 3. Results shown in the Apache Jena Fuseki SPARQL Query window

5. Conclusions