diff --git a/.github/workflows/compile_doc.yml b/.github/workflows/compile_doc.yml new file mode 100644 index 0000000..7ffd4e2 --- /dev/null +++ b/.github/workflows/compile_doc.yml @@ -0,0 +1,23 @@ +name: compile_doc +on: + push: + branches: + - 'main' +jobs: + build: + runs-on: ubuntu-latest + container: metanorma/metanorma:latest + steps: + - name: Checkout repo + uses: actions/checkout@v3 + with: + path: main + - name: Generate document + run: | + cd main/docs + metanorma compile --agree-to-terms -t ogc -x xml,html,doc index.adoc + git config --global user.name 'example' + git config --global user.email 'example@example.com' + git add --all + git commit -am "Compilation of HTML documents" + git push diff --git a/docs/.nojekyll b/docs/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/docs/document.adoc b/docs/document.adoc deleted file mode 100644 index 6d3e876..0000000 --- a/docs/document.adoc +++ /dev/null @@ -1,61 +0,0 @@ -= OGC (add title text) -:doctype: standard -:encoding: utf-8 -:lang: en -:status: draft -:committee: technical -:draft: 3.0 -:external-id: http://www.opengis.net/doc/{doc-type}/{standard}/{m.n} -:docnumber: YY-999 -:received-date: 2029-03-30 -:issued-date: 2029-03-30 -:published-date: 2029-03-30 -:fullname: Editor One -:fullname_2: Editor Two -:docsubtype: Interface -:keywords: ogcdoc, OGC document, API, openapi, html -:submitting-organizations: Organization One; Organization Two -:mn-document-class: ogc -:mn-output-extensions: xml,html,doc,pdf -:local-cache-only: -:data-uri-image: -:pdf-uri: ./document.pdf -:xml-uri: ./document.xml -:doc-uri: ./document.doc -:edition: 1.0 - -//// -Make sure to complete each included document -//// -include::sections/clause_0_front_material.adoc[] - -include::sections/clause_1_scope.adoc[] - -include::sections/clause_2_conformance.adoc[] - -include::sections/clause_3_references.adoc[] - -include::sections/clause_4_terms_and_definitions.adoc[] - -include::sections/clause_5_conventions.adoc[] - -include::sections/clause_6_informative_text.adoc[] - -include::sections/clause_7_normative_text.adoc[] - -include::sections/clause_8_media_types.adoc[] - -//// -add or remove annexes after "A" as necessary -//// -include::sections/annex-a.adoc[] - -include::sections/annex-n.adoc[] - -//// -Revision History should be the last annex before the Bibliography -Bibliography should be the last annex -//// -include::sections/annex-history.adoc[] - -include::sections/annex-bibliography.adoc[] diff --git a/docs/iev/cache/version b/docs/iev/cache/version new file mode 100644 index 0000000..a2268e2 --- /dev/null +++ b/docs/iev/cache/version @@ -0,0 +1 @@ +0.3.1 \ No newline at end of file diff --git a/docs/index.adoc b/docs/index.adoc new file mode 100644 index 0000000..24a58e1 --- /dev/null +++ b/docs/index.adoc @@ -0,0 +1,63 @@ += OGC Geoscience Markup Language - GeoSciML +:doctype: standard +:encoding: utf-8 +:lang: en +:status: draft +:committee: technical +:draft: 4.1.1 +:external-id: http://www.opengis.net/doc/{doc-type}/{standard}/{m.n} +:docnumber: 16-008 +:received-date: 2016-08-23 +:issued-date: 2016-11-29 +:published-date: 2017-01-31 +:fullname: GeoSciML Modeling Team +:fullname_2: Eric Boisvert +:fullname_3: Ollie Raymond +:fullname_3: Marcus Sen +:docsubtype: Interface +:keywords: ogcdoc, OGC document, API, openapi, html, geology, geoscience, stratigraphy, borehole, geochemistry, geophysics, rock, fault, contact, fold, fossil, UML, GML, XML +:submitting-organizations: Arizona Geological Survey (AzGS), Arizona, USA; British Geological Survey (NERC-BGS), UK; Bureau de Recherches Géologiques et Minières (BRGM), France; Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia; Geological Survey of Victoria (GSV), Australia; Geological Survey of Finland (GTK), Finland; Geological Survey of Italy (ISPRA), Italy; Geological Survey of Sweden (SGU), Sweden; Geoscience Australia (GA), Australia; Institute of Geological and Nuclear Sciences (GNS), New Zealand; Landcare Research, New Zealand; Natural Resources Canada (NRCan), Canada; U.S. Geological Survey (USGS), United States of America +:mn-document-class: ogc +:mn-output-extensions: xml,html,doc,pdf +:local-cache-only: +:data-uri-image: +:pdf-uri: ./index.pdf +:xml-uri: ./index.xml +:doc-uri: ./index.doc +:edition: 4.1 + +//// +Make sure to complete each included document +//// +include::sections/clause_0_front_material.adoc[] + +include::sections/clause_1_scope.adoc[] + +include::sections/clause_2_conformance.adoc[] + +include::sections/clause_3_references.adoc[] + +include::sections/clause_4_terms_and_definitions.adoc[] + +include::sections/clause_5_conventions.adoc[] + +include::sections/clause_6_informative_text.adoc[] + +include::sections/clause_7_normative_text.adoc[] + +include::sections/clause_8_media_types.adoc[] + +//// +add or remove annexes after "A" as necessary +//// +include::sections/annex-a.adoc[] + +include::sections/annex-n.adoc[] + +//// +Revision History should be the last annex before the Bibliography +Bibliography should be the last annex +//// +include::sections/annex-history.adoc[] + +include::sections/annex-bibliography.adoc[] diff --git a/docs/index.doc b/docs/index.doc new file mode 100644 index 0000000..ccdf9a3 --- /dev/null +++ b/docs/index.doc @@ -0,0 +1,3396 @@ +MIME-Version: 1.0 +Content-Type: multipart/related; boundary="----=_NextPart_015c3989.8eb6.4dff" + +------=_NextPart_015c3989.8eb6.4dff +Content-ID: +Content-Disposition: inline; filename="index.htm" +Content-Type: text/html; charset="utf-8" + + + + + + +Print +100 + + + + + + + + +

+ + Open Geospatial Consortium + + + + + + +

+ +

+ Submission Date: 2016-08-23 +

 

+

+
+

+
+
+

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/

+
+ +
+ +
+ +
+
+ +

Contents

+ +

 TOC \o "1-2" \h \z \u + +Copyright notice +. + + + PAGEREF _Toc940306266 \h + 1 +

+ +

+Note +. + + + PAGEREF _Toc185384044 \h + 1 +

+ +

+License Agreement +. + + + PAGEREF _Toc233508752 \h + 1 +

+ +

+Notice for Drafts +. + + + PAGEREF _Toc969995460 \h + 1 +

+ +

+I. Abstract +. + + + PAGEREF _Toc298750458 \h + 1 +

+ +

+II. Keywords +. + + + PAGEREF _Toc913269882 \h + 1 +

+ +

+III. Preface +. + + + PAGEREF _Toc641905532 \h + 1 +

+ +

+IV. Security considerations +. + + + PAGEREF _Toc450268940 \h + 1 +

+ +

+V. Submitting Organizations +. + + + PAGEREF _Toc988538550 \h + 1 +

+ +

+VI. Submitters +. + + + PAGEREF _Toc805656337 \h + 1 +

+ +

+1. Scope +. + + + PAGEREF _Toc256232815 \h + 1 +

+ +

+2. Conformance +. + + + PAGEREF _Toc243517329 \h + 1 +

+ +

+3. Normative references +. + + + PAGEREF _Toc464636920 \h + 1 +

+ +

+4. Terms and definitions +. + + + PAGEREF _Toc433561171 \h + 1 +

+ +

+5. Keywords +. + + + PAGEREF _Toc593373739 \h + 1 +

+ +

+6. Submitting organizations +. + + + PAGEREF _Toc177428892 \h + 1 +

+ +

+7. Contributors +. + + + PAGEREF _Toc078299070 \h + 1 +

+ +

+8. Conventions +. + + + PAGEREF _Toc728018719 \h + 1 +

+ +

+8.1. Identifiers +. + + + PAGEREF _Toc273861541 \h + 1 +

+ +

+9. Clauses not containing normative material +. + + + PAGEREF _Toc131888051 \h + 1 +

+ +

+9.1. Clauses not containing normative material sub-clause 1 +. + + + PAGEREF _Toc722091394 \h + 1 +

+ +

+9.2. Clauses not containing normative material sub-clause 2 +. + + + PAGEREF _Toc049094553 \h + 1 +

+ +

+10. Clause containing normative material +. + + + PAGEREF _Toc889857606 \h + 1 +

+ +

+10.1. Requirement Class A or Requirement A Example +. + + + PAGEREF _Toc686772666 \h + 1 +

+ +

+11. Media Types for any data encoding(s) +. + + + PAGEREF _Toc974175464 \h + 1 +

+ +

+Annex A (informative) Conformance Class Abstract Test Suite (Normative) +. + + + PAGEREF _Toc545760617 \h + 1 +

+ +

+A.1. Conformance Class A +. + + + PAGEREF _Toc990976813 \h + 1 +

+ +

+Annex B (informative) Title +. + + + PAGEREF _Toc418019641 \h + 1 +

+ +

+Annex C (informative) Revision History +. + + + PAGEREF _Toc275980653 \h + 1 +

+ +

+Bibliography +. + + + PAGEREF _Toc928875859 \h + 1 +

+ +

 

+ +
+
+

Copyright notice

+ + +

Copyright + © 2023 Open Geospatial Consortium
+ To obtain additional rights of use, visit + https://www.ogc.org/legal +

+
+

Note

+ +

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.

+
+
+ + +
+ + +

Notice for Drafts

+ +

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

+ +

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

+
+ + + + + +
+ + + + + +


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):

Arizona Geological Survey (AzGS), Arizona, USA

+

British Geological Survey (NERC-BGS), UK

+

Bureau de Recherches Géologiques et Minières (BRGM), France

+

Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia

+

Geological Survey of Victoria (GSV), Australia

+

Geological Survey of Finland (GTK), Finland

+

Geological Survey of Italy (ISPRA), Italy

+

Geological Survey of Sweden (SGU), Sweden

+

Geoscience Australia (GA), Australia

+

Institute of Geological and Nuclear Sciences (GNS), New Zealand

+

Landcare Research, New Zealand

+

Natural Resources Canada (NRCan), Canada

+

U.S. Geological Survey (USGS), United States of America

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:

AAAA +

+

BBBB +

