Draft

OGC Standard

OGC Geoscience Markup Language - GeoSciML
GeoSciML Modeling Team Editor Eric Boisvert Editor Marcus Sen Editor
Version: 4.1
Additional Formats: XML PDF DOC
OGC Standard

Draft

Document number:16-008
Document type:OGC Standard
Document subtype:Implementation
Document stage:Draft
Document language:English

License Agreement

Use of this document is subject to the license agreement at https://www.ogc.org/license

Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://ogc.standardstracker.org/



I.  Abstract

GeoSciML is a model of geological features commonly described and portrayed in geological maps, cross sections, geological reports and databases. The model was developed by the IUGS CGI (Commission for the Management and Application of Geoscience Information) and version 4.1 is the first version officially submitted as an OGC standard. This specification describes a logical model and GML/XML encoding rules for the exchange of geological map data, geological time scales, boreholes, and metadata for laboratory analyses. It includes a Lite model, used for simple map-based applications; a basic model, aligned on INSPIRE, for basic data exchange; and an extended model to address more complex scenarios.

The specification also provides patterns, profiles (most notably of Observations and Measurements — ISO19156), and best practices to deal with common geoscience use cases.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, API, openapi, html, geology, geoscience, stratigraphy, borehole, geochemistry, geophysics, rock, fault, contact, fold, fossil, UML, GML, XML


III.  Preface

NOTE  Insert Preface Text here. Give OGC specific commentary: describe the technical content, reason for document, history of the document and precursors, and plans for future work.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

IV.  Security considerations

No security considerations have been made for this Standard.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

NameAffiliation
Eric BoisvertGeological Survey of Canada (Natural Resources Canada)
Ollie RaymondGeoscience Australia
Marcus SenBritish Geological Survey

OGC Geoscience Markup Language - GeoSciML

1.  Scope

NOTE  Insert Scope text here. Give the subject of the document and the aspects of that scope covered by the document.

2.  Conformance

This standard defines XXXX.

Requirements for N standardization target types are considered:

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC® interface standard, a software implementation shall choose to implement:

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Identification of Common Molecular Subsequences. Smith, T.F., Waterman, M.S., J. Mol. Biol. 147, 195–197 (1981)

ZIB Structure Prediction Pipeline: Composing a Complex Biological Workflow through Web Services. May, P., Ehrlich, H.C., Steinke, T. In: Nagel, W.E., Walter, W.V., Lehner, W. (eds.) Euro-Par 2006. LNCS, vol. 4128, pp. 1148–1158. Springer, Heidelberg (2006)

The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).

Grid Information Services for Distributed Resource Sharing. Czajkowski, K., Fitzgerald, S., Foster, I., Kesselman, C. In: 10th IEEE International Symposium on High Performance Distributed Computing, pp. 181–184. IEEE Press, New York (2001)

The Physiology of the Grid: an Open Grid Services Architecture for Distributed Systems Integration. Foster, I., Kesselman, C., Nick, J., Tuecke, S. Technical report, Global Grid Forum (2002)

National Center for Biotechnology Information, http://www.ncbi.nlm.nih.gov

ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html.

ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.

ISO: ISO 19157:2013, Geographic information  — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.

ISO: ISO 19139:2007, Geographic information — Metadata — XML schema implementation. ISO (2007).

ISO: ISO 19115-3, Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts. International Organization for Standardization, Geneva https://www.iso.org/standard/80874.html.

OGC Geospatial User Feedback Standard: Conceptual Model (2016)

Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard. Open Geospatial Consortium (2012). https://portal.ogc.org/files/?artifact id=47842.

Jiyeong Lee, Ki-Joune Li, Sisi Zlatanova, Thomas H. Kolbe, Claus Nagel, Thomas Becker: OGC 14-005r3, OGC® IndoorGML. Open Geospatial Consortium (2014). https://docs.ogc.org/is/14-005r3/14-005r3.html.

Arliss Whiteside Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact id=38867.

4.  Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

