Open Geospatial Consortium

Submission Date: <yyyy-mm-dd>

Approval Date:   <yyyy-mm-dd>

Publication Date:   <yyyy-mm-dd>

External identifier of this OGC® document:{m.n} (TODO)

Internal reference number of this OGC® document:    YY-nnnrx

Version: n.n

Category: OGC® Implementation Specification

Editor:   Martin Desruisseaux

OGC GeoAPI 3.1/4.0

Copyright notice

Copyright © 2009-2018 Open Geospatial Consortium

To obtain additional rights of use, visit


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.

Document type:    OGC® Standard

Document stage:    Draft

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.



This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

i. Abstract

The GeoAPI Implementation Standard defines application programming interfaces (API) in some programming languages (currently Java and Python) for geospatial applications. The API includes a set of types and methods which can be used for the manipulation of geographic information structured following the specifications adopted by the Technical Committee 211 of the International Organization for Standardization (ISO) and by the Open Geospatial Consortium (OGC). Those interfaces standardize the informatics contract between the client code, which manipulates normalized data structures of geographic information based on the published API, and the library code able both to instantiate and operate on these data structures according to the rules required by the published API and by the ISO and OGC standards.

This standard complements existing OGC standards by defining language specific layers of normalization. This standard does not replace the core standards developing the OGC/ISO abstract model but complements those documents for developers by documenting the mapping of types and methods from the abstract model into some programming languages, providing standard interfaces in the org.opengis or opengis namespaces and explaining the use of GeoAPI interfaces.

ii. Keywords

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

ogcdoc, OGC document, GeoAPI, programming, Java, Python, interface, geospatial, metadata, referencing, feature

iii. Preface

There is various libraries for helping developers to process geospatial data from programming languages like Java and Python. But the proliferation of API variations degrade interoperability. Since each library defines its own Application Programming Interface (API), the choice of a particular library result in a vendor lock-in situation even with open-source softwares. For example it is difficult for a Web Map Service (WMS) implementation to replace its map projection engine if all available engines use incompatible APIs. Standard API in programmatic language can reduce such vendor lock-in by providing a layer which separates client code, which call the API, from library code, which implements the API. This follows a similar pattern to the well known JDBC (in Java language) or ODBC (in C/C++ language) API which provides standardized interfaces to databases. Clients can use those APIs without concern for the particular implementation which they will use.

This GeoAPI standard evolved from an effort at the Open Geospatial Consortium (OGC) and in the free software community focused on developing a library of interfaces defining a coherent data model for the manipulation of geospatial data based on the data model defined in the OGC Abstract Specifications. GeoAPI interfaces originates with the publication in January 2001 of the implementation specification OGC 01-009 Coordinate Transformation Services Revision 1.00 (Martin Daly, ed.) which included a set of interfaces written in different programming languages and in the org.opengis namespace. The GeoAPI project started in 2003 as an effort from several contributors to develop a set of Java language interfaces which could be shared between several projects. The GeoAPI project subsequently considered the interfaces of OGC 01-009 as version 0.1 of GeoAPI and started working on GeoAPI 1.0 in collaboration with developers writing the OGC specification Geographic Objects. Subsequently, the Open Geospatial Consortium jettisoned its own Abstract Specifications and adopted, as the basis for further work, the standards developed by the Technical Committee 211 of the International Organization for Standardization (ISO) in its ISO 19100 series. The GeoAPI project therefore realigned its interfaces with those standards. In 2003, version 1.0 of GeoAPI interfaces was released to match the release of the first public draft of the implementation specification OGC 03-064 GO-1 Application Objects Version 1.0 (Greg Reynolds, ed.). The standardization effort of GO-1 took a couple of years during which extensive work was made on GeoAPI interfaces. Release 2.0 of GeoAPI was made at the time of the final publication of the GO-1 specification in 2005. GO-1 has been retired later, but a new working group has been formed in 2009 for continuing GeoAPI development with a more restricted scope: to provide interfaces for existing OGC standards only, without defining new conceptual models. GeoAPI 3.0.0 has been released in 2011 and GeoAPI 3.0.1 in 2017.

GeoAPI interfaces are derived from OGC/ISO conceptual models described by Unified Modeling Language (UML) diagrams. The XML schemas are generally not used (except when there is no UML diagrams describing the model) because they carry XML-specific constraints that do not apply to programming languages. For example querying the coordinate system associated to a Coordinate Reference System (CRS) is a single method call in GeoAPI. But this single operation would have required more than 50 lines of code if the API was generated from Geographic Markup Language (GML) schema instead than from the UML diagrams of abstract models.

The interfaces described in this standard follow closely, without introducing new concepts, from the previously published standards of the Open Geospatial Consortium and the International Organization for Standardization. Nonetheless, 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. Submitting organizations

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

Organization name(s)



v. Submitters

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

Name Affiliation

Martin Desruisseaux


1. Scope

GeoAPI contains a series of interfaces and classes in several packages which interpret into some programming languages (currently Java and Python) the data model and UML types of the ISO and OGC standards documents. The interfaces includes documentation which complement the injunctions of the OGC/ISO specifications by explaining particularities of GeoAPI: interpretations made of the specifications where there was room for choice, constraints specific to each programming language, or standard patterns of behavior expected by the community of a programming language. This document explains GeoAPI interfaces and defines its use by library code implementing the API and by client code calling the API. Jointly with the interface definitions, this work aims to provide:

  • a carefully considered interpretation of the OGC specifications for Java and Python languages,

  • a base structure to facilitate the creation of software libraries which implement OGC standards,

  • a well defined, full documented binding reducing the programming effort of using the OGC abstract model,

  • and to facilitate the portability of application code between different implementations.

The interfaces defined in this standard provide one way to structure the use of the Java and Python languages to implement softwares which follow the design and intents of the OGC/ISO specifications. The creators of the GeoAPI interfaces consider this approach as an effective compromise between the OGC specifications, the requirements of above-cited programming languages, and the tradition of the core libraries of those languages.