+

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:

Any one of the conformance levels specified in Annex A (normative). +

+

Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative). +

+

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

http://www.example.org/req/blah +

+

urn:iso:ts:iso:19139:clause:6 +

+
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

The process input value is specified in-line in an execute request. +

+

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 +

Construct a path for the API Definition document that ends with /api. +

+

Issue a HTTP GET request on that path +

+

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 +

All compliance tests SHALL be configured to use the HTTP 1.1 protocol exclusively. +

+

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).

+ + +
+
+
+ + + + +------=_NextPart_015c3989.8eb6.4dff +Content-ID: +Content-Disposition: inline; filename="filelist.xml" +Content-Transfer-Encoding: base64 +Content-Type: application/xml + +PHhtbCB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiPgog +ICAgICAgIDxvOk1haW5GaWxlIEhSZWY9Ii4uLy9fX3cvT0dDLUdlb1NjaU1ML09HQy1HZW9TY2lN +TC9tYWluL2RvY3MvaW5kZXguaHRtIi8+ICA8bzpGaWxlIEhSZWY9ImZpbGVsaXN0LnhtbCIvPgog +IDxvOkZpbGUgSFJlZj0iaGVhZGVyLmh0bWwiLz4KPC94bWw+Cg== + +------=_NextPart_015c3989.8eb6.4dff +Content-ID: +Content-Disposition: inline; filename="header.html" +Content-Transfer-Encoding: base64 +Content-Type: text/html charset="utf-8" + +PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpvPSJ1 +cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1cm46c2No +ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMu +bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIg0KeG1sbnM6bXY9Imh0dHA6Ly9tYWNW +bWxTY2hlbWFVcmkiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0K +PGhlYWQ+DQo8bWV0YSBuYW1lPVRpdGxlIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPUtleXdvcmRz +IGNvbnRlbnQ9IiI+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0 +L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1Qcm9nSWQgY29udGVudD1Xb3JkLkRv +Y3VtZW50Pg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUi +Pg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxs +aW5rIGlkPU1haW4tRmlsZSByZWw9TWFpbi1GaWxlIGhyZWY9Ii4uLy9fX3cvT0dDLUdlb1NjaU1M +L09HQy1HZW9TY2lNTC9tYWluL2RvY3MvaW5kZXguaHRtbCI+DQo8IS0tW2lmIGd0ZSBtc28gOV0+ +PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIyMDQ5Ii8+DQo8 +L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTiBsaW5rPWJsdWUgdmxp +bms9IiM5NTRGNzIiPg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpmb290bm90ZS1zZXBhcmF0 +b3InIGlkPWZzPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MGNt +O21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoNCm5vcm1hbCc+PHNwYW4gbGFuZz1F +Ti1HQj48c3BhbiBzdHlsZT0nbXNvLXNwZWNpYWwtY2hhcmFjdGVyOmZvb3Rub3RlLXNlcGFyYXRv +cic+PCFbaWYgIXN1cHBvcnRGb290bm90ZXNdPg0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lk +dGg9IjMzJSI+DQoNCjwhW2VuZGlmXT48L3NwYW4+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxk +aXYgc3R5bGU9J21zby1lbGVtZW50OmZvb3Rub3RlLWNvbnRpbnVhdGlvbi1zZXBhcmF0b3InIGlk +PWZjcz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBjbTttYXJn +aW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6DQpub3JtYWwnPjxzcGFuIGxhbmc9RU4tR0I+ +PHNwYW4gc3R5bGU9J21zby1zcGVjaWFsLWNoYXJhY3Rlcjpmb290bm90ZS1jb250aW51YXRpb24t +c2VwYXJhdG9yJz48IVtpZiAhc3VwcG9ydEZvb3Rub3Rlc10+DQoNCjxociBhbGlnbj1sZWZ0IHNp +emU9MT4NCg0KPCFbZW5kaWZdPjwvc3Bhbj48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdiBz +dHlsZT0nbXNvLWVsZW1lbnQ6ZW5kbm90ZS1zZXBhcmF0b3InIGlkPWVzPg0KDQo8cCBjbGFzcz1N +c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDts +aW5lLWhlaWdodDoNCm5vcm1hbCc+PHNwYW4gbGFuZz1FTi1HQj48c3BhbiBzdHlsZT0nbXNvLXNw +ZWNpYWwtY2hhcmFjdGVyOmZvb3Rub3RlLXNlcGFyYXRvcic+PCFbaWYgIXN1cHBvcnRGb290bm90 +ZXNdPg0KDQo8aHIgYWxpZ249bGVmdCBzaXplPTEgd2lkdGg9IjMzJSI+DQoNCjwhW2VuZGlmXT48 +L3NwYW4+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYgc3R5bGU9J21zby1lbGVtZW50OmVu +ZG5vdGUtY29udGludWF0aW9uLXNlcGFyYXRvcicgaWQ9ZWNzPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt +YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhl +aWdodDoNCm5vcm1hbCc+PHNwYW4gbGFuZz1FTi1HQj48c3BhbiBzdHlsZT0nbXNvLXNwZWNpYWwt +Y2hhcmFjdGVyOmZvb3Rub3RlLWNvbnRpbnVhdGlvbi1zZXBhcmF0b3InPjwhW2lmICFzdXBwb3J0 +Rm9vdG5vdGVzXT4NCg0KPGhyIGFsaWduPWxlZnQgc2l6ZT0xPg0KDQo8IVtlbmRpZl0+PC9zcGFu +Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpoZWFkZXIn +IGlkPWVoMT4NCg0KPHAgY2xhc3M9TXNvSGVhZGVyIGFsaWduPWxlZnQgc3R5bGU9J3RleHQtYWxp +Z246bGVmdDtsaW5lLWhlaWdodDoxMi4wcHQ7DQptc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5 +Jz48c3BhbiBsYW5nPUVOLUdCPk9wZW4gR2Vvc3BhdGlhbCBDb25zb3J0aXVtJm5ic3A7MTYtMDA4 +PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYgc3R5bGU9J21zby1lbGVtZW50OmhlYWRlcicg +aWQ9aDE+DQoNCjxwIGNsYXNzPU1zb0hlYWRlciBzdHlsZT0nbWFyZ2luLWJvdHRvbToxOC4wcHQn +PjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQt +c2l6ZToxMS4wcHQ7Zm9udC13ZWlnaHQ6bm9ybWFsJz4NCk9wZW4gR2Vvc3BhdGlhbCBDb25zb3J0 +aXVtJm5ic3A7MTYtMDA4PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXdlaWdo +dDpub3JtYWwnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYgc3R5bGU9 +J21zby1lbGVtZW50OmZvb3RlcicgaWQ9ZWYxPg0KDQo8cCBjbGFzcz1Nc29Gb290ZXIgc3R5bGU9 +J21hcmdpbi10b3A6MTIuMHB0O2xpbmUtaGVpZ2h0OjEyLjBwdDttc28tbGluZS1oZWlnaHQtcnVs +ZToNCmV4YWN0bHknPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PGIgc3R5bGU9J21zby1iaWRpLWZv +bnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4NCmxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4w +cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+PHNwYW4NCnN0eWxlPSdtc28tZWxlbWVudDpm +aWVsZC1iZWdpbic+PC9zcGFuPjxzcGFuDQpzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+wqA8L3Nw +YW4+UEFHRTxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz7CoMKgDQo8L3NwYW4+XCogTUVS +R0VGT1JNQVQgPHNwYW4gc3R5bGU9J21zby1lbGVtZW50OmZpZWxkLXNlcGFyYXRvcic+PC9zcGFu +Pjwvc3Bhbj48L2I+PCFbZW5kaWZdLS0+PGINCnN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpu +b3JtYWwnPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYmlk +aS1mb250LXNpemU6MTEuMHB0Jz48c3BhbiBzdHlsZT0nbXNvLW5vLXByb29mOnllcyc+Mjwvc3Bh +bj48L3NwYW4+PC9iPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PGINCnN0eWxlPSdtc28tYmlkaS1m +b250LXdlaWdodDpub3JtYWwnPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4w +cHQ7DQptc28tYmlkaS1mb250LXNpemU6MTEuMHB0Jz48c3BhbiBzdHlsZT0nbXNvLWVsZW1lbnQ6 +ZmllbGQtZW5kJz48L3NwYW4+PC9zcGFuPjwvYj48IVtlbmRpZl0tLT48c3Bhbg0KbGFuZz1FTi1H +QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0Jz48c3Bh +bg0Kc3R5bGU9J21zby10YWItY291bnQ6MSc+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8L3NwYW4+wqkgT3BlbiBHZW9zcGF0aWFsIENvbnNv +cnRpdW0mbmJzcDsyMDIzIOKAkyBBbGwgcmlnaHRzIHJlc2VydmVkPG86cD48L286cD48L3NwYW4+ +PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdiBzdHlsZT0nbXNvLWVsZW1lbnQ6aGVhZGVyJyBpZD1laDI+ +DQo8cCBjbGFzcz1Nc29IZWFkZXIgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0O2xp +bmUtaGVpZ2h0OjEyLjBwdDsNCm1zby1saW5lLWhlaWdodC1ydWxlOmV4YWN0bHknPjxzcGFuIGxh +bmc9RU4tR0I+T3BlbiBHZW9zcGF0aWFsIENvbnNvcnRpdW0mbmJzcDsxNi0wMDg8L3NwYW4+PC9w +Pg0KPC9kaXY+DQoNCjxkaXYgc3R5bGU9J21zby1lbGVtZW50OmhlYWRlcicgaWQ9ZWgybD4NCjxw +IGNsYXNzPU1zb0hlYWRlckxhbmRzY2FwZSBhbGlnbj1sZWZ0IHN0eWxlPSd0ZXh0LWFsaWduOmxl +ZnQ7bGluZS1oZWlnaHQ6MTIuMHB0Ow0KbXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSc+PHNw +YW4gbGFuZz1FTi1HQj5PcGVuIEdlb3NwYXRpYWwgQ29uc29ydGl1bSZuYnNwOzE2LTAwODwvc3Bh +bj48L3A+DQo8L2Rpdj4NCg0KPGRpdiBzdHlsZT0nbXNvLWVsZW1lbnQ6aGVhZGVyJyBpZD1oMj4N +CjxwIGNsYXNzPU1zb0hlYWRlciBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodDts +aW5lLWhlaWdodDoxMi4wcHQ7DQptc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Jz48c3BhbiBs +YW5nPUVOLUdCPk9wZW4gR2Vvc3BhdGlhbCBDb25zb3J0aXVtJm5ic3A7MTYtMDA4PC9zcGFuPjwv +cD4NCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpoZWFkZXInIGlkPWgybD4NCjxw +IGNsYXNzPU1zb0hlYWRlckxhbmRzY2FwZSBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpy +aWdodDtsaW5lLWhlaWdodDoxMi4wcHQ7DQptc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Jz48 +c3BhbiBsYW5nPUVOLUdCPk9wZW4gR2Vvc3BhdGlhbCBDb25zb3J0aXVtJm5ic3A7MTYtMDA4PC9z +cGFuPjwvcD4NCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpmb290ZXInIGlkPWVm +Mj4NCjxwIGNsYXNzPU1zb0Zvb3RlciBzdHlsZT0nbGluZS1oZWlnaHQ6MTIuMHB0O21zby1saW5l +LWhlaWdodC1ydWxlOmV4YWN0bHknPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PHNwYW4NCmxhbmc9 +RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+ +PHNwYW4NCnN0eWxlPSdtc28tZWxlbWVudDpmaWVsZC1iZWdpbic+PC9zcGFuPjxzcGFuDQpzdHls +ZT0nbXNvLXNwYWNlcnVuOnllcyc+wqA8L3NwYW4+UEFHRTxzcGFuIHN0eWxlPSdtc28tc3BhY2Vy +dW46eWVzJz7CoMKgDQo8L3NwYW4+XCogTUVSR0VGT1JNQVQgPHNwYW4gc3R5bGU9J21zby1lbGVt +ZW50OmZpZWxkLXNlcGFyYXRvcic+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0tLT48c3Bhbg0KbGFu +Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0 +Jz48c3Bhbg0Kc3R5bGU9J21zby1uby1wcm9vZjp5ZXMnPmlpPC9zcGFuPjwvc3Bhbj48IS0tW2lm +IHN1cHBvcnRGaWVsZHNdPjxzcGFuDQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 +O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLWVsZW1lbnQ6Zmll +bGQtZW5kJz48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXS0tPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxl +PSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuIA0Kc3R5 +bGU9J21zby10YWItY291bnQ6MSc+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoCA8L3NwYW4+wqkgT3BlbiBHZW9zcGF0aWFsIENvbnNvcnRpdW0m +bmJzcDsyMDIzJm5ic3A74oCTIEFsbCByaWdodHMgcmVzZXJ2ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 +L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpmb290ZXInIGlkPWVmMmw+ +DQo8cCBjbGFzcz1Nc29Gb290ZXJMYW5kc2NhcGUgc3R5bGU9J2xpbmUtaGVpZ2h0OjEyLjBwdDtt +c28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Jz48IS0tW2lmIHN1cHBvcnRGaWVsZHNdPjxzcGFu +DQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZTox +MS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLWVsZW1lbnQ6ZmllbGQtYmVnaW4nPjwvc3Bhbj48c3Bh +bg0Kc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPsKgPC9zcGFuPlBBR0U8c3BhbiBzdHlsZT0nbXNv +LXNwYWNlcnVuOnllcyc+wqDCoA0KPC9zcGFuPlwqIE1FUkdFRk9STUFUIDxzcGFuIHN0eWxlPSdt +c28tZWxlbWVudDpmaWVsZC1zZXBhcmF0b3InPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdLS0+PHNw +YW4NCmxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXpl +OjExLjBwdCc+PHNwYW4NCnN0eWxlPSdtc28tbm8tcHJvb2Y6eWVzJz5paTwvc3Bhbj48L3NwYW4+ +PCEtLVtpZiBzdXBwb3J0RmllbGRzXT48c3Bhbg0KbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl +OjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0Jz48c3Bhbg0Kc3R5bGU9J21zby1lbGVt +ZW50OmZpZWxkLWVuZCc+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0tLT48c3BhbiBsYW5nPUVOLUdC +DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0Jz48c3Bh +biANCnN0eWxlPSdtc28tdGFiLWNvdW50OjEnPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPC9zcGFuPsKpIE9wZW4gR2Vvc3BhdGlhbCBDb25z +b3J0aXVtJm5ic3A7MjAyMyZuYnNwO+KAkyBBbGwgcmlnaHRzIHJlc2VydmVkPG86cD48L286cD48 +L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdiBzdHlsZT0nbXNvLWVsZW1lbnQ6Zm9vdGVyJyBp +ZD1mMj4NCjxwIGNsYXNzPU1zb0Zvb3RlciBzdHlsZT0nbGluZS1oZWlnaHQ6MTIuMHB0Jz48c3Bh +biBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6 +MTEuMHB0Jz7CqSBPcGVuIEdlb3NwYXRpYWwgQ29uc29ydGl1bSZuYnNwOzIwMjMmbmJzcDvigJMg +QWxsDQpyaWdodHMgcmVzZXJ2ZWQ8c3BhbiBzdHlsZT0nbXNvLXRhYi1jb3VudDoxJz7CoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8L3NwYW4+PC9z +cGFuPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PHNwYW4NCmxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt +c2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+PHNwYW4NCnN0eWxlPSdtc28t +ZWxlbWVudDpmaWVsZC1iZWdpbic+PC9zcGFuPiBQQUdFPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1 +bjp5ZXMnPsKgwqANCjwvc3Bhbj5cKiBNRVJHRUZPUk1BVCA8c3BhbiBzdHlsZT0nbXNvLWVsZW1l +bnQ6ZmllbGQtc2VwYXJhdG9yJz48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXS0tPjxzcGFuDQpsYW5n +PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQn +PjxzcGFuDQpzdHlsZT0nbXNvLW5vLXByb29mOnllcyc+aWlpPC9zcGFuPjwvc3Bhbj48IS0tW2lm +IHN1cHBvcnRGaWVsZHNdPjxzcGFuDQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 +O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLWVsZW1lbnQ6Zmll +bGQtZW5kJz48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXS0tPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxl +PSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxvOnA+PC9vOnA+ +PC9zcGFuPjwvcD4NCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpmb290ZXInIGlk +PWYybD4NCjxwIGNsYXNzPU1zb0Zvb3RlckxhbmRzY2FwZSBzdHlsZT0nbGluZS1oZWlnaHQ6MTIu +MHB0Jz48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1m +b250LXNpemU6MTEuMHB0Jz7CqSBPcGVuIEdlb3NwYXRpYWwgQ29uc29ydGl1bSZuYnNwOzIwMjMm +bmJzcDvigJMgQWxsDQpyaWdodHMgcmVzZXJ2ZWQ8c3BhbiBzdHlsZT0nbXNvLXRhYi1jb3VudDox +Jz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 +L3NwYW4+PC9zcGFuPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PHNwYW4NCmxhbmc9RU4tR0Igc3R5 +bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+PHNwYW4NCnN0 +eWxlPSdtc28tZWxlbWVudDpmaWVsZC1iZWdpbic+PC9zcGFuPiBQQUdFPHNwYW4gc3R5bGU9J21z +by1zcGFjZXJ1bjp5ZXMnPsKgwqANCjwvc3Bhbj5cKiBNRVJHRUZPUk1BVCA8c3BhbiBzdHlsZT0n +bXNvLWVsZW1lbnQ6ZmllbGQtc2VwYXJhdG9yJz48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXS0tPjxz +cGFuDQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6 +ZToxMS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLW5vLXByb29mOnllcyc+aWlpPC9zcGFuPjwvc3Bh +bj48IS0tW2lmIHN1cHBvcnRGaWVsZHNdPjxzcGFuDQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp +emU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLWVs +ZW1lbnQ6ZmllbGQtZW5kJz48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXS0tPjxzcGFuIGxhbmc9RU4t +R0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxv +OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdtc28tZWxlbWVudDpm +b290ZXInIGlkPWVmMz4NCjxwIGNsYXNzPU1zb0Zvb3RlciBzdHlsZT0nbWFyZ2luLXRvcDoxMi4w +cHQ7bGluZS1oZWlnaHQ6MTIuMHB0O21zby1saW5lLWhlaWdodC1ydWxlOg0KZXhhY3RseSc+PCEt +LVtpZiBzdXBwb3J0RmllbGRzXT48YiBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFs +Jz48c3Bhbg0KbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250 +LXNpemU6MTEuMHB0Jz48c3Bhbg0Kc3R5bGU9J21zby1lbGVtZW50OmZpZWxkLWJlZ2luJz48L3Nw +YW4+PHNwYW4NCnN0eWxlPSdtc28tc3BhY2VydW46eWVzJz7CoDwvc3Bhbj5QQUdFPHNwYW4gc3R5 +bGU9J21zby1zcGFjZXJ1bjp5ZXMnPsKgwqANCjwvc3Bhbj5cKiBNRVJHRUZPUk1BVCA8c3BhbiBz +dHlsZT0nbXNvLWVsZW1lbnQ6ZmllbGQtc2VwYXJhdG9yJz48L3NwYW4+PC9zcGFuPjwvYj48IVtl +bmRpZl0tLT48Yg0Kc3R5bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4gbGFu +Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMS4w +cHQnPjxzcGFuIHN0eWxlPSdtc28tbm8tcHJvb2Y6eWVzJz4yPC9zcGFuPjwvc3Bhbj48L2I+PCEt +LVtpZiBzdXBwb3J0RmllbGRzXT48Yg0Kc3R5bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1h +bCc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCm1zby1iaWRpLWZv +bnQtc2l6ZToxMS4wcHQnPjxzcGFuIHN0eWxlPSdtc28tZWxlbWVudDpmaWVsZC1lbmQnPjwvc3Bh +bj48L3NwYW4+PC9iPjwhW2VuZGlmXS0tPjxzcGFuDQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp +emU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLXRh +Yi1jb3VudDoxJz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgIDwvc3Bhbj7CqSBPcGVuIEdlb3NwYXRpYWwgQ29uc29ydGl1bSZuYnNwOzIwMjMm +bmJzcDvigJMgQWxsIHJpZ2h0cyByZXNlcnZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k +aXY+DQoNCjxkaXYgc3R5bGU9J21zby1lbGVtZW50OmZvb3RlcicgaWQ9ZWYzbD4NCjxwIGNsYXNz +PU1zb0Zvb3RlckxhbmRzY2FwZSBzdHlsZT0nbWFyZ2luLXRvcDoxMi4wcHQ7bGluZS1oZWlnaHQ6 +MTIuMHB0O21zby1saW5lLWhlaWdodC1ydWxlOg0KZXhhY3RseSc+PCEtLVtpZiBzdXBwb3J0Rmll +bGRzXT48YiBzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3Bhbg0KbGFuZz1F +Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0Jz48 +c3Bhbg0Kc3R5bGU9J21zby1lbGVtZW50OmZpZWxkLWJlZ2luJz48L3NwYW4+PHNwYW4NCnN0eWxl +PSdtc28tc3BhY2VydW46eWVzJz7CoDwvc3Bhbj5QQUdFPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1 +bjp5ZXMnPsKgwqANCjwvc3Bhbj5cKiBNRVJHRUZPUk1BVCA8c3BhbiBzdHlsZT0nbXNvLWVsZW1l +bnQ6ZmllbGQtc2VwYXJhdG9yJz48L3NwYW4+PC9zcGFuPjwvYj48IVtlbmRpZl0tLT48Yg0Kc3R5 +bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n +Zm9udC1zaXplOjEwLjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuIHN0eWxl +PSdtc28tbm8tcHJvb2Y6eWVzJz4yPC9zcGFuPjwvc3Bhbj48L2I+PCEtLVtpZiBzdXBwb3J0Rmll +bGRzXT48Yg0Kc3R5bGU9J21zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4gbGFuZz1F +Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQn +PjxzcGFuIHN0eWxlPSdtc28tZWxlbWVudDpmaWVsZC1lbmQnPjwvc3Bhbj48L3NwYW4+PC9iPjwh +W2VuZGlmXS0tPjxzcGFuDQpsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1i +aWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuDQpzdHlsZT0nbXNvLXRhYi1jb3VudDoxJz7CoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDwvc3Bh +bj7CqSBPcGVuIEdlb3NwYXRpYWwgQ29uc29ydGl1bSZuYnNwOzIwMjMmbmJzcDvigJMgQWxsIHJp +Z2h0cyByZXNlcnZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYgc3R5 +bGU9J21zby1lbGVtZW50OmZvb3RlcicgaWQ9ZjM+DQo8cCBjbGFzcz1Nc29Gb290ZXIgc3R5bGU9 +J2xpbmUtaGVpZ2h0OjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1HQg0Kc3R5bGU9J2ZvbnQtc2l6ZTox +MC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+wqkgT3BlbiBHZW9zcGF0aWFsIENvbnNv +cnRpdW0mbmJzcDsyMDIzJm5ic3A74oCTIEFsbA0KcmlnaHRzIHJlc2VydmVkPHNwYW4gc3R5bGU9 +J21zby10YWItY291bnQ6MSc+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoCA8L3NwYW4+PC9zcGFuPjwhLS1baWYgc3VwcG9ydEZpZWxkc10+PGIN +CnN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdodDpub3JtYWwnPjxzcGFuIGxhbmc9RU4tR0Igc3R5 +bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYmlkaS1mb250LXNpemU6MTEuMHB0Jz48c3BhbiBz +dHlsZT0nbXNvLWVsZW1lbnQ6ZmllbGQtYmVnaW4nPjwvc3Bhbj4NClBBR0U8c3BhbiBzdHlsZT0n +bXNvLXNwYWNlcnVuOnllcyc+wqDCoCA8L3NwYW4+XCogTUVSR0VGT1JNQVQgPHNwYW4NCnN0eWxl +PSdtc28tZWxlbWVudDpmaWVsZC1zZXBhcmF0b3InPjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlm +XS0tPjxiDQpzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBsYW5nPUVO +LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+ +PHNwYW4gc3R5bGU9J21zby1uby1wcm9vZjp5ZXMnPjM8L3NwYW4+PC9zcGFuPjwvYj48IS0tW2lm +IHN1cHBvcnRGaWVsZHNdPjxiDQpzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsJz48 +c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KbXNvLWJpZGktZm9udC1z +aXplOjExLjBwdCc+PHNwYW4gc3R5bGU9J21zby1lbGVtZW50OmZpZWxkLWVuZCc+PC9zcGFuPjwv +c3Bhbj48L2I+PCFbZW5kaWZdLS0+PHNwYW4NCmxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox +MC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9wPg0K +PC9kaXY+DQoNCjxkaXYgc3R5bGU9J21zby1lbGVtZW50OmZvb3RlcicgaWQ9ZjNsPg0KPHAgY2xh +c3M9TXNvRm9vdGVyTGFuZHNjYXBlIHN0eWxlPSdsaW5lLWhlaWdodDoxMi4wcHQnPjxzcGFuIGxh +bmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4w +cHQnPsKpIE9wZW4gR2Vvc3BhdGlhbCBDb25zb3J0aXVtJm5ic3A7MjAyMyZuYnNwO+KAkyBBbGwN +CnJpZ2h0cyByZXNlcnZlZDxzcGFuIHN0eWxlPSdtc28tdGFiLWNvdW50OjEnPsKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC +oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg +wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPC9zcGFuPjwvc3Bh +bj48IS0tW2lmIHN1cHBvcnRGaWVsZHNdPjxiDQpzdHlsZT0nbXNvLWJpZGktZm9udC13ZWlnaHQ6 +bm9ybWFsJz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KbXNvLWJp +ZGktZm9udC1zaXplOjExLjBwdCc+PHNwYW4gc3R5bGU9J21zby1lbGVtZW50OmZpZWxkLWJlZ2lu +Jz48L3NwYW4+DQpQQUdFPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPsKgwqAgPC9zcGFu +PlwqIE1FUkdFRk9STUFUIDxzcGFuDQpzdHlsZT0nbXNvLWVsZW1lbnQ6ZmllbGQtc2VwYXJhdG9y +Jz48L3NwYW4+PC9zcGFuPjwvYj48IVtlbmRpZl0tLT48Yg0Kc3R5bGU9J21zby1iaWRpLWZvbnQt +d2VpZ2h0Om5vcm1hbCc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN +Cm1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuIHN0eWxlPSdtc28tbm8tcHJvb2Y6eWVz +Jz4zPC9zcGFuPjwvc3Bhbj48L2I+PCEtLVtpZiBzdXBwb3J0RmllbGRzXT48Yg0Kc3R5bGU9J21z +by1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbCc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z +aXplOjEwLjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQnPjxzcGFuIHN0eWxlPSdtc28t +ZWxlbWVudDpmaWVsZC1lbmQnPjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlmXS0tPjxzcGFuDQps +YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4w +cHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4N +Cg== + +------=_NextPart_015c3989.8eb6.4dff-- \ No newline at end of file diff --git a/docs/index.err b/docs/index.err new file mode 100644 index 0000000..9d0b3b4 --- /dev/null +++ b/docs/index.err @@ -0,0 +1,150 @@ +./index.err errors + + +== Document Attributes + +(): 'Interface' is not a permitted subtype of Standard: reverting to 'implementation' +(): draft is not an allowed status for standard + + +== AsciiDoc Input + +(Section: Bibliography): no anchor on reference, markup may be malformed: see +https://www.metanorma.com/author/topics/document-format/bibliography/ , +https://www.metanorma.com/author/iso/topics/markup/#bibliographies +: For citations in the text please use square brackets and consecutive numbers: [1], [2], [3] + # + + +== Anchors + +(XML Line 000274): Crossreference target OGC06-121r9 is undefined + +(XML Line 000332): normalised identifier in from http://www.opengis.net/spec/ABCD/m.n/req/req-class-a +

