I. Abstract
The OGC Points of Interest (POI) Conceptual Model is an open data model for representing information about POI. The model is defined using a Unified Modeling Language (UML) object model. This UML model extends the ISO Technical Committee 211 (TC211) conceptual model standards for spatial and temporal data. Building on the ISO foundation assures that the features described in the POI Model share the same spatiotemporal universe as described by related standards (e.g., CityGML).
The goal for developing the OGC POI Conceptual Model is to reach a common definition of the basic entities, attributes, and relations of “points of interest.” In the broadest terms, a POI is a location about which information of general interest is available. “A POI can be as simple as a set of coordinates and an identifier, or more complex such as a three-dimensional model of a building with names in various languages, information about open and closed hours, and a civic address.” W3C
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, Point of Interest, POI, Feature
III. Preface
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
The POI Conceptual Model defines a POI as a type of Feature. By building on the same Feature Model as other OGC Feature models, POI implementations inherit the security controls and vulnerabilities of their associated Feature Dataset. They are a Feature like any other.
This document defines a Conceptual Model Standard. Implementations of this Standard (Implementation Standards) are free to add additional details and content necessary to enable implementation-specific security controls. In the event that anything in this Standard prevents implementation of needed controls, implementors are requested to notify the POI Standards Working Group (SWG) and help devise a solution.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Digital Flanders
- HeazelTech
- Pangaea Innovations
- PEREY Research and Consulting
- US Army Geospatial Center
1. Scope
The OGC Points of Interest Conceptual Model Standard (this document) describes a conceptual model for representing information about points of interest (POI).
POI data has many uses including navigation systems, mapping, geocaching, location-based social networking games, and augmented reality browsers.
POI data has traditionally been exchanged in proprietary formats by various transport mechanisms. This document defines a flexible, lightweight, extensible POI data model. This will enable content publishers to effectively describe and efficiently serve and exchange POI data.
To achieve these goals, this document describes a generic data model that may be instantiated in a variety of serializations, including XML, JSON, and RDF. The data model is designed to be extended with POI information specific to the geospatial data it represents.
2. Conformance
This Standard defines a Conceptual Model which is independent of any encoding or formatting techniques. The Standardization Target for this Standard is technology-specific POI Implementation Standards.
2.1. OGC Implementation Standards
Implementation Standards define how a Conceptual Model should be implemented using a specific technology. Conformant Implementation Standards provide evidence that they are an accurate representation of the Conceptual Model. This evidence should include implementations of the abstract tests specified in Annex A (normative) of this document.
Since this Standard is implementing technology agnostic, the specific techniques to be used for conformance testing cannot be specified. Implementation Standards need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as Annex A to the Implementation Standard document.
2.2. Implementations
POI implementations will typically be a simplified representation of a more complex dataset. Implementors may want to extend the POI model to include properties specific to that dataset. These extensions are accomplished using the POI Payload mechanism described in POI Payload. Since the POI Payload has its own definition of syntax and semantics, conformance with the POI Conceptual Model Standard cannot ensure payload conformance.
2.3. Conformance Classes
This Standard identifies one “Core” conformance class. This conformance class defines the conformance criteria for the requirements defined in one “Core” requirements class. The tests this conformance class are documented in Annex A. These tests are organized by Requirements Class. So an implementation of the Core conformance class must pass all tests specified in Annex A for the Core Requirements Class.
The POI Conceptual Model is defined by the POI UML model. This Standard is a representation of that UML model in document form. In the case of a discrepancy between the UML model and this document, the UML model takes precedence.
2.4. Primitive Data Types
The Primitive Data Types (CharacterString, Integer, DateTime, etc.) are defined in ISO 19103. These Data Types are universal concepts. Therefore, no explicit conformance testing for these concepts is needed. Testing for conformance with the technology-specific implementation of these concepts should be documented in the corresponding Implementation Standard.
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.
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 19103, Geographic information — Conceptual schema language. International Organization for Standardization, Geneva https://www.iso.org/standard/83454.html.
ISO: ISO 19107:2003, Geographic information — Spatial schema. International Organization for Standardization, Geneva (2003). https://www.iso.org/standard/26012.html.
ISO: ISO 19109:2015, Geographic information — Rules for application schema. International Organization for Standardization, Geneva (2015). https://www.iso.org/standard/59193.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 19507:2012, ISO (2012).
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.
Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009). https://portal.ogc.org/files/?artifact_id=34762&version=2.
Open Geospatial Consortium. OGC Definitions Register. https://www.opengis.net/def/glossary
Object Management Group (OMG), Unified Modeling Language (UML), Version 2.5.1, December 2017, https://www.omg.org/spec/UML/2.5.1
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.
a set of conceptual schema for data required by one or more applications.
Note 1 to entry: The purpose of an application schema is twofold: “to provide a computer-readable data description defining the data structure, which makes it possible to apply automated mechanisms for data management; and to achieve a common and correct understanding of the data, by documenting the data content of the particular application field, thereby making it possible to unambiguously retrieve information from the data.”
[SOURCE: ISO 19109]
description of a set of objects that share the same attributes, operations, methods, relationships, and semantics
Note 1 to entry: A class may use a set of interfaces to specify collections of operations it provides to its environment. The term was first used in this way in the general theory of object-oriented programming, and later adopted for use in this same sense in UML.
[SOURCE: ISO 19103 clause 4.27, modified — Note 1 to entry has been added from ISO 19117:2012, 4.2]
unit of knowledge created by a unique combination of characteristics
Note 1 to entry: Concepts (Clause 4.3) are not necessarily bound to particular languages. They are, however, influenced by the social or cultural background which often leads to different categorizations.
[SOURCE: ISO 1087-1 clause 3.2.1]
model that defines concepts (Clause 4.3) of a universe of discourse
[SOURCE: ISO 19101-1 clause 4.1.5]
a class of conformance tests. A conformant implementation must pass all the tests in the class.
[SOURCE: OGC Definitions Register]
abstraction of real-world phenomena
Note 1 to entry: A feature (Clause 4.6) may occur as a type or an instance. In this document, feature (Clause 4.6) instance is meant unless otherwise specified.
[SOURCE: ISO 19101 clause 4.1.11, modified — Note 1 to entry has been added from ISO 19156, 4.6]
class (Clause 4.2) of features (Clause 4.6) having common characteristics
[SOURCE: ISO 19156 clause 4.7]
guidance for software engineers that is so specific that any two independent software implementations of the Standard can “plug and play” for each other.
[SOURCE: OGC Definitions Register]
a class of requirements, comprising a logical grouping of normative statements that shall be satisfied as a group in conformant implementations. May have dependencies on other requirements classes (Clause 4.9), but there should be no circular dependencies else the classes must always be satisfied together so are functionally one class.
[SOURCE: OGC Definitions Register]
entity to which some requirements of a standard apply
NOTE
The standardization target is the entity which may receive a certificate of conformance for a requirements class.
[SOURCE: OGC 08-131r3]
5. Conventions
5.1. Identifiers
The normative provisions in this document are denoted by the URI:
http://www.opengis.net/spec/poi/1.0
All requirements and conformance tests that appear in this document are denoted by partial URIs relative to this base.
5.2. UML Notation
The POI Conceptual Model (CM) Standard is documented as a Unified Modeling Language (UML) model. The model is presented in this document through diagrams using the UML static structure diagram. The UML notations used in this standard are described in the diagram in Figure 1.
Figure 1 — UML notation (see ISO TS 19103, Geographic information - Conceptual schema language).
All associations between model elements in the POI Conceptual Model are unidirectional. Thus, associations in the model are navigable in only one direction. The direction of navigation is depicted by an arrowhead. In general, the context an element takes within the association is indicated by its role. The role is displayed near the target of the association. If the graphical representation is ambiguous though, the position of the role must be drawn to the element the association points to.
Aggregations are a form of association where the Component Class is treated as an attribute of the Aggregate Class. However, the Component Class is not an integral part of the Aggregate Class. A Component Class can be aggregated by more than one Aggregate Class.
Compositions are a form of association where the Component Class is treated as an attribute of the Composite Class. Component Classes are an integral part of the Composite Class and cannot be shared by multiple Composite Classes. No Compositions are used in this Standard.
The following stereotypes are used in this model.
«Abstract» a class that doesn’t include a complete implementation. Therefore, abstract classes can’t be directly instantiated; they have to be specialized (inherited).
«DataType» defines a set of properties that lack identity. A data type is a classifier with no operations, whose primary purpose is to hold information.
«FeatureType» represents features that are similar and exhibit common characteristics. Features are abstractions of real-world phenomena and have an identity.
«Metaclass» (Optional) a profile class and packageable element which may be extended through one or more stereotypes, which defines how an existing metaclass may be extended as part of a profile.
«Property» denotes attributes and association roles. This stereotype does not add further semantics to the conceptual model but is required to be able to add tagged values to the attributes and association roles that are relevant for the encoding.
«Type» denotes classes that are not directly instantiable, but are used as an abstract collection of operation, attribute, and relation signatures. The stereotype is used in the POI Conceptual Model only for classes that are imported from the ISO standards 19103, 19107, 19109, and 19115.
To enhance the readability of the POI UML diagrams, classes are depicted in different colors. The following coloring scheme is applied:
Classes painted in green belong to the POI Requirements Class.
Classes painted in tan are defined in the ISO standards 19107, 19109, or 19115. Class names are preceded by the UML package name in which the class is defined.
The color white is used for notes and Object Constraint Language (OCL) constraints that are provided in the UML diagrams.
The example UML diagram in Figure 2 demonstrates the UML notation and coloring scheme used throughout this standard. The generalization, link, and instance associations are also illustrated.
Figure 2 — Example UML diagram demonstrating the UML notation and coloring scheme used throughout the POI Standard.
5.3. International Text
Not all users will speak the same language. Therefore a POI Standard should support international text. While internationalization techniques are specific to the implementing technology, this Conceptual Standard should provide some guidance on the desired characteristics of such an implementation.
To that end, this Standard recommends the following conventions for implementing internationalized text in an Implementation Standard:
All text strings should have cardinality greater than one;
Text strings can have an associated language attribute; and
These language attributes should be populated with an international language code.
6. POI Model Core Requirements
6.1. ISO Foundation
The POI Standard builds on a base of ISO Standards maintained by ISO Technical Committee 211 (TC211). The relevant portions of those Standards are described below. In addition, ISO Technical Committee 211 provides a harmonized UML model which encompasses all of the ISO Standards used by this POI Conceptual Model. That UML model is available from the ISO TC211 HMMG.
6.1.1. ISO Feature Model
A Point of Interest (POI) is a Feature. Therefore, it is important to understand what a POI inherits from the ISO Feature model.
The ISO TC211 Feature Model is defined in ISO 19109:2015. A UML model showing applicable portions of the ISO Feature Model is provided in Figure 3.
Figure 3 — Feature Model
The most relevant classes defined by this model are described below.
FeatureType: This class describes how a feature class shall be constructed in an Application Schema. In accordance with the conformance clause of the standard, instances of this class are instantiated as feature classes in an Application Schema.
AnyFeature: The class AnyFeature is an instance of the «metaclass» FeatureType. It represents the set of all classes which are feature types.
In an implementation, this abstract class shall be substituted by a concrete class representing a feature type from an application schema associated with a domain of discourse.
| Identifier | /req/core/generalfeaturemodel |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An encoding of the POI Conceptual Model SHALL be compliant with the General Feature Model defined in ISO 19109. |
6.1.2. ISO Geometry Model
The ISO TC211 Geometry Model is defined in ISO 19107:2003. While there is a new version of this standard, it has not been widely implemented. Therefore, the 2003 version has been used in this Standard.
The ISO Geometry Model can represent very complex geometry. Much more complex than needed for expressing a POI. Therefore, POI geometry types are restricted to Points, Lines, and Polygons. Figure 4 provides a UML model of the classes from ISO 19107 which are applicable to POIs.
Figure 4 — Geometry Model
The key classes described in this figure are:
GM_Object: Root class for all OGC geometry types.
GM_Point: The geometric primitive for Points
GM_LineString: The geometric primitive for line strings.
GM_Polygon: The geometric primitive for areas.
| Identifier | /req/core/geometry |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | The POI Conceptual Model spatial geometry properties SHALL be compliant with the Geometry Model defined in ISO 19107 with the following restrictions: |
| B | A POI instance SHALL include a spatial geometry property using the SpatialAttributeType attribute type. |
| C | The spatial geometry properties of all POI instances SHALL be defined using one or more of the following classes:
|
6.2. POI ISO Extensions
This Standard extends the OGC Feature Model to support the concept of a Point of Interest. These extensions are illustrated in Figure 5.
Figure 5 — POI UML Model - ISO Extensions
These extensions include further refinement of the AnyFeature class through the addition of identification and temporal validity attributes.
AbstractFeature: The root Feature class for this Standard. This class has been borrowed from the CityGML 3.0 Conceptual Model. AbstractFeature adds descriptive and identifying properties to AnyFeature. AbstractFeatureWithLifespan: Adds temporality to AbstractFeature. This class was also borrowed from the CityGML 3.0 Conceptual Model.
6.2.1. Abstract Feature
| Identifier | /req/core/abstractfeature |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeature class SHALL be an accurate representation of the UML model for that class. |
| B | An encoding of the AbstractFeature class SHALL be a compliant extension of the AnyFeature class defined in ISO 19109. |
| C | An encoding of the AbstractFeature class SHALL comply with requirement /req/core/abstractfeature-description. |
| D | An encoding of the AbstractFeature class SHALL comply with requirement /req/core/abstractfeature-featureid. |
| E | An encoding of the AbstractFeature class SHALL comply with requirement /req/core/abstractfeature-identifier. |
| F | An encoding of the AbstractFeature class SHALL comply with requirement /req/core/abstractfeature-name. |
| Identifier | /req/core/abstractfeature-description |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeature class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeature class SHALL include zero or one description attributes. |
| Identifier | /req/core/abstractfeature-featureid |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeature class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeature class SHALL include one featureID attributes. |
| Identifier | /req/core/abstractfeature-identifier |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeature class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeature class SHALL include zero or one identifier attributes. |
| Identifier | /req/core/abstractfeature-name |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeature class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeature class SHALL include zero or more name attributes. |
6.2.2. Abstract Feature with Lifespan
| Identifier | /req/core/featurewithlifespan |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeatureWithLifespan class SHALL be an accurate representation of the UML model for that class. |
| B | An encoding of the AbstractFeatureWithLifespan class SHALL comply with requirement /req/core/abstractfeature. |
| C | An encoding of the AbstractFeatureWithLifespan class SHALL comply with requirement /req/core/featurewithlifespan-creationdate. |
| D | An encoding of the AbstractFeatureWithLifespan class SHALL comply with requirement /req/core/featurewithlifespan-terminationdate. |
| E | An encoding of the AbstractFeatureWithLifespan class SHALL comply with requirement /req/core/featurewithlifespan-validfrom. |
| F | An encoding of the AbstractFeatureWithLifespan class SHALL comply with requirement /req/core/featurewithlifespan-validto. |
Requirement 9: Requirement — Feature with Lifespan Creation Date | |
|---|---|
| Identifier | /req/core/featurewithlifespan-creationdate |
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeatureWithLifespan class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeatureWithLifespan class SHALL include zero or one creationDate attributes. |
Requirement 10: Requirement — Feature with Lifespan Termination Date | |
|---|---|
| Identifier | /req/core/featurewithlifespan-terminationdate |
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeatureWithLifespan class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeatureWithLifespan class SHALL include zero or one terminationDate attributes. |
Requirement 11: Requirement — Feature with Lifespan Valid From | |
|---|---|
| Identifier | /req/core/featurewithlifespan-validfrom |
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeatureWithLifespan class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeatureWithLifespan class SHALL include zero or one validFrom attributes. |
Requirement 12: Requirement — Feature with Lifespan Valid To | |
|---|---|
| Identifier | /req/core/featurewithlifespan-validto |
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the AbstractFeatureWithLifespan class SHALL comply with the following criteria: |
| B | An encoding of the AbstractFeatureWithLifespan class SHALL include zero or one validTo attributes. |
6.3. POI Class Model
The following classes form the core of the POI model. These classes are the same for all POIs.
Figure 6 — POI UML Model - Core
AbstractPOI: The abstract model for a Point of Interest.
POI: A POI instance.
FeatureOfInterest: This is an OGC Feature which has been defined independently from the POI. Conceptually, the purpose of the POI is to provide a user friendly synopsis of this Feature.
6.3.1. Abstract POI
| Identifier | /req/core/abstract-poi |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL be an accurate representation of the UML model for that class. |
| B | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-feature-with-lifespan. |
| C | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-contactinfo. |
| D | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-featureofinterest. |
| E | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-metadata. |
| F | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-keywords. |
| G | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-rights. |
| H | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-symbology. |
| I | An instantiation of the Abstract POI class SHALL comply with requirement /req/core/poi-haspayload. |
| Identifier | /req/core/poi-contactInfo |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include one or more contactInfo attributes. |
| C | Encodings of the contactInfo attribute SHALL be a valid implementation of the CI_Responsibility class from ISO 19115-1:2014 |
| Identifier | /req/core/poi-featureofinterest |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include zero or more associated instances of the FeatureOfInterest class. |
| C | The target of the hasFeatureOfInterest aggregation SHALL be a valid implementation of the Feature class from ISO 19109:2015 |
| Identifier | /req/core/poi-metadata |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include zero or more metadata attributes. |
| C | An implementation of the metadata association SHALL comply with requirement /req/core/link. |
| Identifier | /req/core/poi-keywords |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include zero or more keywords attributes. |
| C | Encodings of the keywords attribute SHALL be a valid implementation of the MD_Keywords class from ISO 19115-1:2014. |
| Identifier | /req/core/poi-rights |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include zero, one, or two rights attributes. |
| C | Encodings of the rights attribute SHALL be a valid implementation of the MD_Constraints class from ISO 19115-1:2014. |
| Identifier | /req/core/poi-symbology |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include zero or one symbology attributes. |
| C | Encodings of a symbology attribute SHALL comply with requirement /req/core/link. |
| Identifier | /req/core/poi-haspayload |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the Abstract POI class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI class SHALL include zero or more associated instances of the POI_Payload class. |
| C | The associated POI_Payload classes SHALL comply with requirement /req/core/poi-payload. |
| Identifier | /req/core/link |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | The encoding of the Link class SHALL be implemented using a hyperlink approach appropriate for implementing technology. |
6.3.2. POI
| Identifier | /req/core/poi |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An encoding of the POI class SHALL comply with requirement /req/core/req-poi-abstract-poi. |
6.4. POI Payload
A POI is a representation of a Feature. The POI class provides a standard way to identify and manage a POI. However, it does not provide any information about the Feature it is representing. This information is difficult to standardize since it is dependent on the data model of the Feature store being described.
Therefore, the POI model is designed to be extended with properties specific to a Feature or a Feature Collection. The POI Payload is a container for representations of Feature properties. The syntax of those representations is provided by the Payload Schema class. Where appropriate, semantics can also be provided through the Payload Definition class. Since the schema and definitions may be the same for a large number of Features, these classes should be instantiated as referenceable resources, allowing one instance to be used by a number of POIs.
Figure 7 — POI UML Model - Payload
POI_Payload: The abstract model for a Point of Interest. All POI instances will contain these attributes.
PayloadSchema: The Payload Schema Class represents a syntactic model (schema) for a POI payload.
PayloadDefinition: The Payload Definition Class represents a semantic model (ontology) for a POI payload.
In the interest of interoperability, the POI Payload should be constructed using data types and concepts which are already in wide use by the Geospatial community. The data types and concepts defined by the ISO 19103, ISO 19107, ISO 19109, and ISO 19115 Standards are recommended for this purpose.
While the POI Payload should have a single syntactic model (schema), there may be more than one way to represent that model. For example, JSON Schemas are commonly provided using both JSON and YAML encodings. The POI abstract model allows a POI Payload to have multiple usesSchema aggregations in order to support this practice.
The hasDefinition aggregation is provided in anticipation of the future use of ontologies to associate meaning (semantics) with the structure (syntax) of the POI Payload. Use of the hasDefinition aggregation is optional.
| Identifier | /req/core/poi_payload |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the POI_Payload class SHALL be an accurate representation of the UML model for that class. |
| B | An instantiation of the POI_Payload class SHALL comply with requirement /req/core/poi_payload-hasfeatureofinterest. |
| C | An instantiation of the POI_Payload class SHALL comply with requirement /req/core/poi_payload-hasdefinition. |
| D | An instantiation of the POI_Payload class SHALL comply with requirement /req/core/poi_payload-usesschema. |
Requirement 24: Requirement — POI Payload Has Feature of Interest | |
|---|---|
| Identifier | /req/core/poi_payload-hasfeatureofinterest |
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the POI_Payload class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI_Payload class SHALL include zero or more hasFeatureOfInterest aggregations. |
| C | The target of a hasFeatureOfInterest aggregation SHALL be a valid implementation of the Feature class from ISO 19109:2015 |
| Identifier | /req/core/poi_payload-hasdefinition |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the POI_Payload class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI_Payload class SHALL include no more than one hasDefinition aggregations. |
| C | The target of a hasDefinition aggregation SHALL be a valid ontology for the implementing technology |
| Identifier | /req/core/poi_payload-usesschema |
|---|---|
| Included in | Requirements class 1: http://www.opengis.net/spec/poi/1.0/req/core |
| A | An instantiation of the POI_Payload class SHALL comply with the following criteria: |
| B | An encoding of the Abstract POI_Payload class SHALL include one or more usesSchema aggregations. |
| C | The target of a usesSchema aggregation SHALL be a valid schema for the implementing technology. |
6.5. POI Data Dictionary
The POI UML model is the normative definition of the POI Conceptual Model. The Data Dictionary tables in this section were software generated from the UML model. As such, this section provides a normative representation of the POI Conceptual Model.
Table 1
AbstractFeature | |||||||||||||||
| |||||||||||||||
|
Table 4
AbstractFeatureWithLifespan | |||||||||||||||
| |||||||||||||||
|
Table 7
AbstractPOI | ||||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
|
Table 11
FeatureOfInterest | ||||||
|
Table 13
PayloadDefinition | ||||||
|
Table 15
PayloadSchema | ||||||
|
Table 17
POI | ||||||
| ||||||
|
Table 20
POI_Payload | ||||||||||||
| ||||||||||||
|
6.5.1. POI Data Types
The following data types are used in the POI UML model.
Table 23
CharacterString | ||||||
|
Table 25
Integer | ||||||
|
Table 27
Link | ||||||||||||||||||
| ||||||||||||||||||
|
Annex A
(informative)
Abstract Test Suite (Normative)
The following Abstract Test Suite is independent of any implementing technology. It is not to be used to assess conformance of a POI implementation. Rather, it is intended for use by developers of Implementation Standards. It provides a baseline to be extended with the technology-specific details necessary to create an Executable Test Script. It is the technology-specific Executable Test Scripts which are used to assess conformance of POI implementations.
A.1. Conformance Class Core
A.1.1. General Feature Model
| Identifier | /conf/core/generalfeaturemodel |
|---|---|
| Requirement | Requirement 1: /req/core/generalfeaturemodel |
| Target Type | Implementation Standard |
| NOTE | If the Implementation Standard is based on a Standard known to be conformant with ISO 19109 (ex: GML), then conformance with that Standard is sufficient to show conformance with ISO 19109. |
| Test purpose | Validate that the POI Implementation Standard is conformant with the ISO 19109 General Feature Model. |
| Test-method-type | Manual Inspection |
| Description | Inspect the POI Implementation Standard for the following: |
| A | Validate that the Implementation Standard includes an Abstract Test Suite (Annex A). |
| B | Validate that the Abstract Test Suite tests for conformance with the General Feature Model defined in ISO 19109. |
A.1.2. Geometry
| Identifier | /conf/core/geometry |
|---|---|
| Requirement | Requirement 2: /req/core/geometry |
| Target Type | Implementation Standard |
| NOTE | If the Implementation Standard is based on a Standard known to be conformant with ISO 19107 (ex: GML), then conformance with that Standard is sufficient to show conformance with ISO 19107. |
| Test purpose | To validate that the POI Implementation Standard is conformant with the ISO 19107 Geometry Model. |
| Test-method-type | Manual Inspection |
| Description | Inspect the POI Implementation Standard for the following: |
| A | Validate that the Implementation Standard includes an Abstract Test Suite (Annex A). |
| B | Validate that all geometries used in the Implementation Standard conform with the geometry model defined in ISO 19107. |
| C | Validate that the Abstract Test Suite tests each POI Feature for the presence of a SpatialAttributeType property of type GM_Point, GM_LineString, or GM_Polygon. |
A.1.3. Abstract Feature
| Identifier | /conf/core/abstractfeature |
|---|---|
| Requirement | Requirement 3: /req/core/abstractfeature |
| Prerequisites | Abstract test A.1: /conf/core/generalfeaturemodel Abstract test A.2: /conf/core/geometry |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the AbstractFeature Class as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Inspect the POI Implementation Standard to validate that the AbstractFeature class is properly implemented. |
| A | Validate that the implementation of the AbstractFeature class is also a valid implementation of the AnyFeature class defined in the ISO 19109 General Feature Model. |
| B | Validate correct implementation of the description attribute using test /conf/core/abstractfeature-description. |
| C | Validate correct implementation of the featureId attribute using test /conf/core/abstractfeature-featureid. |
| D | Validate correct implementation of the identifier attribute using test /conf/core/abstractfeature-identifier. |
| E | Validate correct implementation of the name attribute using test /conf/core/abstractfeature-name. |
A.1.3.1. Abstract Feature-Description
| Identifier | /conf/core/abstractfeature-description |
|---|---|
| Requirement | Requirement 4: /req/core/abstractfeature-description |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the description attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the description attribute. |
| A | Validate that zero, one, or more ‘description’ attributes are allowed in an AbstractFeature class. |
| B | Validate that the description attribute is a valid implementation of the CharacterString class from ISO 19103. |
A.1.3.2. Abstract Feature-FeatureId
| Identifier | /conf/core/abstractfeature-featureid |
|---|---|
| Requirement | Requirement 5: /req/core/abstractfeature-featureid |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the featureId attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the featureId attribute. |
| A | Validate that one ‘featureId’ attribute is required in an AbstractFeature class. |
| B | Validate that more than one ‘featureId’ attributes are allowed in an AbstractFeature class. |
| C | Validate that the featureId attribute is a valid implementation of the GenericName class from ISO 19103. |
A.1.3.3. Abstract Feature-Identifier
| Identifier | /conf/core/abstractfeature-identifier |
|---|---|
| Requirement | Requirement 6: /req/core/abstractfeature-identifier |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the identifier attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the identifier attribute. |
| A | Validate that zero, one, or more ‘identifier’ attributes are allowed in an AbstractFeature class. |
| B | Validate that the identifier attribute is a valid implementation of the ScopedName class from ISO 19103. |
A.1.3.4. Abstract Feature-Name
| Identifier | /conf/core/abstractfeature-name |
|---|---|
| Requirement | Requirement 7: /req/core/abstractfeature-name |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the name attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the name attribute. |
| A | Validate that zero, one, or more ‘name’ attributes are allowed in an AbstractFeature class. |
| B | Validate that the name attribute is a valid implementation of the GenericName class from ISO 19103. |
A.1.4. Abstract Feature with Lifespan
| Identifier | /conf/core/featurewithlifespan |
|---|---|
| Requirement | Requirement 8: /req/core/featurewithlifespan |
| Prerequisite | Abstract test A.3: /conf/core/abstractfeature |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the AbstractFeaturewithLifespan Class as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Inspect the POI Implementation Standard to validate that the AbstractFeatureWithLifespan class is properly implemented. |
| A | Validate that the implementation of the AbstractFeatureWithLifespan class is also a valid implementation of the AbstractFeature class using test /conf/core/abstractfeature. |
| B | Validate correct implementation of the creationDate attribute using test /conf/core/featurewithlifespan-creationdate. |
| C | Validate correct implementation of the terminationDate attribute using test /conf/core/featurewithlifespan-terminationdate. |
| D | Validate correct implementation of the validFrom attribute using test /conf/core/featurewithlifespan-validfrom. |
| E | Validate correct implementation of the validTo attribute using test /conf/core/featurewithlifespan-validto. |
A.1.4.1. Creation Date
| Identifier | /conf/core/featurewithlifespan-creationdate |
|---|---|
| Requirement | Requirement 9: /req/core/featurewithlifespan-creationdate |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the creationDate attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the creationDate attribute. |
| A | Validate that no more than one creationDate attribute is allowed in an AbstractFeatureWithLifespan class. |
| B | Validate that the creationDate attribute is a valid implementation of the DateTime type from ISO 19103. |
A.1.4.2. Termination Date
| Identifier | /conf/core/featurewithlifespan-terminationdate |
|---|---|
| Requirement | Requirement 10: /req/core/featurewithlifespan-terminationdate |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the terminationDate attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the terminationDate attribute. |
| A | Validate that no more than one terminationDate attribute is allowed in an AbstractFeatureWithLifespan class. |
| B | Validate that the terminationDate attribute is a valid implementation of the DateTime type from ISO 19103. |
A.1.4.3. Valid From
| Identifier | /conf/core/featurewithlifespan-validfrom |
|---|---|
| Requirement | Requirement 11: /req/core/featurewithlifespan-validfrom |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the validFrom attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the validFrom attribute. |
| A | Validate that no more than one validFrom attribute is allowed in an AbstractFeatureWithLifespan class. |
| B | Validate that the validFrom attribute is a valid implementation of the DateTime type from ISO 19103. |
A.1.4.4. Valid To
| Identifier | /conf/core/featurewithlifespan-validto |
|---|---|
| Requirement | Requirement 12: /req/core/featurewithlifespan-validto |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the validTo attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the validTo attribute. |
| A | Validate that no more than one ‘validTo’ attribute is allowed in an AbstractFeatureWithLifespan class. |
| B | Validate that the validTo attribute is a valid implementation of the DateTime type from ISO 19103. |
A.1.5. Abstract POI
| Identifier | /conf/core/abstract-poi |
|---|---|
| Requirement | Requirement 13: /req/core/abstract-poi |
| Prerequisite | Abstract test A.8: /conf/core/featurewithlifespan |
| Target Type | Implementation Standard |
| Test purpose | To validate that the Implementation Standard implements the AbstractPOI class as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate that the Implementation Standard correctly implements the AbstractPOI class: |
| A | Validate that the implementation of the AbstractPOI class is also a valid implementation of the AbstractFeatureWithLifespan class using test /conf/core/featurewithlifespan. |
| B | Validate correct implementation of the contactInfo attribute using test /conf/core/poi-contactinfo. |
| C | Validate correct implementation of the hasFeatureOfInterest aggregation using the test /conf/core/poi-featureofinterest. |
| D | Validate correct implementation of the hasMetadata association using the test /conf/core/poi-metadata. |
| E | Validate correct implementation of the keywords attribute using the test /conf/core/poi-keywords. |
| F | Validate correct implementation of the rights attribute using the test /conf/core/poi-rights. |
| G | Validate correct implementation of the symbology association using the test /conf/core/poi-symbology. |
| H | Validate correct implementation of the hasPayload association using the test /conf/core/poi-haspayload. |
A.1.5.1. Abstract POI ContactInfo
| Identifier | /conf/core/poi-contactinfo |
|---|---|
| Requirement | Requirement 14: /req/core/poi-contactInfo |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the contactInfo attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the contactInfo attribute. |
| A | Validate that zero or more contactInfo attributes are allowed in an AbstractPOI class. |
| B | Validate that the contactInfo attribute is a valid implementation of the CI_Responsibility class from ISO 19115-1:2014. |
A.1.5.2. Abstract POI Feature Of Interest
| Identifier | /conf/core/poi-featureofinterest |
|---|---|
| Requirement | Requirement 15: /req/core/poi-featureofinterest |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the hasFeatureOfinterest aggregation as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and target class of the hasFeatureOfInterest aggregation. |
| A | Validate that zero or more hasFeatureOfInterest aggregations are allowed in an AbstractPOI class. |
| B | Validate that the target of the hasFeatureOfInterest aggregation is a valid implementation of the Feature class from ISO 19109:2015. |
A.1.5.3. Abstract POI Metadata
| Identifier | /conf/core/poi-metadata |
|---|---|
| Requirement | Requirement 16: /req/core/poi-metadata |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the hasMetadata association as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and encoding of the hasMetadata association. |
| A | Validate that zero or more hasMetadata associations are allowed in an AbstractPOI class. |
| B | Validate that the hasMetadata association is implemented as described in the Conceptual Model using the /conf/core/link test. |
A.1.5.4. Abstract POI Keywords
| Identifier | /conf/core/poi-keywords |
|---|---|
| Requirement | Requirement 17: /req/core/poi-keywords |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the keywords attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the keywords attribute. |
| A | Validate that zero or more keywords attributes are allowed in an AbstractPOI class. |
| B | Validate that the keywords attribute is a valid implementation of the MD_Keywords class from ISO 19115-1:2014. |
A.1.5.5. Abstract POI Rights
| Identifier | /conf/core/poi-rights |
|---|---|
| Requirement | Requirement 18: /req/core/poi-rights |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the rights attribute as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and type of the rights attribute. |
| A | Validate that zero, one, or two rights attributes are allowed in an AbstractPOI class. |
| B | Validate that the rights attribute is a valid implementation of the MD_Constraints class from ISO 19115-1:2014. |
A.1.5.6. Abstract POI Symbology
| Identifier | /conf/core/poi-symbology |
|---|---|
| Requirement | Requirement 19: /req/core/poi-symbology |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the symbology association as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and encoding of the symbology association. |
| A | Validate that zero or one symbology associations are allowed in an AbstractPOI class. |
| B | Validate that the symbology association is implemented as described in the Conceptual Model using the /conf/core/link test. |
A.1.5.7. Abstract POI Payload Association
| Identifier | /conf/core/poi-haspayload |
|---|---|
| Requirement | Requirement 20: /req/core/poi-haspayload |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the hasPayload aggregation as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and target class of the hasPayload aggregation. |
| A | Validate that zero or more hasPayload aggregations are allowed in an AbstractPOI class. |
| B | Validate that the target of the hasPayload aggregation is a valid implementation of the POI_Payload class using the /conf/core/poi-payload test. |
A.1.5.8. Link
| Identifier | /conf/core/link |
|---|---|
| Requirement | Requirement 21: /req/core/link |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the Link class as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate that the association being tested uses a hyperlink approach appropriate for the implementing technology. |
A.1.6. POI Payload
| Identifier | /conf/core/poi_payload |
|---|---|
| Requirement | Requirement 23: /req/core/poi_payload |
| Target Type | Implementation Standard |
| Test purpose | To validate that the Implementation Standard implements the POI_Payload Class as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate that the Implementation Standard correctly implements the POI_Payload class: |
| A | Validate correct implementation of the usesSchema aggregation using the test /conf/core/poi_payload-usesschema. |
| B | Validate correct implementation of the hasDefinition aggregation using the test /conf/core/poi_payload-hasdefinition. |
| C | Validate correct implementation of the hasFeatureOfInterest aggregation using the test /conf/core/poi_payload-hasfeatureofinterest. |
A.1.6.1. POI_Payload Uses Schema
| Identifier | /conf/core/poi_payload-usesschema |
|---|---|
| Requirement | Requirement 26: /req/core/poi_payload-usesschema |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the usesSchema aggregation as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and target class of the usesSchema aggregation. |
| A | Validate that at least one usesSchema aggregation is required in a POI_Payload class. |
| B | Validate that the target of the usesSchema aggregation is a valid schema for the implementing technology. |
A.1.6.2. POI_Payload Has Definition
| Identifier | /conf/core/poi_payload-hasdefinition |
|---|---|
| Requirement | Requirement 25: /req/core/poi_payload-hasdefinition |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the hasDefinition aggregation as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and target class of the hasDefinition aggregation. |
| A | Validate that no more than one hasDefinition aggregation is allowed in a POI_Payload class. |
| B | Validate that the target of the hasDefinition aggregation is a valid ontology for the implementing technology. |
A.1.6.3. POI_Payload Feature Of Interest
| Identifier | /conf/core/poi_payload-hasfeatureofinterest |
|---|---|
| Requirement | Requirement 24: /req/core/poi_payload-hasfeatureofinterest |
| Target Type | Implementation Standard |
| Test purpose | Validate that the Implementation Standard implements the hasFeatureOfinterest aggregation as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate the cardinality and target class of the hasFeatureOfInterest aggregation. |
| A | Validate that zero or more hasFeatureOfInterest aggregations are allowed in a POI_Payload class. |
| B | Validate that the target of the hasFeatureOfInterest aggregation is a valid implementation of the Feature class from ISO 19109:2015. |
A.1.7. POI
| Identifier | /conf/core/poi |
|---|---|
| Requirement | Requirement 22: /req/core/poi |
| Prerequisite | Abstract test A.13: /conf/core/abstract-poi |
| Target Type | Implementation Standard |
| Test purpose | To validate that the Implementation Standard implements the POI Class as defined in the POI Conceptual Model. |
| Test-method-type | Manual Inspection |
| Description | Validate that the Implementation Standard correctly implements the POI class: |
| A | Validate that the implementation of the POI class is also a valid implementation of the Abstract_POI class using test /conf/core/abstract-poi. |
Annex B
(informative)
Revision History
Table B.1
| Date | Release | Editor | Primary clauses modified | Description |
|---|---|---|---|---|
| 2021-06-17 | 0.0.1 | Matthew Purss | all | initial version |
| 2024-02-15 | 1.0.0 | Chuck Heazel | all | POI draft standard for OAB review |
Bibliography
[1] Thomas H. Kolbe, Tatjana Kutzner, Carl Stephen Smyth, Claus Nagel, Carsten Roensdorf, Charles Heazel: OGC 20-010, OGC City Geography Markup Language (CityGML) Part 1: Conceptual Model Standard. Open Geospatial Consortium (2021). http://www.opengis.net/doc/IS/CityGML-1/3.0.0.
[2] ISO: ISO 1087-1, Terminology work — Vocabulary — Part 1: Theory and application. International Organization for Standardization, Geneva https://www.iso.org/standard/20057.html.
[3] ISO/IEC: ISO/IEC 2382, Information technology — Vocabulary. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/63598.html.
[4] ISO: ISO 11404:2007, ISO (2007).
[5] ISO: ISO 19104, Geographic information — Terminology. International Organization for Standardization, Geneva https://www.iso.org/standard/63541.html.
[6] ISO: ISO 19111:2019, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/74039.html.
[7] ISO: ISO 19112, Geographic information — Spatial referencing by geographic identifiers. International Organization for Standardization, Geneva https://www.iso.org/standard/70742.html.
[8] ISO: ISO 19117:2012, Geographic information — Portrayal. International Organization for Standardization, Geneva (2012). https://www.iso.org/standard/46226.html.
[9] ISO: ISO 19118, Geographic information — Encoding. International Organization for Standardization, Geneva https://www.iso.org/standard/44212.html.
[10] ISO: ISO 19119:2016, Geographic information — Services. International Organization for Standardization, Geneva (2016). https://www.iso.org/standard/59221.html.
[11] ISO: ISO 19133, Geographic information — Location-based services — Tracking and navigation. International Organization for Standardization, Geneva https://www.iso.org/standard/32551.html.
[12] ISO: ISO 19136-1, Geographic information — Geography Markup Language (GML) — Part 1: Fundamentals. International Organization for Standardization, Geneva https://www.iso.org/standard/75676.html.
[13] ISO: ISO 19143, Geographic information — Filter encoding. International Organization for Standardization, Geneva https://www.iso.org/standard/42137.html.
[14] ISO: ISO 19150-1, Geographic information — Ontology — Part 1: Framework. International Organization for Standardization, Geneva https://www.iso.org/standard/57465.html.. ISO
[15] ISO: ISO 19150-2, Geographic information — Ontology — Part 2: Rules for developing ontologies in the Web Ontology Language (OWL). International Organization for Standardization, Geneva https://www.iso.org/standard/57466.html.
[16] ISO: ISO 19150-4, Geographic information — Ontology — Part 4: Service ontology. International Organization for Standardization, Geneva https://www.iso.org/standard/72177.html.
[17] ISO: ISO 19155, Geographic information — Place Identifier (PI) architecture. International Organization for Standardization, Geneva https://www.iso.org/standard/32573.html.
[18] ISO: ISO 19156:2011, Geographic information — Observations and measurements. International Organization for Standardization, Geneva (2011). https://www.iso.org/standard/32574.html.
[19] ISO: ISO 19160-4, Addressing — Part 4: International postal address components and template language. International Organization for Standardization, Geneva https://www.iso.org/standard/83470.html.
[20] ISO/IEC: ISO/IEC 19501, Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/32620.html.
[21] W3C. Points of Interest Core W3C Working Draft 12 May 2011. https://www.w3.org/TR/poi-core
[22] ISO TC211 Harmonized Model Maintenance Group. ISO/TC 211 Harmonized UML Model. https://github.com/ISO-TC211/HMMG
[23] Object Management Group, Model Driven Architecture Guide rev. 2.0