This version of the standard does not propose a complete set of interfaces covering the entire set of OGC/ISO abstract standards, but focuses on an initial group of interfaces only. This initial group of interfaces covers enough of the abstract model to permit the description of geospatial metadata, the definition of coordinate reference systems and to enable operations on coordinate tuples between different reference systems. The work writing interfaces matching other OGC specifications is done in the “pending” directory of the GeoAPI project. It is expected that these other interfaces will be proposed for standardization in subsequent revisions of this specification but the interfaces must first have been implemented, ideally several times, and then tested extensively by use.

Version 3.1 and 4.0 of GeoAPI covers the base of the OGC/ISO Abstract Model for geographic information. GeoAPI provides utilities, base types, metadata structures, geo-referencing and a feature model. The geo-referencing data elements enable the creation of reference systems for spatial coordinates and mathematical operators to convert coordinates from one coordinate reference system to another. This version of the standard covers the specifications ISO 19103, ISO 19115, ISO 19111 (completed by some elements from the closely related OGC™ specification OGC 01-009), ISO 19109 and four elements from ISO 19107 necessary to the implementation of ISO 19111. Future versions of this specification are expected to expand this set of interfaces to cover more models of the OGC Abstract Specification series, including notably geometry data structures, with the “pending” portion of the GeoAPI project already exploring these new areas.

2. Conformance

This standard defines interfaces in Java and Python programming languages. The normative publication of the interfaces occurs in the ASCII or binary format specific to each target language. The interfaces are distributed in ZIP bundles along with the API documentation. An online version of the API documentation, which may contain fixes for errata discovered after publication of this specification, is available at the URLs listed below:

Table 1. Distribution formats
Java Python


Java Archive (JAR) binary

Python source files (.py)


Javadoc as HTML files

Sphinx generated pages as HTML files

Online version:

The snapshot elements in above URLs will be replaced by 3.1 and 4.0 after release (TODO).

This specification makes certain requirements of libraries implementing this API and defines several conformance classes for implementations covering different packages of the API or providing different levels of complexity in their implementations. GeoAPI provides a test suite through which to establish conformance of GeoAPI implementations. Requirements for 2 standardization target types are considered:

  • Libraries which provide software components for building geospatial applications.

  • Applications which use the above-cited software components.

The second target type (applications) leaves more freedom than the first target type (libraries). In particular, applications are free to delete any types, methods or functionalities that they do not use.

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 B (normative).

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

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

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document, except for any departures from the listed specifications which are explicitly mentioned in this text. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this specification are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.

ISO / TC 211: ISO 19103:2015, Geographic information — Conceptual schema language (2015)

ISO / TC 211: ISO 19107:2003, Geographic information — Spatial schema (2003)

ISO / TC 211: ISO 19109:2015, Geographic information — Rules for application schema (2015)

ISO / TC 211: ISO 19111:2007, Geographic information — Spatial referencing by coordinates (2007)

ISO / TC 211: ISO 19115-1:2014, Geographic information — Metadata — Fundamentals (2014)

ISO / TC 211: ISO 19115-2:2009, Geographic information — Metadata — Extensions for imagery and gridded data (2009)

ISO / TC 211: ISO 19141:2008, Geographic information — Schema for moving features (2008)

OGC: OGC 01‑009, OpenGIS® Implementation Specification: Coordinate Transformation Services, revision 1.00 (2001)

OGC: OGC 14-083, OGC® Moving Features Encoding Part I: XML Core (2015)