Requirements Class

  • +
    • +

  • urn:iso:ts:iso:19139:clause:6

    +
    • +
+(XML Line 000351): normalised identifier in from /req/req-class-a/req-name-1 +

Requirement ‘shall’ statement

 + +(XML Line 000443): Crossreference target ats_core_api-definition-success is undefined + /conf/core/api-definition-success +(XML Line 000462): Crossreference target rfc2818 is undefined + HTTP over TLS + + +== Style + +(): Prefatory material must be followed by (clause) Scope +(): Scope must be followed by Conformance +(): Normative References must be followed by Terms and Definitions + + +== Metanorma XML Style Warning + +(XML Line 000081): Table should have title + + + + + +(XML Line 000294): Hanging paragraph in clause + + 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.

+ + +(XML Line 000308): Hanging paragraph in clause + + Clauses not containing normative material +

Paragraph

+ + +(XML Line 000322): Hanging paragraph in clause + + Clause containing normative material +

Paragraph

+ + +(XML Line 000326): Hanging paragraph in clause + + Requirement Class A or Requirement A Example +

Paragraph – intro text for the requirement class.

+ +

Use the following table for Requirements Classes.

+(XML Line 000356): Table should have title +
NameAffiliation
Eric BoisvertGeological Survey of Canada (Natural Resources Canada)
Ollie Raymond
+ + + + +(XML Line 000407): Hanging paragraph in clause + + Conformance Class Abstract Test Suite (Normative) +

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