This document uses the terms defined in Sub-clause 5.3 of [OGC06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply.

4.1. example term

term used for exemplary purposes

Note 1 to entry: An example note.

Example

Here’s an example of an example term.

[SOURCE: ISO 19101-1:2014]

5.  Keywords

6.  Submitting organizations

7.  Contributors

Additional contributors to this Standard include the following:

Edward Lewis, British Geological Survey

8.  Conventions

This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

8.1.  Identifiers

The normative provisions in this standard are denoted by the URI

http://www.opengis.net/spec/{standard}/{m.n}

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

9.  Clauses not containing normative material

Paragraph

9.1.  Clauses not containing normative material sub-clause 1

Paragraph

9.2.  Clauses not containing normative material sub-clause 2

10.  Clause containing normative material

Paragraph

10.1.  Requirement Class A or Requirement A Example

Paragraph – intro text for the requirement class.

Use the following table for Requirements Classes.

Requirements class 1

Obligationrequirement
Description

Requirements Class

Normative statementsRequirement 1-1
Requirement 1-2

10.1.1.  Requirement 1

Paragraph — intro text for the requirement.

Use the following table for Requirements, number sequentially.

Requirement 1

Obligationrequirement
Statement

Requirement ‘shall’ statement

Dictionary tables for requirements can be added as necessary. Modify the following example as needed.

Table 1

NamesDefinitionData types and valuesMultiplicity and use
name 1definition of name 1floatOne or more (mandatory)
name 2definition of name 2character string type, not emptyZero or one (optional)
name 3definition of name 3GML:: Point PropertyTypeOne (mandatory)

10.1.2.  Requirement 2

Paragraph — intro text for the requirement.

Use the following table for Requirements, number sequentially.

Requirement 2

Label/req/req-class-a/req-name-2
Conditions
  1. The process input value is specified in-line in an execute request.

  2. The process input is defined as an object according to its schema.

A

The server SHALL support process input values encoded as qualified values.

B

The value of the value key SHALL be an object instance.

11.  Media Types for any data encoding(s)

A section describing the MIME-types to be used is mandatory for any standard involving data encodings. If no suitable MIME type exists in http://www.iana.org/assignments/media-types/index.html then this section may be used to define a new MIME type for registration with IANA.


Annex A
(informative)
Conformance Class Abstract Test Suite (Normative)

NOTE  Ensure that there is a conformance class for each requirements class and a test for each requirement (identified by requirement name and number)

A.1.  Conformance Class A

Example

label

http://www.opengis.net/spec/name-of-standard/1.0/conf/example1

subject

Requirements Class “example1”

classification

Target Type:Web API

A.1.1.  Example 1

Abstract test A.1

Subject/req/req-class-a/req-name-1
Label/conf/core/api-definition-op
Test purpose

Validate that the API Definition document can be retrieved from the expected location.

Test method
  1. Construct a path for the API Definition document that ends with /api.

  2. Issue a HTTP GET request on that path

  3. Validate the contents of the returned document using test /conf/core/api-definition-success.

A.1.2.  Example 2

Abstract test A.2

Subject/req/req-class-a/req-name-2
Label/conf/core/http
Test purpose

Validate that the resource paths advertised through the API conform with HTTP 1.1 and, where appropriate, TLS.

Test method
  1. All compliance tests SHALL be configured to use the HTTP 1.1 protocol exclusively.

  2. For APIs which support HTTPS, all compliance tests SHALL be configured to use HTTP over TLS (RFC 2818) with their HTTP 1.1 protocol.


Annex B
(informative)
Title

NOTE  Place other Annex material in sequential annexes beginning with “B” and leave final two annexes for the Revision History and Bibliography


Annex C
(informative)
Revision History

Table C.1

DateReleaseEditorPrimary clauses modifiedDescription
2016-04-280.1G. Editorallinitial version

Bibliography

NOTE  The TC has approved Springer LNCS as the official document citation type.

Springer LNCS is widely used in technical and computer science journals and other publications

– Actual References:

[n] Journal: Author Surname, A.: Title. Publication Title. Volume number, Issue number, Pages Used (Year Published)

[n] Web: Author Surname, A.: Title, http://Website-Url

[1]  OGC: OGC Testbed 12 Annex B: Architecture (2015).