James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Oracle: The Java Language Specification

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular:

  • SHALL (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

  • SHOULD is the verb form used to indicate desirable ability or use, without mentioning or excluding other possibilities.

  • MAY is the verb form used to indicate an action permissible within the limits of this specification.

  • CAN is the verb form used for statements of possibility.

For the purposes of this document, the following additional terms and definitions apply. Further discussion about type, class, interface, property, attribute and implementation terms can be found in the conventions section.

4.1. Application Programming Interface (API)

a formally defined set of types and methods which establish a contract between client code which uses the API and implementation code which provides the API

4.2. conceptual model

model that defines concepts of a universe of discourse
[source: ISO 19101-1]

4.3. constraint

UML condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element
[source: ISO 19103]

4.4. coordinate

one of a sequence of numbers designating the position of a point
Note 1 to entry: In a spatial coordinate reference system, the coordinate numbers are qualified by units.
[source: ISO 19111]

4.5. coordinate operation

process using a mathematical model, based on a one-to-one relationship, that changes coordinates in a source coordinate reference system to coordinates in a target coordinate reference system, or that changes coordinates at a source coordinate epoch to coordinates at a target coordinate epoch within the same coordinate reference system
[source: ISO 19111]

4.6. coordinate reference system

coordinate system that is related to an object by a datum
Note 1 to entry: Geodetic and vertical datums are referred to as reference frames.
Note 2 to entry: For geodetic and vertical reference frames, the object will be the Earth. In planetary applications, geodetic and vertical reference frames may be applied to other celestial bodies.
[source: ISO 19111]

4.7. coverage

feature that acts as a function to return values from its range for any direct position within its spatial, temporal, or spatiotemporal domain
[source: ISO 19123]

4.8. dataset

identifiable collection of data
[source: ISO 19115-1]

4.9. datatype

specification of a value domain with operations allowed on values in this domain
Examples: Integer, Real, Boolean, String and Date.
Note 1 to entry: Data types include primitive predefined types and user definable types.
[source: ISO 19103]

4.10. dynamic attribute

characteristic of a feature in which its value varies with time
[source: OGC 16-140]

4.11. feature

abstraction of a real world phenomena
Note 1 to entry: A feature can occur as a type or an instance. Feature type or feature instance should be used when only one is meant.
[source: ISO 19109]

4.12. feature attribute

characteristic of a feature
Note 1 to entry: A feature attribute can occur as a type or an instance. Feature attribute type or feature attribute instance is used when only one is meant.
[source: ISO 19109]

4.13. feature operation

operation that every instance of a feature type may perform
[source: ISO 19109]

4.14. geographic feature

representation of real world phenomenon associated with a location relative to the Earth
[source: ISO 19101-2]

4.15. geometric object

spatial object representing a geometric set
[source: ISO 19107:2003]

4.16. interface

UML classifier that represents a declaration of a set of coherent public UML features and obligations
Note 1 to entry: An interface specifies a contract; any classifier that realizes the interface must fulfil that contract. The obligations that can be associated with an interface are in the form of various kinds of constraints (such as pre- and post-conditions) or protocol specifications, which can impose ordering restrictions on interactions through the interface.
[source: UML 2]

4.17. Java

trademark of Oracle used to refer to an object oriented, single inheritance programming language whose syntax derives from the C programming language and which is defined by the Java Language Specification

4.18. metadata

data about data
[source: ISO 19115-1]

4.19. moving feature

feature whose location changes over time
Note 1 to entry: Its base representation uses a local origin and local coordinate vectors of a geometric object at a given reference time.
Note 2 to entry: The local origin and ordinate vectors establish an engineering coordinate reference system (ISO 19111), also called a local frame or a local Euclidean coordinate system.

4.20. multiplicity

UML specification of the range of allowable cardinalities that a set may assume
Note 1 to entry: Contrast with cardinality, which is the number of elements in a set.
[source: ISO 19103]

4.21. package

UML general purpose mechanism for organizing elements into groups
[source: ISO 19103]

4.22. property

facet or attribute of an object referenced by a name
[source: ISO 19143]

4.23. Python

an interpreted high-level programming language for general-purpose programming
[source: Wikipedia]

4.24. trajectory

path of a moving point described by a one parameter set of points
[source: ISO 19141]

5. Conventions

This section provides details for conventions used in the document. All examples in this document illustrated by the (i) icon are informative only.

5.1. UML notation

Unified Modeling Language (UML) static structure diagrams appearing in this document are used as described in Subclause 5.2 of OGC Web Services Common [OGC 06-121r9].

5.2. Type terminology

The meaning of type, class, interface, property and attribute can vary depending on the programming language. This document follows the UML 2 definition of interface as a declaration of a set of coherent public operations, properties and obligations specifying a contract. UML interfaces are represented in programming languages by Java interfaces and Python abstract classes. The word class is generally not used in this document except in discussions specific to a programming language, in which case the word takes the meaning defined by the target language; in Java this is often (but not only) an implementation of an interface.

The word type is used as a generic term for interface, class (whatever it is in target programming languages), code list, enumeration or the description of a feature. Note that code lists, enumerations and feature types are not interfaces.

The word property (not attribute) is used for values or associations defined by an interface. This document reserves the word attribute for feature attributes or XML attributes.

The meaning of implementation depends on the context. From the perspective of OGC/ISO abstract specifications, Java interfaces or Python abstract classes are implementations of the abstract models, in the same way than XML Schema Definitions (XSD) are other implementations of the same abstract models. But from the perspective of programming languages, interfaces are not implementations; instead the word "implementation" is used for concrete classes. In this document, the types provided by GeoAPI are said to be an implementation of abstract models, while the concrete classes provided by vendors are said to be an implementations of GeoAPI.

5.3. Abbreviated terms

The following symbols and abbreviated terms are used in this specification:

Table 2. Abbreviated terms
API Application Program Interface


Coordinate Reference System


International Organization for Standardization


Open Geospatial Consortium


Unified Modeling Language


Uniform Resource Identifiers


Well Known Text


eXtended Markup Language


XML Schema Definition


One Dimensional


Two Dimensional


Three Dimensional




Geodetic longitude


Geodetic latitude

5.4. Identifiers

The normative provisions in this specification 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.

5.4.1. Package namespaces

This specification uses opengis in the text for denoting a package or module in OGC namespace, but the exact spelling depends on the programming language. For example the metadata package is spelled org.opengis.metadata in Java but only opengis.metadata (without org prefix) in Python. Except in language-specific notes, this specification uses the shorter form in the text and lets readers adapt to their programming language of interest.

6. Geospatial API overview

The GeoAPI interfaces formalizes the handling of the types defined in the specification documents for working with geographic information adopted by the International Organization for Standardization (ISO) and the Open Geospatial Consortium (OGC). Whereas the specifications define types, operations and relationships using the general UML notation, the GeoAPI types implement those standards as programming language interfaces or simple classes. The structure of the GeoAPI library mirrors the packaging and separation of the different ISO and OGC specifications by grouping different types and functionality in separated Java and Python language packages.

Figure 1. ISO specifications and GeoAPI packages mapping

The opengis.annotation package provides the annotation system used to document the origin and obligation level of all methods and types in GeoAPI. These annotations are available through introspection at runtime for any code which wishes to exploit this information. The base of GeoAPI is formed by a formal mapping of the core types used by ISO and OGC standards to Java and Python equivalents, along with extra types in the opengis.util package for types not provided in the standard libraries. The packages in the opengis.metadata namespace cover the types defined in the ISO 19115 Metadata specification, which are data structures describing other structures. The packages in the opengis.parameter and opengis.referencing namespaces implement the types from the ISO 19111 Spatial Referencing by Coordinates specification complemented by the mathematical operator types from the OGC 01-009 Coordinate Transformation Services implementation specification. The packages in the opengis.geometry namespace cover the types defined in the ISO 19107 Spatial Schema specification, although in version 4.0 of the library only defines the elements from that specification needed by the geo-referencing types. Finally the packages in the opengis.feature namespace covers the meta-classes defined in the ISO 19109 Rules for application schema specification, completed by the dynamic attributes defined in OGC 14-083 Moving Features specification. This package is not needed for dynamic languages like Python.

6.1. General mapping rules

This section gives high-level guidance in the mapping from UML to Java and Python API applying to all GeoAPI types. Other sections after this one will focus on specific type subsets (metadata, referencing, etc). Those guidance are not strict rules; departures exist on a case-by-case basis when the semantic justify them.

6.1.1. Naming conventions

The interface and property names defined in OGC/ISO standards may be modified for compliance with the conventions in use in target programming languages. The main changes are described below:


The two-letter prefixes are dropped. For example MD_Metadata and CI_Citation interfaces are named Metadata and Citation in Java and Python. The camel cases convention (for example CoordinateSystemAxis) is kept unchanged for interfaces.

Code lists and enumerations

The two-letter prefixes are dropped in the same way than for interfaces. Then if the type name ends with the Code suffix, that suffix is dropped too in strongly-typed languages like Java. For example the ISO 19115 TopicCategoryCode code list is named TopicCategory in Java classes. This renaming is not applied to more dynamic languages like Python, because the naming convention can be a compensation for the absence of compile-time type checks.


The name changes depend on the target programming language and on the multiplicity. In Java, accessor methods start with the get prefix and are followed by their property name in camel cases. For example the ISO 19111 coordinateSystem property become a method named getCoordinateSystem() in Java. But in Python, no prefix is added and the camel cases convention is replaced by the snake cases convention. For example ISO 19111 coordinateSystem property become a property named coordinate_system in Python. In all languages, if a property allows more than one value, then the plural form of its noun may be used. The plural form hints the developers that they may need to use indexes or iterators for accessing elements.

Table 3. Example of entity name changes
ISO entity Name in Java Name in Python

CI_Citation interface



CoordinateSystemAxis interface



TopicCategoryCode code list



coordinateSystem property



6.1.2. Multiplicity conventions

The UML diagrams may specify arbitrary multiplicities (minimum and maximum number of occurrences) for each property. But GeoAPI recognizes only the following four multiplicities, materialized in the API as annotations and in the method signatures. If a different multiplicity is needed, then [0 … ∞] should be used with a restriction documented in the text attached to the property.

  • [0 … 0] — the property can not be set (this happen sometime in subtypes).

  • [0 … 1] — the property is optional or conditional.

  • [1 … 1] — the property is mandatory.

  • [0 … ∞] — the property can appear an arbitrary number of times, including zero or one.

Some programming languages have an Optional construct for differentiating the [0 … 1] and [1 … 1] cases. This construct is used where appropriate, but shall be considered only as a hint. It may appear in a mandatory property if that property was optional in the parent interface. Conversely, absence of Optional construct is not a guarantee that the value will never be null. Some properties fall in gray area, where they are usually not null but may be null in some rare situations. For example the ellipsoid property of a Geodetic Reference Frame is mandatory when used in the context of geographic or projected coordinate reference systems, which are by far the most common cases. Even when used in other contexts, the ellipsoid is optional but still recommended. Consequently GeoAPI does not use the Optional construct for the ellipsoid property in order to keep the most common usages simpler, but robust applications should be prepared to handle a null value. Developers should refer to the API documentation for the policy on null values.

6.1.3. Annotated API

The opengis.annotation package allows GeoAPI to document the UML elements from the various specification documents used for defining the Java and Python constructs. Those annotations encode the source document, stereotype, original name, and obligation level of the various types, properties and operations published by GeoAPI. The source document may be completed by a version number when the GeoAPI construct is based on a different edition of a normative document than the dated references listed in the references clause. GeoAPI defines two annotations in the Java language (no annotation in Python): @UML which is applied on types and properties (fields or methods), and @Classifier which can be applied only on types. Those annotations are shown in the figure below:

Figure 2. Annotations reflecting UML elements used by GeoAPI

Those annotations are related to the ISO 19115-1 Metadata standard in the following way: above Obligation enumeration is the MD_ObligationCode enumeration defined by ISO 19115, moved into the opengis.annotation package for making it closer to other UML-related types. A forbidden value has been added for handling the cases where a property defined in a parent interface is inapplicable to a sub-interface (those cases are declared in ISO standards with the maximum number of occurrence set to zero). Above Stereotype enumeration is a copy of the MD_DatatypeCode code list defined by ISO 19115, retaining only the values relevant to GeoAPI. This duplication exists because the ISO 19115 standard defines a code list, while Java annotations require enumerations.

Annotations in Java source code

All classes, interfaces and enumeration types in GeoAPI which are based on a published standard shall have an @UML annotation documenting the standard in which is defined the type, the original name of the element, and the version of the standard if different than the dated normative reference. As an example, the annotation label for the ProjectedCRS interface appears in the source code as below (except the classifier which is implicit):

@UML(identifier = "ProjectedCRS", specification = ISO_19111)
public interface ProjectedCRS extends GeneralDerivedCRS {

which specifies that the type was defined in ISO 19111 standard as a type also named ProjectedCRS. The @Classifier annotation is omitted when the value is Stereotype.TYPE, which is the most common case. In addition, that interface contains the method getCoordinateSystem() with the following annotation:

@UML(identifier    = "coordinateSystem",
     obligation    = MANDATORY,
     specification = ISO_19111)
CartesianCS getCoordinateSystem();

which indicates that the method was defined in the same ISO 19111 specification but had the name coordinateSystem in the standard rather than the getCoordinateSystem name used by GeoAPI, and that a non-null value must be provided by every ProjectedCRS instance.

An example in annex shows how these annotations are available at runtime by introspection.

6.1.4. Derived methods

GeoAPI may define additional methods not explicitly specified in OGC/ISO abstract models, when the values returned by those methods can be derived from the values provided by standard OGC/ISO properties. Those extensions are enabled by a GeoAPI restriction in the way properties are handled. In OGC/ISO abstract models each property could have its value stored verbatim, for example as a column in a database table, an XML element in a file or a field in a class. For enabling efficient use of OGS/ISO models in relational databases or XML files, those models are generally non-redundant: each value is stored in exactly one property. By contrast in GeoAPI all properties are getter methods; no matter how implementations store property values, users can fetch them only through method calls. Since methods are free to compute values from other properties, GeoAPI uses this capability for making some information more easily accessible in situations where property values can be reached only indirectly in OGC/ISO models. Those additional methods introduce apparent duplications, but they should be thought as links to the real properties rather than copies of the property values. Those methods are added sparsely, in places where introducing them brings some harmonization by reducing the needs to perform special cases. Examples include fetching the head of an arbitrary GenericName, fetching the Geodetic Reference Frame indirectly associated to a ProjectedCRS, fetching axes of an arbitrary Coordinate Reference System (including compound ones), and more. Those additional methods can be recognized by the absence of @UML annotation.

6.2. Core data types mapping

The ISO 19103 specification (Geographic Information – Conceptual schema language) defines types which are used as building blocks by the other standards in the 19100 series. ISO 19103:2015 defines Primitive types (§7.2 of that standard), Collection types (§7.3), Enumerated types (§7.4), Name types (§7.5), Record types (§7.7) and Unit of Measure types (§C.4). GeoAPI maps these types either to existing types from the Java and Python standard libraries or, when needed, to types defined in the opengis.util package. That utility package is used by GeoAPI for types defined in the ISO 19103 specification for which no equivalence is already present in the Java and Python standard libraries.

For various practical reasons the mapping from ISO types to programming language types is not a one-to-one relationship. The mapping actually used is explained below. Furthermore not all of the types in ISO 19103 have a mapping defined because the need for these types has not yet appeared, since they have not yet appeared in any other specification for which GeoAPI defines interfaces. Such types are listed as "unimplemented" in the tables below.

6.2.1. Primitive types

From ISO 19103:2015 §7.2.1

Each primitive type of the OGC/ISO specifications maps to zero, one or two object structures in GeoAPI. Where the mapping can be made directly to a programming language primitive type, such as int and double, the language primitive is preferred. However, when the value must be able to be set to null, the object wrapper of that primitive may be used in languages where "primitives" and "wrappers" are distinct. The following table shows the mapping used by GeoAPI to represent the primitive types in the ISO 19100 series.

Table 4. Primitive types mapping
ISO 19103 interface Java type Python type


java.lang.Boolean (1)




int or float


java.lang.Integer (1)(2)



java.lang.Double (1)


Decimal (3)







java.lang.String (4)







(1) The primitive type, such as int and double, is used instead of the wrapper where the value can not be null.
(2) Sometime substituted by java.lang.Long or long where the value may exceed 232.
(3) Decimal differs from Real, as Decimal is exact in base 10 while Real may not.
(4) Substituted by org.opengis.util.InternationalString where the string representation depends on the locale.

6.2.2. Date and time

From ISO 19103:2015 §7.2.2 to 7.2.4

The ISO 19103 Date interface gives values for year, month and day while the Time interface gives values for hour, minute and second. DateTime is the combination of a date with a time, with or without timezone. GeoAPI maps the ISO date and time interfaces to the types provided in the standard library of target languages. In some cases like Java, this mapping forces GeoAPI to choose whether the time component shall include timezone information or not since the choices are represented by different types (e.g. LocalDateTime, OffsetDateTime and ZonedDateTime). The timezone information is often desired for geospatial data (for example in the acquisition time of a remote sensing image), but may be undesired for some other cases like office opening hours. In the later case, the decision to include timezone or not depends if the opening hours apply to one specific office or to all offices spanning the multiple timezones of a country. GeoAPI generally includes timezone information, but this policy may be adjusted on a case-by-case basis.

Table 5. Date and time types mapping
ISO 19103 interface Java class Python type


java.time.LocalDate (1)




java.time.ZonedDateTime (1)



java.time.Instant (1)

(1) Some properties defined in GeoAPI 3.x use the legacy java.util.Date class for historical reasons.

Note: DateTime is distinct from Instant. The former is expressed in the proleptic Gregorian calendar as described in ISO 8601, while the later is an instantaneous point on the selected time scale, astronomical or atomic. An Instant does not have year, month or day components (it is instead a duration elapsed since an epoch), and its conversion to a DateTime may be complicated. In GeoAPI, temporal objects in metadata are typically DateTime while coordinates in a temporal coordinate reference system are typically Instant.

6.2.3. Collections

From ISO 19103:2015 §7.3

GeoAPI implements ISO 19103 collection interfaces using the standard Collections Frameworks provided by Java and Python. A Set is a finite collection of objects where each object appears only once. A Bag is similar to a Set except that it may contain duplicated instances. The order of elements in a Set or a Bag is not specified. A Sequence is similar to a Bag except that elements are ordered.

Table 6. Collections mapping
ISO 19103 interface Java type Python type













Unless otherwise required by the semantic of a property, GeoAPI preferably uses the Collection type in Java method signatures. This allows implementors to choose their preferred subtypes, usually Set or Sequence. The Set type is not the default type because enforcing element uniqueness may constraint implementations to use hash tables or similar algorithms, which is not always practical.

6.2.4. Controlled vocabulary

From ISO 19103:2015 §6.5

GeoAPI distinguishes between two enumerated types depending on whether the complete set of literal types is known when the code is originally created, or if the list may be extended at run time. Many language provides an enum construct for the former case and GeoAPI defines the CodeList abstract class in Java for the later case.

Table 7. Enumerated types mapping
ISO 19103 type Java type Python type












In some specifications (for example ISO 19115), code list and enumeration names end with the Code suffix. Some other specifications (for example ISO 19111) do not use any particular suffix. The mapping to programmatic API may uniformize those type names to a single convention, depending on the target language. For the Java API, Code suffixes are omitted in class names. For the Python API, class names are left unchanged.

Code lists in Java

The use of org.opengis.util.CodeList constructs includes accessing statically defined elements, defining new elements and retrieving any element defined for the code list. Considering, for example, org.​opengis.​referencing.​cs.​AxisDirection, the following code could be used:

AxisDirection north    = AxisDirection.NORTH;
AxisDirection northBis = AxisDirection.valueOf("NORTH");

where the second locution will create a new value if it does not exist. Special care should be taken to keep such calls consistent throughout the code since the CodeList will create a new element if there are any difference in the String parameters.

6.2.5. Name types

From ISO 19103:2015 §7.5

A name is a sequence of identifiers rooted within the context of a namespace. NameSpace defines a domain in which "names" given by character strings can be mapped to objects. For example a class forms a namespace for the properties that the class contains.

Table 8. Name types mapping
ISO 19103 interface Java interface Python class















GenericName is the base interface for all names in a NameSpace. A generic name can be either a LocalName, or a ScopedName which is a composite of a LocalName (the head) for locating another NameSpace and a GenericName (the tail) valid in that name space. For example if "urn:​ogc:​def:​crs:​EPSG:​9.5:​4326" is a ScopedName, then "urn" is the head and "ogc:​def:​crs:​EPSG:​9.5:​4326" is the tail. GeoAPI extends the model by allowing navigation in the opposite direction, with "urn:​ogc:​def:​crs:​EPSG:​9.5" as the path and "4326" as the tip.

TypeName and MemberName are subtypes of LocalName for referencing a type (for example a class) and a member (for example a property in a class) respectively. The NameFactory is an extension of the GeoAPI project designed to allow the construction of instances of these name types.

Figure 3. Generic names derived from ISO 19103

GeoAPI extends the ISO 19103 model by adding a (path, tip) pair in complement to the (head, tail) pair. While the head and tip properties carry non-trivial information only inside ScopedName, GeoAPI nevertheless makes them available from the GenericName interface (not shown in above diagram) with the restriction that they shall return this (Java) or self (Python) when the name is an instance of LocalName. This generalization makes common operations simpler without the need to check for the exact name interface.

The ISO 19103 aName property appears as toString in above UML diagram, but this property should be mapped to the standard mechanism for representing an arbitrary object as a character string in the target programming language. In Java this is the toString() method; in Python this is __str__ or __repr__. This specification uses the Java method name as it is more readable, but other languages should adapt.

The ISO 19103 NameSpace interface defines also mapping functions from a name to the object identified by that name. But this functionality does not appear in the GeoAPI NameSpace interface; instead we left these mappings to other frameworks (for example Java Naming and Directory Interface).

Mapping to Java Naming and Directory Interface™ (JNDI)

The mapping functions defined by ISO 19103 are not part of the NameSpace interface defined by GeoAPI. Java applications which need such mapping may use the methods in the javax.naming.Context interface instead:

Table 9. Java Naming and Directory Interface equivalences
ISO 19103 NameSpace member org.opengis.util.NameSpace javax.naming.Context










registerID(LocalName, Any)

bind​(Name, Object)



unregisterID(LocalName, Any)


6.2.6. Record types

From ISO 19103:2015 §7.7

Records define new data type as an heterogeneous aggregation of component data types. Each data component is identified by a MemberName and has exactly one value per record.

Table 10. Record types mapping
ISO 19103 interface Java class or interface Python class















Record and RecordType have some similarities with Feature and FeatureType respectively but without multi-occurrence, associations, operations and type inheritance. If we push the comparison with features further, record Field and FieldType are similar to feature Attribute and AttributeType respectively.

TODO: add UML diagram (show how Field is replaced by Map<type,value>). Resolve

6.3. Internationalization

From ISO 19103:2015 §C.2

The InternationalString interface is defined by GeoAPI to handle textual sequences which may potentially need to be translated for users of different locales. Conceptually this act as a CharacterString but may, depending on the implementation, provide access to locale specific representations of that string. GeoAPI InternationalString is closely related, but not identical, to ISO 19103 LanguageString. The main difference is that the later is a character string in one specific language, while InternationalString can be a collection of character strings in different locales. This is useful, for example, when an implementation is operating on a server that serves multiple languages simultaneously, to allow sending string representations in the locale of the client rather than the locale of the server running the GeoAPI implementation.

Note: InternationalString is inspired by JSR-150 (Internationalization Service for J2EE) with support for different timezones omitted.

Table 11. Linguistic types mapping
ISO 19103 interface Java class or interface Python class








Internationalization in Java

The org.opengis.util.InternationalString interface provides a container for multiple versions of the same text, each for a specific java.util.Locale — the identifier used in Java for a specific language, possibly in a named territory.

NameFactory factory =  ...                      // Implementation dependent.
InternationalString multiLingual = factory.createInternationalString(Map.of(
        Locale.ENGLISH, "My documents",
        Locale.FRENCH,  "Mes documents"));

System.out.println(localized);         // Language at implementation choice.

The method to obtain factories is not specified by this standard and therefore depends on the design of the library implementation. Also, the locale used by default depends on the choice of the implementation so the result of the call toString() without parameters will depend on the implementation.

6.4. Units of measurement

From ISO 19103:2015 §C.4

Measurements and their units are represented by two base interfaces defined in ISO 19103: Measure for the result from performing the act of ascertaining the value of a characteristic of some entity, and UnitOfMeasure as a quantity adopted as a standard of measurement for other quantities of the same kind. Those two base interfaces have a parallel set of subtypes: Length (a Measure specialization for distances) is accompanied by UomLength (a UnitOfMeasure specialization for length units), Area is accompanied with UomArea, etc.

Some languages have a standard library for units of measurement. For example Java has standardized a set of quantity interfaces in the JSR-363 standard. When such language-specific standard exists and provides equivalent functionality to ISO 19103, that external standard is used. Otherwise new types are defined following ISO 19103 definitions of units of measurement.

Table 12. Units of measurement mapping
ISO 19103 interface Java interface Python class









































Parameterized units in Java

The ISO 19103 Measure type is represented by the Quantity interface in the Java API defined by JSR-363. The Java standard defines various quantity subtypes in the same way than ISO 19103 does, often with the same names (Angle, Length, Area, Volume and Time). But contrarily to ISO 19103, JSR-363 does not define a parallel set of subtypes for units of measurement. Instead, it defines only one unit type, javax.measure.Unit<? extends Quantity>, which is parametrized by the quantity type. For example instead of defining a UomLength subtype, developers use Unit<Length> to qualify the type of Unit or Measure being used. Units of the same parametrized type can be used in unit conversions like below (the Units class must be provided by a JSR-363 implementation):

Unit<Length> sourceUnit = Units.MILE;
Unit<Length> targetUnit = Units.KILOMETRE;
UnitConverter converter = source.getConverterTo(target);
double source = 123.2;
double target = converter.convert(source);

where the initial calls define units of length and then a converter is used to obtain the equivalent length in a new unit.

6.5. Departure from ISO 19103

GeoAPI differs from ISO 19103 in the following ways:

  • Replace some ISO 19103 types by equivalent standard types of the target platform when they exist.

  • Introduction of a ControlledVocabulary type as a common parent for code lists and enumerations.

  • Use of InternationalString for holding a separate String for every locale to handle.

  • Introduction of a NameFactory for providing constructors to instantiate GenericName objects.

6.6. Metadata packages

The GeoAPI metadata packages use the org.opengis.metadata namespace and implement the types defined in the specification from the International Organization for Standardization ISO 19115-1:2014 – Metadata part 1: fundamentals along with the modifications of Technical Corrigendum 1 from 2016 (TODO: verify). They are completed or merged with the types defined in ISO 19115-2:2009 – Extensions for imagery and gridded data (TODO: verify).

The metadata packages of GeoAPI provide container types for descriptive elements which may be related to data sets or components. All of these data structures are essentially containers for strings, dates or numbers, and the interfaces consist almost exclusively of methods which provide access to those types or a container. The API defines no methods which manipulate or modify the data structures.

Write access to metadata in Java

The metadata packages of GeoAPI have been built primarily in support of the geodetic types defined in the referencing packages and therefore consider primarily read access to the data structure contents. The GeoAPI metadata interfaces provide no methods to set the values of the types. Furthermore, because the way that wildcards for Java Generics have been used in the interfaces, the collection instances are constrained to be read only. Implementors are free to provide a fully mutable implementation of GeoAPI interfaces, but users may need to cast to the implementation classes in order to modify a metadata.

The GeoAPI rules of method return values have been relaxed for the metadata packages. Elsewhere in GeoAPI, methods which have a mandatory obligation in the specification must return an instance of the return type and cannot return the Java null or Python None reference. However, in the metadata package this rule is relaxed because data sets are encountered so frequently which have not correctly followed the requirements of the specification. In the GeoAPI metadata packages, methods for mandatory properties should return a valid instance, but users should be prepared to receive null (Java), None (Python) or an empty collection. This modification has been adopted to allow implementations sufficient latitude to handle metadata records which do not correctly conform to the specification. Nonetheless, sophisticated implementations can determine if a metadata record conforms with the specification by inspecting the annotations at runtime.

6.6.1. Package mapping

From ISO 19115-1:2014 §6.5.[2…14]; ISO 19115-1 §6.6; ISO 19157

The mapping of ISO packages to GeoAPI packages follows a parallel naming scheme, shown in the table below. Some minor packages (for example Portrayal catalogue which contains only one interface) have been aggregated into another package. All packages are defined by ISO 19115 except Data quality which is defined by ISO 19157 but considered by GeoAPI as metadata for historical reasons, and Reference system which has been replaced by the ISO 19111 interfaces from the referencing package.

Table 13. Metadata package mapping
ISO package Java package Python module
















Spatial representation



Reference system





Portrayal catalogue






Metadata extension



Application schema



Service metadata



Extent, Citation and Common



Data quality



6.6.2. Reference systems

Coordinate Reference Systems (CRS) are defined in details by the ISO 19111 interfaces in GeoAPI referencing packages. A Reference System may also use geographic identifiers (ISO 19112) instead of coordinates. The common parent interface of Coordinate Reference System and Reference System by Geographic Identifier is ReferenceSystem. GeoAPI inserts this interface between IdentifiedObject and CoordinateReferenceSystem in ISO 19111 interface hierarchy (this is a departure from ISO standards). Usages are shown below:

Table 14. Associations from a metadata object to a reference system
Metadata interface Property name Property type













TODO: replace above table by UML diagram showing IdentifiedObject and ReferenceSystem.

The reference system identifier can be obtained by ReferenceSystem.identifier. The reference system type (geographic, projected, compound, etc.) can be determined using language-specific instructions, for example instanceof in Java. If a metadata instance does not have the full reference system definition but only its identifier, then the implementation can use a custom ReferenceSystem instance.

6.6.3. How to use

The interfaces in the GeoAPI metadata packages are primarily containers of primitive types and other metadata types. Metadata elements will be encountered in the data types from the referencing packages and the interfaces enable users to obtain the elements of the data type. As an example, we want to print a list of all the individuals (ignoring organizations) for a document starting with a Citation element:

Citation citation = ...;    // We assume this instance is already available

for (Responsibility rp : citation.getCitedResponsibleParties()) {
    if (rp.getRole() == Role.AUTHOR) {
        for (Party party : rp.getParties()) {
            if (party instanceof Individual) {
                InternationalString author = rp.getName();

The remainder of the metadata packages work in similar ways, where client code must disaggregate an instance to obtain the elements needed.

6.6.4. Departures from ISO 19115

A departure in the GeoAPI metadata packages from the published ISO 19115 standard is in the way GeoAPI metadata package added the types and properties defined in the specification ISO 19115-2 – Extensions for imagery and gridded data. The latter was forced to create a number of interfaces to hold elements which naturally could occur directly in the interfaces defined by ISO 19115. We integrated such interfaces directly into the existing interfaces rather than adding complexity to the API which exists by historical accident. For example ISO 19115-2 defines a MI_Band interface which extends the MD_Band interface defined by ISO 19115-1, with the addition of a transferFunctionType property (among others) for completing the scaleFactor and offset properties defined by ISO 19115-1. GeoAPI merges those two interfaces together, with annotations on each property for declaring the originating standard. The metadata interfaces merged in such way are:

Table 15. Metadata ISO 19115-2 interfaces merged with ISO 19115-1 parent interfaces
ISO 19115-1 parent interface ISO 19115-2 subclass merged with parent

















Another departure come from GeoAPI replacing the MD_ReferenceSystem interface by RS_ReferenceSystem. Coordinate Reference Systems (CRS) are defined in details by the ISO 19111 interfaces in GeoAPI referencing packages. But the ISO 19115 metadata standards do not reference those CRS interfaces directly (except in one case). Instead the metadata standards reference CRS by their identifier (for example an EPSG code), optionally accompanied by a code telling whether the CRS type is geographic, projected, temporal, a compound of the above, etc. The ISO 19115 standard combines those two information in a MD_ReferenceSystem interface. The following table lists the associations to referencing systems as defined by the metadata standards:

Table 16. Associations to a Reference Systems defined by ISO 19115
ISO 19115 interface Association to MD_ReferenceSystem Association to ISO 19111










In order to have a more uniform way to handle reference systems, GeoAPI replaces (identifier, type code) tuples by associations to the actual Reference System objects. GeoAPI does that by omitting the MD_ReferenceSystem and MD_ReferenceSystemTypeCode interfaces, replacing them by associations to RS_ReferenceSystem instead as shown in the reference system section. The RS_ReferenceSystem interface is a common parent for Referencing by Coordinate (ISO 19111) and Referencing by Geographic Identifier (ISO 19112). The functionalities can by mapped as below:

Table 17. Mapping from ISO properties to GeoAPI replacements
ISO 19115 interface and property GeoAPI replacement




Type of the RS_ReferenceSystem instance

As a side-effect of this replacement, verticalCRSId becomes redundant with verticalCRS. Consequently the former is omitted from GeoAPI interfaces.

7. Requirements

This section describes requirements for ensuring source compatibility or binary compatibility (when applicable) of libraries compliant with this specification. Those requirements apply to the libraries made available for use by other developers. The requirements usually do not apply to final products distributed to end users. For example compliant libraries shall obey to method signatures declared in published OGC interfaces, otherwise other developers could not base their developments on a common set of API. However the final product is free to modify, add or remove methods as it sees fit; if the GeoAPI of the final product is not invoked by any external application, then changes to that API has no impact on inter-operability.

7.1. Requirement class A

Requirements Class

Target type





Requirement 1
requirement description

Requirement 2
requirement description

Requirement 3
requirement description


7.1.1. Requirement 1

Requirement 1


Redistributed modules in OGC namespace shall contain the exact same set of types, methods and properties as listed in the API documentation published by OGC at the following locations:

Python: TODO

Note that this requirement does not mean that vendors must implement all types and methods, or can not implement their own API in addition of GeoAPI. This requirement only means that modules or packages inside the org.opengis or opengis namespaces shall contain the exact same set of types as published at above links, and each of those types shall contain the exact same set of properties as published. But vendors are still free to implement only a subset of their choice and throw exception for unimplemented types and methods. Vendors can also add new types and methods, provided that those additions are in a namespace different than org.opengis and opengis. Finally, this requirement apply only to libraries redistributed for use by other developers. Final applications are free to remove any unused types or methods if such removal is invisible to other developers.

Annex A: Conformance Class Test Suite (Normative)

A.1. Conformance Class A

A.1.1. Requirement 1

Test id:




Test purpose:

Verify that all types and properties in OGC namespace are as published.

Test method:


Annex B: Conformance Level (Normative)

Annex C: Java Profile (Normative)

Annex D: Python Profile (Normative)

Annex E: Examples

E.1. UML at runtime

The annotations in API are available at runtime by introspection. This is useful, for example, when code needs to marshall data using the name defined by the ISO standard rather than the GeoAPI name.

E.1.1. Java example

At runtime, the annotation of a reference to a GeoAPI interface can be obtained as follows, taking as an example the method getTitle() in the Citation interface:

Class<?>      type          = Citation.class;
Method        method        = type.getMethod("getTitle");
UML           annotation    = method.getAnnotation(UML.class);
String        identifier    = annotation.identifier();          // = "title"
Specification specification = annotation.specification();       // = ISO 19115-1
Obligation    obligation    = annotation.obligation();          // = mandatory

Java provides a class instance like the Citation.class instance used here for every type, either interface or class, defined in the runtime. The getMethod(…) call uses introspection to obtain a reference to the method from which the annotation can then be obtained. The annotation system therefore provides access, at runtime, to the original definition of the element.

Annex F: Revision History

Date Release Editor Clauses modified Description



Adrian Custer


Initial public draft



Martin Desruisseaux

Annex E

List of departures



Martin Desruisseaux

8.1.1, 10.1, annex F


TODO: update references in above table:

  • 8.1.1: Primitive types

  • 10.1: Geometry packages - Defined types

  • annex E: list of departures

  • annex F: Comparison with legacy OGC specifications

Annex G: Bibliography

[1] OGC: 16-019r4, OGC® Open Geospatial APIs - White Paper (2016)

[2] The Junit framework,

[3] The Unified Code for Units of Measure,