+ + +(XML Line 000412): Hanging paragraph in clause + + Conformance Class A +
label
+

+
+(XML Line 000476): Table should have title +
NamesDefinitionData types and valuesMultiplicity and use
+ + + + + + +== Requirements + +(XML Line 000332): Requirement class http___www.opengis.net_spec_ABCD_m.n_req_req-class-a has no corresponding Conformance class +

Requirements Class

  • +
    • +

  • urn:iso:ts:iso:19139:clause:6

    +
    • +
+(XML Line 000351): Requirement _req_req-class-a_req-name-1 has no corresponding Conformance test +

Requirement ‘shall’ statement

 + +(XML Line 000383): Requirement req_core_process-execute-input-inline-object has no corresponding Conformance test + label/req/req-class-a/req-name-2 + +

  1. The process input value is specified in-line in an execute request.

    +
    2. +

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

    +(XML Line 000428): Conformance test ats_core_api-definition-op has no corresponding Requirement + /req/req-class-a/req-name-1label/conf/core/api-definition-op

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

    +     + +

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

    +     +(XML Line 000428): Conformance test ats_core_api-definition-op has no corresponding Conformance class + /req/req-class-a/req-name-1label/conf/core/api-definition-op

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

    +     + +

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

    +     +(XML Line 000449): Conformance test ats_core_http has no corresponding Requirement + /req/req-class-a/req-name-2label/conf/core/http

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

    +     + +

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

    +     +(XML Line 000449): Conformance test ats_core_http has no corresponding Conformance class + /req/req-class-a/req-name-2label/conf/core/http

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

    +     + +

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

    +     + + +== Metanorma XML Syntax + +(XML Line 000110:91): element "clause" not allowed here; expected the element end-tag or element "submitters" +(XML Line 000133:50): element "foreword" not allowed here; expected the element end-tag or element "clause", "definitions", "floating-title" or "terms" +(XML Line 000336:91): attribute "metadata" not allowed here; expected attribute "columns", "keep-lines-together", "keep-with-next", "key", "multilingual-rendering" or "tag" diff --git a/docs/index.html b/docs/index.html new file mode 100644 index 0000000..3d88370 --- /dev/null +++ b/docs/index.html @@ -0,0 +1,1819 @@ + + +OGC Geoscience Markup Language - GeoSciML + + + + + + + + + + + + + + + + +
    +

    Draft

    +
    + +
    +

    OGC Standard

    +
    + + + +
    •
    + +
    + + +
    +
    + +
    + +
    + OGC Geoscience Markup Language - GeoSciML + +
    +
    + + + + + +
    + + + + + + + GeoSciML Modeling Team Editor + + Eric Boisvert Editor + + Marcus Sen Editor + + +
    + +
    + Submission Date: 2016-08-23 + Approval Date: 2016-11-29 + Publication Date: 2017-01-31 + External identifier of this OGC® document: http://www.opengis.net/doc/{doc-type}/{standard}/{m.n} + Internal identifier of this OGC® document: 16-008 + + +
    + +
    + + Version: 4.1
    + + + Additional Formats: + + XML + + + PDF + + + DOC + +
    + +
    + +
    + +
    + +
    +
    + OGC Standard +
    + +
    +

    Draft

    +
    +
    + +
    +
    + + +

    Notice for Drafts

    + +

    This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

    + +

    Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

    +
    + + + + + +
    +
    + + + +
    +
DateReleaseEditorPrimary clauses modifiedDescription
+ + + + + +
Document number:16-008
Document type:OGC Standard
Document subtype:Implementation
Document stage:Draft
Document language:English
+
+ +
+
+
+

Copyright notice

+ + +

Copyright + © 2023 Open Geospatial Consortium
+ To obtain additional rights of use, visit + https://www.ogc.org/legal +

+
+

Note

+ +

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.

+
+
+
+ +
+
+ +
+
+

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):

  • Arizona Geological Survey (AzGS), Arizona, USA
    • +
  • British Geological Survey (NERC-BGS), UK
    • +
  • Bureau de Recherches Géologiques et Minières (BRGM), France
    • +
  • Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia
    • +
  • Geological Survey of Victoria (GSV), Australia
    • +
  • Geological Survey of Finland (GTK), Finland
    • +
  • Geological Survey of Italy (ISPRA), Italy
    • +
  • Geological Survey of Sweden (SGU), Sweden
    • +
  • Geoscience Australia (GA), Australia
    • +
  • Institute of Geological and Nuclear Sciences (GNS), New Zealand
    • +
  • Landcare Research, New Zealand
    • +
  • Natural Resources Canada (NRCan), Canada
    • +
  • U.S. Geological Survey (USGS), United States of America

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:

  • AAAA

    +
    • +

  • BBBB

    +
    • +

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:

  • Any one of the conformance levels specified in Annex A (normative).

    +
    • +

  • Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).

    +
    • +

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. +

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

    +
    3. +
+
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. +

  2. Issue a HTTP GET request on that path

    +
    3. +

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

    +
    4. +
+ +
+
+ +

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. +

  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.

    +
    3. +
+
+
+

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).

+ + +
+ + + + + + + + + + + + + + + + + + + diff --git a/docs/index.presentation.xml b/docs/index.presentation.xml new file mode 100644 index 0000000..24a660a --- /dev/null +++ b/docs/index.presentation.xml @@ -0,0 +1,1063 @@ + + + +OGC Geoscience Markup Language - GeoSciML +./index.xml./index.pdf./index.dochttp://www.opengis.net/doc/{doc-type}/{standard}/{m.n}16-00816-0082017-01-312016-11-292016-08-23 +Arizona Geological Survey (AzGS), Arizona, USA + +British Geological Survey (NERC-BGS), UK + +Bureau de Recherches Géologiques et Minières (BRGM), France + +Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia + +Geological Survey of Victoria (GSV), Australia + +Geological Survey of Finland (GTK), Finland + +Geological Survey of Italy (ISPRA), Italy + +Geological Survey of Sweden (SGU), Sweden + +Geoscience Australia (GA), Australia + +Institute of Geological and Nuclear Sciences (GNS), New Zealand + +Landcare Research, New Zealand + +Natural Resources Canada (NRCan), Canada + +U.S. Geological Survey (USGS), United States of America + +GeoSciML Modeling Team + +Eric Boisvert + +Marcus Sen + +Open Geospatial Consortium +4.14.1.1en

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.

+draftDraft2023 +Open Geospatial Consortium +ogcdocOGC documentAPIopenapihtmlgeologygeosciencestratigraphyboreholegeochemistrygeophysicsrockfaultcontactfoldfossilUMLGMLXMLstandardimplementationtechnicalScopeSymbols and abbreviated termsAbbreviated termsSymbolsTable of contentsIntroductionPrefaceAbstractAcknowledgementsTerms and definitionsTerms, definitions, symbols and abbreviated termsTerms, definitions and symbolsTerms, definitions and abbreviated termsNormative referencesBibliographyPrefaceClauseAnnexAppendix

No terms and definitions are listed in this document.

+

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.

+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.There are no normative references in this document.

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 terms and definitions given in % additionally apply.

+

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 terms and definitions given in % and the following additionally apply.

+(%)%1 and %2%1, and %2%1 or %2%1, or %2%1 and %2%1 or %2%1 from %2%1 to %2spellout-ordinalNOTENoteNote % to entryListDefinition ListFigureDiagramFormulaFormulaTableRequirementRecommendationPermissionBoxRecommendation testRequirement testPermission testRecommendations classRequirements classPermissions classAbstract testConformance classKeyExampleExamplewherewhereWhole of textdraftinformativenormativemodifiedDEPRECATEDSOURCEandAll Parts%Spellout editioneditionversionList of figuresList of tablesList of recommendationsJanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecemberObligationDangerWarningCautionImportantSafety PrecautionsEditorial NoteSectionClausePartParagraphChapterPageTableAnnexFigureExampleNoteFormulamfncommonsgdualplpreppartadjadvnounverbdeprecatessupersedesnarrowerbroaderequivalentcomparecontrastseesee alsoClauseClausesAnnexAnnexesAppendixAppendixesNoteNotesNote % to entryNotes % to entryListListsFigureFiguresFormulaFormulasTableTablesRequirementRequirementsRecommendationRecommendationsPermissionPermissionsExampleExamplesPartPartsSectionSectionsParagraphParagraphsChapterChaptersPagePagesADMITTEDSubmittersNo security considerations have been made for this document.DraftWork Item DraftCandidate SWG DraftCandidate OAB Review DraftCandidate Public RFC DraftCandidate TC Vote DraftApprovedPublishedDeprecatedRescindedRetiredenLatnTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2 + +OGC Geoscience Markup Language - GeoSciML +./index.xml./index.pdf./index.dochttp://www.opengis.net/doc/{doc-type}/{standard}/{m.n}16-00816-0082017-01-312016-11-292016-08-23 +Arizona Geological Survey (AzGS), Arizona, USA + +British Geological Survey (NERC-BGS), UK + +Bureau de Recherches Géologiques et Minières (BRGM), France + +Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia + +Geological Survey of Victoria (GSV), Australia + +Geological Survey of Finland (GTK), Finland + +Geological Survey of Italy (ISPRA), Italy + +Geological Survey of Sweden (SGU), Sweden + +Geoscience Australia (GA), Australia + +Institute of Geological and Nuclear Sciences (GNS), New Zealand + +Landcare Research, New Zealand + +Natural Resources Canada (NRCan), Canada + +U.S. Geological Survey (USGS), United States of America + +GeoSciML Modeling Team + +Eric Boisvert + +Marcus Sen + +Open Geospatial Consortium +4.14.1.1enLatnGeoSciML 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. +draft2023 +Open Geospatial Consortium +ogcdocOGC documentAPIopenapihtmlgeologygeosciencestratigraphyboreholegeochemistrygeophysicsrockfaultcontactfoldfossilUMLGMLXMLstandardimplementationtechnicalTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2 + + + + Copyright notice + + Copyright + © 2023 Open Geospatial Consortium + To obtain additional rights of use, visit + https://www.ogc.org/legal + + + + Note + 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. + + + + + License Agreement + + Use of this document is subject to the license agreement at + https://www.ogc.org/license + + + + + + + + Notice for Drafts + This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard. + + Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. + + + + + + + + + + + + + + + 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/ + + + + +AbstractGeoSciML 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. + +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 + +Preface +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. + +Security considerations +No security considerations have been made for this Standard. + +Submitting Organizations +The following organizations submitted this Document to the + Open Geospatial Consortium (OGC): + Arizona Geological Survey (AzGS), Arizona, USA +British Geological Survey (NERC-BGS), UK +Bureau de Recherches Géologiques et Minières (BRGM), France +Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia +Geological Survey of Victoria (GSV), Australia +Geological Survey of Finland (GTK), Finland +Geological Survey of Italy (ISPRA), Italy +Geological Survey of Sweden (SGU), Sweden +Geoscience Australia (GA), Australia +Institute of Geological and Nuclear Sciences (GNS), New Zealand +Landcare Research, New Zealand +Natural Resources Canada (NRCan), Canada +U.S. Geological Survey (USGS), United States of America + + +Submitters +All questions regarding this submission should be directed to the editor or the submitters: + +Name +Affiliation +Eric Boisvert +Geological Survey of Canada (Natural Resources Canada) +Ollie Raymond +Geoscience Australia +Marcus Sen +British Geological Survey + + + + + +Keywords + + + +Preface +The primary goal of this specification is to capture the semantics, schema, and encoding syntax of key elements described and portrayed in geological maps and databases, in order to enable information systems to interoperate with such data. + +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. + + + + + +Submitting organizations + + + + +Contributors +Additional contributors to this Standard include the following: + +Edward Lewis, British Geological Survey + + + +Scope +Insert Scope text here. Give the subject of the document and the aspects of that scope covered by the document. + + + + +Conformance +This standard defines XXXX. + +Requirements for N standardization target types are considered: + +AAAA + +BBBB + + + +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: + +Any one of the conformance levels specified in Annex A (normative). + +Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative). + + + +All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified. + + + + + +Terms and definitionsThis 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 , 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. + + +example term + + +term used for exemplary purposes + + + + + + + An example note. +Here’s an example of an example term. + + + + +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. + + +Identifiers +The normative provisions in this standard are denoted by the URI + + + +All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base. + + + + +Clauses not containing normative material +Paragraph + + +Clauses not containing normative material sub-clause 1 +Paragraph + + + +Clauses not containing normative material sub-clause 2 + + + + +Clause containing normative material +Paragraph + + +Requirement Class A or Requirement A Example +Paragraph – intro text for the requirement class. + +Use the following table for Requirements Classes. + +Requirements Class + +urn:iso:ts:iso:19139:clause:6 + + + + + + + + + +Requirement 1 +Paragraph — intro text for the requirement. + +Use the following table for Requirements, number sequentially. + + Requirement ‘shall’ statement + + +Dictionary tables for requirements can be added as necessary. Modify the following example as needed. + +Names +Definition +Data types and values +Multiplicity and use + +name 1 +definition of name 1 +float +One or more (mandatory) +name 2 +definition of name 2 +character string type, not empty +Zero or one (optional) +name 3 +definition of name 3 +GML:: Point PropertyType +One (mandatory) + + + + + +Requirement 2 +Paragraph — intro text for the requirement. + +Use the following table for Requirements, number sequentially. + + label/req/req-class-a/req-name-2 + +The process input value is specified in-line in an execute request. + +The process input is defined as an object according to its schema. + + + +The server SHALL support process input values encoded as qualified values. + +The value of the value key SHALL be an object instance. + + + + + + +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 then this section may be used to define a new MIME type for registration with IANA. + + + + + + + + + + +Conformance Class Abstract Test Suite (Normative) +Ensure that there is a conformance class for each requirements class and a test for each requirement (identified by requirement name and number) + + + +Conformance Class A +label + + +subject +Requirements Class “example1” + +classification +Target Type:Web API + + + + + +Example 1 + /req/req-class-a/req-name-1label/conf/core/api-definition-opValidate that the API Definition document can be retrieved from the expected location. + + +Construct a path for the API Definition document that ends with /api. + +Issue a HTTP GET request on that path + +Validate the contents of the returned document using test /conf/core/api-definition-success. + + + + +Example 2 + /req/req-class-a/req-name-2label/conf/core/httpValidate that the resource paths advertised through the API conform with HTTP 1.1 and, where appropriate, TLS. + + +All compliance tests SHALL be configured to use the HTTP 1.1 protocol exclusively. + +For APIs which support HTTPS, all compliance tests SHALL be configured to use HTTP over TLS (RFC 2818) with their HTTP 1.1 protocol. + + + + +Title +Place other Annex material in sequential annexes beginning with “B” and leave final two annexes for the Revision History and Bibliography + + +Revision History +Date +Release +Editor +Primary clauses modified +Description + +2016-04-28 +0.1 +G. Editor +all +initial version + + + +Normative referencesThe 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)Identification of Common Molecular Subsequences +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)ZIB Structure Prediction Pipeline +The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).The Grid +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)Grid Information Services for Distributed Resource Sharing +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)The Physiology of the Grid +National Center for Biotechnology Information, NCBI + 2023-03-16 +Geographic information + +Reference model + +Part 1: Fundamentals + +Geographic information — Reference model — Part 1: Fundamentals + https://www.iso.org/standard/59164.html https://www.iso.org/obp/ui/#!iso:std:59164:en https://www.iso.org/contents/data/standard/05/91/59164.detail.rss ISO 19101-1:2014 urn:iso:std:iso:19101:-1:stage-90.93:ed-1 19101 2014-11 +International Organization for Standardization + ISO www.iso.org 1 en Latn ISO 19101-1:2014 defines the reference model for standardization in the field of geographic information. This reference model describes the notion of interoperability and sets forth the fundamentals by which this standardization takes place. Although structured in the context of information technology and information technology standards, ISO 19101-1:2014 is independent of any application development method or technology implementation approach. 90 93 2014 +ISO + ISO 19101:2002 ISO 19101:2002 + Geneva + 2023-03-16 +Geographic information + +Metadata + +Part 1: Fundamentals + +Geographic information — Metadata — Part 1: Fundamentals + https://www.iso.org/standard/53798.html https://www.iso.org/obp/ui/#!iso:std:53798:en https://www.iso.org/contents/data/standard/05/37/53798.detail.rss ISO 19115-1:2014 urn:iso:std:iso:19115:-1:stage-90.93:ed-1 19115 2014-04 +International Organization for Standardization + ISO www.iso.org 1 en Latn ISO 19115-1:2014 defines the schema required for describing geographic information and services by means of metadata. It provides information about the identification, the extent, the quality, the spatial and temporal aspects, the content, the spatial reference, the portrayal, distribution, and other properties of digital geographic data and services. ISO 19115-1:2014 is applicable to: -the cataloguing of all types of resources, clearinghouse activities, and the full description of datasets and services; -geographic services, geographic datasets, dataset series, and individual geographic features and feature properties. ISO 19115-1:2014 defines: -mandatory and conditional metadata sections, metadata entities, and metadata elements; -the minimum set of metadata required to serve most metadata applications (data discovery, determining data fitness for use, data access, data transfer, and use of digital data and services); -optional metadata elements to allow for a more extensive standard description of resources, if required; -a method for extending metadata to fit specialized needs. Though ISO 19115-1:2014 is applicable to digital data and services, its principles can be extended to many other types of resources such as maps, charts, and textual documents as well as non-geographic data. Certain conditional metadata elements might not apply to these other forms of data. 90 93 2014 +ISO + ISO 19115:2003 ISO 19115:2003 + ISO 19115:2003/Cor 1:2006 ISO 19115:2003/Cor 1:2006 + ISO 19115-1:2014/Amd 1:2018 ISO 19115-1:2014/Amd 1:2018 2019-06-13 + ISO 19115-1:2014/Amd 2:2020 ISO 19115-1:2014/Amd 2:2020 2019-06-13 + Geneva + 2023-03-16 +Geographic information + +Data quality + +Geographic information  — Data quality + https://www.iso.org/standard/32575.html https://www.iso.org/obp/ui/#!iso:std:32575:en https://www.iso.org/contents/data/standard/03/25/32575.detail.rss ISO 19157:2013 urn:iso:std:iso:19157:stage-90.92:ed-1 19157 2013-12 +International Organization for Standardization + ISO www.iso.org 1 en Latn ISO 19157:2013 establishes the principles for describing the quality of geographic data. It —  defines components for describing data quality; —  specifies components and content structure of a register for data quality measures; —  describes general procedures for evaluating the quality of geographic data; —  establishes principles for reporting data quality. ISO 19157:2013 also defines a set of data quality measures for use in evaluating and reporting data quality. It is applicable to data producers providing quality information to describe and assess how well a data set conforms to its product specification and to data users attempting to determine whether or not specific geographic data are of sufficient quality for their particular application. ISO 19157:2013 does not attempt to define minimum acceptable levels of quality for geographic data. 90 92 2013 +ISO + ISO 19113:2002 ISO 19113:2002 + ISO 19114:2003 ISO 19114:2003 + ISO/TS 19138:2006 ISO/TS 19138:2006 + ISO 19157-1 ISO 19157-1 2019-07-01 + ISO/AWI 19157-3 ISO/AWI 19157-3 2019-07-01 + ISO 19157:2013/Amd 1:2018 ISO 19157:2013/Amd 1:2018 2019-07-01 + Geneva + +Geographic information — Metadata — XML schema implementation +ISO 19139:2007191392007 +ISO + + 2023-03-16 +Geographic information + +Metadata + +Part 3: XML schema implementation for fundamental concepts + +Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts + https://www.iso.org/standard/80874.html https://www.iso.org/contents/data/standard/08/08/80874.detail.rss ISO 19115-3 urn:iso:std:iso:19115:-3:stage-draft:ed-1 19115 +International Organization for Standardization + ISO www.iso.org 1 en Latn 50 00 2023 +ISO/PRF + ISO/TS 19115-3:2016 ISO/TS 19115-3:2016 + 2023-03-16 +Geographic information + +Metadata + +Part 3: XML schema implementation for fundamental concepts + +Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts + https://www.iso.org/standard/80874.html https://www.iso.org/contents/data/standard/08/08/80874.detail.rss ISO 19115-3 urn:iso:std:iso:19115:-3:stage-draft:ed-1 19115 +International Organization for Standardization + ISO www.iso.org 1 en Latn 50 00 2023 +ISO/PRF + ISO/TS 19115-3:2016 ISO/TS 19115-3:2016 + Geneva + Geneva +OGC Geospatial User Feedback Standard: Conceptual Model (2016)OGC 15-09715-097 + 2023-03-16 +OGC City Geography Markup Language (CityGML) Encoding Standard + +OGC City Geography Markup Language (CityGML) Encoding Standard + https://portal.ogc.org/files/?artifact_id=47842 12-019 2012-04-04 + Gerhard Gröger + + Thomas H. Kolbe + + Claus Nagel + + Karl-Heinz Häfele + +Open Geospatial Consortium + en Latn CityGML is an open data model and XML-based format for the storage and exchange of virtual 3D city models. It is an application schema for the Geography Markup Language version 3.1.1 (GML3), the extendible international standard for spatial data exchange issued by the Open Geospatial Consortium (OGC) and the ISO TC211. The aim of the development of CityGML is to reach a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields. + 2023-03-16 +OGC® IndoorGML + +OGC® IndoorGML + https://docs.ogc.org/is/14-005r3/14-005r3.html 14-005r3 2014-12-02 + Jiyeong Lee + + Ki-Joune Li + + Sisi Zlatanova + + Thomas H. Kolbe + + Claus Nagel + + Thomas Becker + +Open Geospatial Consortium + 3 en Latn This OGC® IndoorGML standard specifies an open data model and XML schema for indoor spatial information. IndoorGML is an application schema of OGC® GML 3.2.1. While there are several 3D building modelling standards such as CityGML, KML, and IFC, which deal with interior space of buildings from geometric, cartographic, and semantic viewpoints, IndoorGML intentionally focuses on modelling indoor spaces for navigation purposes. + 2023-03-16 +OGC Web Service Common Implementation Specification + +OGC Web Service Common Implementation Specification + https://portal.ogc.org/files/?artifact_id=38867 06-121r9 2010-04-07 + Arliss Whiteside Jim Greenwood + +Open Geospatial Consortium + 9 en Latn This document specifies many of the aspects that are, or should be, common to all or multiple OGC Web Service (OWS) interface Implementation Standards. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Of course, each such Implementation Standard must specify the additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses. + +Bibliography +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, + + OGC: OGC Testbed 12 Annex B: Architecture (2015). + OGCTB12 + 12 + + + + +sourcecode table td { padding: 5px; } +sourcecode table pre { margin: 0; } +sourcecode, sourcecode .w { + color: #444444; +} +sourcecode .cp { + color: #CC00A3; +} +sourcecode .cs { + color: #CC00A3; +} +sourcecode .c, sourcecode .ch, sourcecode .cd, sourcecode .cm, sourcecode .cpf, sourcecode .c1 { + color: #FF0000; +} +sourcecode .kc { + color: #C34E00; +} +sourcecode .kd { + color: #0000FF; +} +sourcecode .kr { + color: #007575; +} +sourcecode .k, sourcecode .kn, sourcecode .kp, sourcecode .kt, sourcecode .kv { + color: #0000FF; +} +sourcecode .s, sourcecode .sb, sourcecode .sc, sourcecode .ld, sourcecode .sd, sourcecode .s2, sourcecode .se, sourcecode .sh, sourcecode .si, sourcecode .sx, sourcecode .sr, sourcecode .s1, sourcecode .ss { + color: #009C00; +} +sourcecode .sa { + color: #0000FF; +} +sourcecode .nb, sourcecode .bp { + color: #C34E00; +} +sourcecode .nt { + color: #0000FF; +} + + + + + + Copyright notice + +

Copyright + © 2023 Open Geospatial Consortium
+ To obtain additional rights of use, visit + https://www.ogc.org/legal +

+ + + Note +

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.

+ + + + + License Agreement + +

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

+ + + + + + + + Notice for Drafts +

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

+ +

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

+ + + + + + + + + + + + + + +

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.<tab/>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.<tab/>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.<tab/>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.<tab/>Security considerations +

No security considerations have been made for this Standard.

+ +V.<tab/>Submitting Organizations +

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

+
  • Arizona Geological Survey (AzGS), Arizona, USA
    • +
  • British Geological Survey (NERC-BGS), UK
    • +
  • Bureau de Recherches Géologiques et Minières (BRGM), France
    • +
  • Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia
    • +
  • Geological Survey of Victoria (GSV), Australia
    • +
  • Geological Survey of Finland (GTK), Finland
    • +
  • Geological Survey of Italy (ISPRA), Italy
    • +
  • Geological Survey of Sweden (SGU), Sweden
    • +
  • Geoscience Australia (GA), Australia
    • +
  • Institute of Geological and Nuclear Sciences (GNS), New Zealand
    • +
  • Landcare Research, New Zealand
    • +
  • Natural Resources Canada (NRCan), Canada
    • +
  • U.S. Geological Survey (USGS), United States of America
+ + +VI.<tab/>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
+ + + +5.<tab/>Keywords + + + +Preface +NOTE

The primary goal of this specification is to capture the semantics, schema, and encoding syntax of key elements described and portrayed in geological maps and databases, in order to enable information systems to interoperate with such data.

+ +

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.

+ + + + + +6.<tab/>Submitting organizations + + + + +7.<tab/>Contributors +

Additional contributors to this Standard include the following:

+ +

Edward Lewis, British Geological Survey

+ + + +1.<tab/>Scope +NOTE

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

+ + + + +2.<tab/>Conformance +

This standard defines XXXX.

+ +

Requirements for N standardization target types are considered:

+ +

  • AAAA

    +
    • +

  • BBBB

    +
    • +
+ +

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:

+ +

  • Any one of the conformance levels specified in Annex A (normative).

    +
    • +

  • Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).

    +
    • +
+ +

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

+ + + + + +4.<tab/>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] + + + +8.<tab/>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.<tab/>Identifiers +

The normative provisions in this standard are denoted by the URI

+ +

+ +

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

+ + + + +9.<tab/>Clauses not containing normative material +

Paragraph

+ + +9.1.<tab/>Clauses not containing normative material sub-clause 1 +

Paragraph

+ + + +9.2.<tab/>Clauses not containing normative material sub-clause 2 + + + + +10.<tab/>Clause containing normative material +

Paragraph

+ + +10.1.<tab/>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

  • +
    • +

  • urn:iso:ts:iso:19139:clause:6

    +
    • +
Normative statementsRequirement 1-1
Requirement 1-2
+ + +10.1.1.<tab/>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.<tab/>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. +

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

    +
    3. +
+
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.<tab/>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 then this section may be used to define a new MIME type for registration with IANA.

+ + + + + + + + + + +<strong>Annex A</strong><br/>(informative)<br/><strong>Conformance Class Abstract Test Suite (Normative)</strong> +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.<tab/>Conformance Class A +Example
label
+

+
+
subject
+

Requirements Class “example1”

+
+
classification
+

Target Type:Web API

+
+
+ + + +A.1.1.<tab/>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. +

  2. Issue a HTTP GET request on that path

    +
    3. +

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

    +
    4. +
+ +
+ + + +A.1.2.<tab/>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. +

  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.

    +
    3. +
+
+ + + +<strong>Annex B</strong><br/>(informative)<br/><strong>Title</strong> +NOTE

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

+ + +<strong>Annex C</strong><br/>(informative)<br/><strong>Revision History</strong> +Table C.1 + + + + + + + + + + + +
DateReleaseEditorPrimary clauses modifiedDescription
2016-04-280.1G. Editorallinitial version
+ +3.<tab/>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)Identification of Common Molecular Subsequences +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)ZIB Structure Prediction Pipeline +The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).The Grid +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)Grid Information Services for Distributed Resource Sharing +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)The Physiology of the Grid +National Center for Biotechnology Information, NCBI +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.https://www.iso.org/standard/59164.htmlhttps://www.iso.org/obp/ui/#!iso:std:59164:enhttps://www.iso.org/contents/data/standard/05/91/59164.detail.rssISO 19101-1:2014URN urn:iso:std:iso:19101:-1:stage-90.93:ed-1 90 93 + ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.https://www.iso.org/standard/53798.htmlhttps://www.iso.org/obp/ui/#!iso:std:53798:enhttps://www.iso.org/contents/data/standard/05/37/53798.detail.rssISO 19115-1:2014URN urn:iso:std:iso:19115:-1:stage-90.93:ed-1 90 93 + ISO: ISO 19157:2013, Geographic information  — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.https://www.iso.org/standard/32575.htmlhttps://www.iso.org/obp/ui/#!iso:std:32575:enhttps://www.iso.org/contents/data/standard/03/25/32575.detail.rssISO 19157:2013URN urn:iso:std:iso:19157:stage-90.92:ed-1 90 92 +ISO: ISO 19139:2007, Geographic information — Metadata — XML schema implementation. ISO (2007).ISO 19139: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.https://www.iso.org/standard/80874.htmlhttps://www.iso.org/contents/data/standard/08/08/80874.detail.rssISO 19115-3URN urn:iso:std:iso:19115:-3:stage-draft:ed-1 50 00 +OGC Geospatial User Feedback Standard: Conceptual Model (2016)OGC 15-09715-097 +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.https://portal.ogc.org/files/?artifact_id=47842OGC 12-019 + 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.https://docs.ogc.org/is/14-005r3/14-005r3.htmlOGC 14-005r3 + 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.https://portal.ogc.org/files/?artifact_id=38867OGC 06-121r9 + +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,

+ + OGC: OGC Testbed 12 Annex B: Architecture (2015).[1] + OGCTB12 + 12 +[1] + + + + diff --git a/docs/index.xml b/docs/index.xml new file mode 100644 index 0000000..5d71c4e --- /dev/null +++ b/docs/index.xml @@ -0,0 +1,548 @@ + + + +OGC Geoscience Markup Language - GeoSciML +./index.xml./index.pdf./index.dochttp://www.opengis.net/doc/{doc-type}/{standard}/{m.n}16-00816-0082017-01-312016-11-292016-08-23 +Arizona Geological Survey (AzGS), Arizona, USA + +British Geological Survey (NERC-BGS), UK + +Bureau de Recherches Géologiques et Minières (BRGM), France + +Commonwealth Scientific and Industrial Research Organisation (CSIRO), Australia + +Geological Survey of Victoria (GSV), Australia + +Geological Survey of Finland (GTK), Finland + +Geological Survey of Italy (ISPRA), Italy + +Geological Survey of Sweden (SGU), Sweden + +Geoscience Australia (GA), Australia + +Institute of Geological and Nuclear Sciences (GNS), New Zealand + +Landcare Research, New Zealand + +Natural Resources Canada (NRCan), Canada + +U.S. Geological Survey (USGS), United States of America + +GeoSciML Modeling Team + +Eric Boisvert + +Marcus Sen + +Open Geospatial Consortium +4.14.1.1en

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.

+draft2023 +Open Geospatial Consortium +ogcdocOGC documentAPIopenapihtmlgeologygeosciencestratigraphyboreholegeochemistrygeophysicsrockfaultcontactfoldfossilUMLGMLXMLstandardimplementationtechnicalTOC Heading Levels2HTML TOC Heading Levels2DOC TOC Heading Levels2 + + + + Copyright notice + +

Copyright + © 2023 Open Geospatial Consortium
+ To obtain additional rights of use, visit + https://www.ogc.org/legal +

+ + + Note +

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.

+ + + + + License Agreement + +

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

+ + + + + + + + Notice for Drafts +

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

+ +

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

+ + + + + + + + + + + + + + +

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/

+ + + + +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.

+ +Preface +

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.

+ +Security considerations +

No security considerations have been made for this Standard.

+ +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
+ + + +Keywords + + + +Preface +

The primary goal of this specification is to capture the semantics, schema, and encoding syntax of key elements described and portrayed in geological maps and databases, in order to enable information systems to interoperate with such data.

+ +

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.

+ + + + + +Submitting organizations + + + + +Contributors +

Additional contributors to this Standard include the following:

+ +

Edward Lewis, British Geological Survey

+ + + +Scope +

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

+ + + + +Conformance +

This standard defines XXXX.

+ +

Requirements for N standardization target types are considered:

+ +

  • AAAA

    +
    • +

  • BBBB

    +
    • +
+ +

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:

+ +

  • Any one of the conformance levels specified in Annex A (normative).

    +
    • +

  • Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).

    +
    • +
+ +

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

+ + + + + +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 , 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.

+ + +example term + + +

term used for exemplary purposes

 + + + + + + +

An example note.

+

Here’s an example of an example term.

+ + + + +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.

+ + +Identifiers +

The normative provisions in this standard are denoted by the URI

+ +

+ +

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

+ + + + +Clauses not containing normative material +

Paragraph

+ + +Clauses not containing normative material sub-clause 1 +

Paragraph

+ + + +Clauses not containing normative material sub-clause 2 + + + + +Clause containing normative material +

Paragraph

+ + +Requirement Class A or Requirement A Example +

Paragraph – intro text for the requirement class.

+ +

Use the following table for Requirements Classes.

+ +

Requirements Class

  • +
    • +

  • urn:iso:ts:iso:19139:clause:6

    +
    • +
 + + + + + + + +Requirement 1 +

Paragraph — intro text for the requirement.

+ +

Use the following table for Requirements, number sequentially.

+ +

Requirement ‘shall’ statement

 + + +

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

+ + + + + + + + + + + + + + + + + + + +
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)
+ + + +Requirement 2 +

Paragraph — intro text for the requirement.

+ +

Use the following table for Requirements, number sequentially.

+ + label/req/req-class-a/req-name-2 + +

  1. The process input value is specified in-line in an execute request.

    +
    2. +

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

    +
    3. +
+ +

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

+ +

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

+ + + + + + +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 then this section may be used to define a new MIME type for registration with IANA.

+ + + + + + + + + + +Conformance Class Abstract Test Suite (Normative) +

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

+ + + +Conformance Class A +
label
+

+
+
subject
+

Requirements Class “example1”

+
+
classification
+

Target Type:Web API

+
+
+ + + +Example 1 + /req/req-class-a/req-name-1label/conf/core/api-definition-op

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

+ + +

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

+ +

Issue a HTTP GET request on that path

+ +

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

+ + + + +Example 2 + /req/req-class-a/req-name-2label/conf/core/http

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

+ + +

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

+ +

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

+ + + + +Title +

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

+ + +Revision History + + + + + + + + + + + + +
DateReleaseEditorPrimary clauses modifiedDescription
2016-04-280.1G. Editorallinitial version
+ +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)Identification of Common Molecular Subsequences +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)ZIB Structure Prediction Pipeline +The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).The Grid +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)Grid Information Services for Distributed Resource Sharing +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)The Physiology of the Grid +National Center for Biotechnology Information, NCBI + 2023-03-16 +Geographic information + +Reference model + +Part 1: Fundamentals + +Geographic information — Reference model — Part 1: Fundamentals + https://www.iso.org/standard/59164.html https://www.iso.org/obp/ui/#!iso:std:59164:en https://www.iso.org/contents/data/standard/05/91/59164.detail.rss ISO 19101-1:2014 urn:iso:std:iso:19101:-1:stage-90.93:ed-1 19101 2014-11 +International Organization for Standardization + ISO www.iso.org 1 en ISO 19101-1:2014 defines the reference model for standardization in the field of geographic information. This reference model describes the notion of interoperability and sets forth the fundamentals by which this standardization takes place. Although structured in the context of information technology and information technology standards, ISO 19101-1:2014 is independent of any application development method or technology implementation approach. 90 93 2014 +ISO + ISO 19101:2002 ISO 19101:2002 + Geneva + 2023-03-16 +Geographic information + +Metadata + +Part 1: Fundamentals + +Geographic information — Metadata — Part 1: Fundamentals + https://www.iso.org/standard/53798.html https://www.iso.org/obp/ui/#!iso:std:53798:en https://www.iso.org/contents/data/standard/05/37/53798.detail.rss ISO 19115-1:2014 urn:iso:std:iso:19115:-1:stage-90.93:ed-1 19115 2014-04 +International Organization for Standardization + ISO www.iso.org 1 en ISO 19115-1:2014 defines the schema required for describing geographic information and services by means of metadata. It provides information about the identification, the extent, the quality, the spatial and temporal aspects, the content, the spatial reference, the portrayal, distribution, and other properties of digital geographic data and services. ISO 19115-1:2014 is applicable to: -the cataloguing of all types of resources, clearinghouse activities, and the full description of datasets and services; -geographic services, geographic datasets, dataset series, and individual geographic features and feature properties. ISO 19115-1:2014 defines: -mandatory and conditional metadata sections, metadata entities, and metadata elements; -the minimum set of metadata required to serve most metadata applications (data discovery, determining data fitness for use, data access, data transfer, and use of digital data and services); -optional metadata elements to allow for a more extensive standard description of resources, if required; -a method for extending metadata to fit specialized needs. Though ISO 19115-1:2014 is applicable to digital data and services, its principles can be extended to many other types of resources such as maps, charts, and textual documents as well as non-geographic data. Certain conditional metadata elements might not apply to these other forms of data. 90 93 2014 +ISO + ISO 19115:2003 ISO 19115:2003 + ISO 19115:2003/Cor 1:2006 ISO 19115:2003/Cor 1:2006 + ISO 19115-1:2014/Amd 1:2018 ISO 19115-1:2014/Amd 1:2018 2019-06-13 + ISO 19115-1:2014/Amd 2:2020 ISO 19115-1:2014/Amd 2:2020 2019-06-13 + Geneva + 2023-03-16 +Geographic information + +Data quality + +Geographic information  — Data quality + https://www.iso.org/standard/32575.html https://www.iso.org/obp/ui/#!iso:std:32575:en https://www.iso.org/contents/data/standard/03/25/32575.detail.rss ISO 19157:2013 urn:iso:std:iso:19157:stage-90.92:ed-1 19157 2013-12 +International Organization for Standardization + ISO www.iso.org 1 en ISO 19157:2013 establishes the principles for describing the quality of geographic data. It —  defines components for describing data quality; —  specifies components and content structure of a register for data quality measures; —  describes general procedures for evaluating the quality of geographic data; —  establishes principles for reporting data quality. ISO 19157:2013 also defines a set of data quality measures for use in evaluating and reporting data quality. It is applicable to data producers providing quality information to describe and assess how well a data set conforms to its product specification and to data users attempting to determine whether or not specific geographic data are of sufficient quality for their particular application. ISO 19157:2013 does not attempt to define minimum acceptable levels of quality for geographic data. 90 92 2013 +ISO + ISO 19113:2002 ISO 19113:2002 + ISO 19114:2003 ISO 19114:2003 + ISO/TS 19138:2006 ISO/TS 19138:2006 + ISO 19157-1 ISO 19157-1 2019-07-01 + ISO/AWI 19157-3 ISO/AWI 19157-3 2019-07-01 + ISO 19157:2013/Amd 1:2018 ISO 19157:2013/Amd 1:2018 2019-07-01 + Geneva + +Geographic information — Metadata — XML schema implementation +ISO 19139:2007191392007 +ISO + + 2023-03-16 +Geographic information + +Metadata + +Part 3: XML schema implementation for fundamental concepts + +Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts + https://www.iso.org/standard/80874.html https://www.iso.org/contents/data/standard/08/08/80874.detail.rss ISO 19115-3 urn:iso:std:iso:19115:-3:stage-draft:ed-1 19115 +International Organization for Standardization + ISO www.iso.org 1 en 50 00 2023 +ISO/PRF + ISO/TS 19115-3:2016 ISO/TS 19115-3:2016 + 2023-03-16 +Geographic information + +Metadata + +Part 3: XML schema implementation for fundamental concepts + +Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts + https://www.iso.org/standard/80874.html https://www.iso.org/contents/data/standard/08/08/80874.detail.rss ISO 19115-3 urn:iso:std:iso:19115:-3:stage-draft:ed-1 19115 +International Organization for Standardization + ISO www.iso.org 1 en 50 00 2023 +ISO/PRF + ISO/TS 19115-3:2016 ISO/TS 19115-3:2016 + Geneva + Geneva +OGC Geospatial User Feedback Standard: Conceptual Model (2016)OGC 15-09715-097 + 2023-03-16 +OGC City Geography Markup Language (CityGML) Encoding Standard + +OGC City Geography Markup Language (CityGML) Encoding Standard + https://portal.ogc.org/files/?artifact_id=47842 12-019 2012-04-04 + Gerhard Gröger + + Thomas H. Kolbe + + Claus Nagel + + Karl-Heinz Häfele + +Open Geospatial Consortium + en CityGML is an open data model and XML-based format for the storage and exchange of virtual 3D city models. It is an application schema for the Geography Markup Language version 3.1.1 (GML3), the extendible international standard for spatial data exchange issued by the Open Geospatial Consortium (OGC) and the ISO TC211. The aim of the development of CityGML is to reach a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields. + 2023-03-16 +OGC® IndoorGML + +OGC® IndoorGML + https://docs.ogc.org/is/14-005r3/14-005r3.html 14-005r3 2014-12-02 + Jiyeong Lee + + Ki-Joune Li + + Sisi Zlatanova + + Thomas H. Kolbe + + Claus Nagel + + Thomas Becker + +Open Geospatial Consortium + 3 en This OGC® IndoorGML standard specifies an open data model and XML schema for indoor spatial information. IndoorGML is an application schema of OGC® GML 3.2.1. While there are several 3D building modelling standards such as CityGML, KML, and IFC, which deal with interior space of buildings from geometric, cartographic, and semantic viewpoints, IndoorGML intentionally focuses on modelling indoor spaces for navigation purposes. + 2023-03-16 +OGC Web Service Common Implementation Specification + +OGC Web Service Common Implementation Specification + https://portal.ogc.org/files/?artifact_id=38867 06-121r9 2010-04-07 + Arliss Whiteside Jim Greenwood + +Open Geospatial Consortium + 9 en This document specifies many of the aspects that are, or should be, common to all or multiple OGC Web Service (OWS) interface Implementation Standards. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Of course, each such Implementation Standard must specify the additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses. + +Bibliography +

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,

+ + OGC: OGC Testbed 12 Annex B: Architecture (2015). + OGCTB12 + 12 + + + + + diff --git a/docs/sections/clause_0_front_material.adoc b/docs/sections/clause_0_front_material.adoc index c2ebda3..b09d1ea 100644 --- a/docs/sections/clause_0_front_material.adoc +++ b/docs/sections/clause_0_front_material.adoc @@ -30,7 +30,9 @@ Attention is drawn to the possibility that some of the elements of this document [abstract] == 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. == Keywords @@ -40,7 +42,8 @@ Attention is drawn to the possibility that some of the elements of this document [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. > +The primary goal of this specification is to capture the semantics, schema, and encoding syntax of key elements described and portrayed in geological maps and databases, in order to enable information systems to interoperate with such data. + 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. @@ -69,7 +72,9 @@ All questions regarding this submission should be directed to the editor or the |=== |*Name* |*Affiliation* -| | +|Eric Boisvert |Geological Survey of Canada (Natural Resources Canada) +|Ollie Raymond |Geoscience Australia +|Marcus Sen | British Geological Survey |=== == Contributors @@ -78,4 +83,4 @@ All questions regarding this submission should be directed to the editor or the Additional contributors to this Standard include the following: -Individual name(s), Organization +Edward Lewis, British Geological Survey diff --git a/.github/workflows/docker.yml b/docs/workflows/docker.yml similarity index 100% rename from .github/workflows/docker.yml rename to docs/workflows/docker.yml diff --git a/.github/workflows/generate.yml b/docs/workflows/generate.yml similarity index 100% rename from .github/workflows/generate.yml rename to docs/workflows/generate.yml