7.2.1.1.  Context and data model

Temporal geometry is geometry constrained to one of the temporal coordinate systems, defined by TemporalCS in ISO 19111:2019. Temporal geometry primitives instant and interval implement the temporal analogues of point and line respectively in ISO 19107:2019. All geometry has topology, and the temporal topology primitives nodeT and edgeT implement the temporal analogues of node and edge respectively. These are shown in Figure 3.

Figure 3 — Primitives of Temporal Geometry and Topology

Temporal interfaces paralleling the spatial geometry and topology interface structure are built from these temporal primitives. Each temporal interface has the same meaning and semantics as their equivalent spatial interface, with the constraint that all temporal interfaces are constrained to the same coordinate system as their temporal primitives. Figure 4 shows the spatial classes on the left and their temporal equivalents on the right.

Figure 4 — ISO 19107:2019 Context for Temporal Geometry and Topology

7.2.1.2.  Defining tables

1. Table 5 — Elements of Temporal Geometry and Topology::Duration

2. Table 6 — Elements of Temporal Geometry and Topology::EdgeT

3. Table 7 — Elements of Temporal Geometry and Topology::Instant

4. Table 8 — Elements of Temporal Geometry and Topology::Interval

5. Table 9 — Elements of Temporal Geometry and Topology::NodeT

6. Table 10 — Elements of Temporal Geometry and Topology::TemporalGeometricCollection

7. Table 11 — Elements of Temporal Geometry and Topology::TemporalGeometricComplex

8. Table 12 — Elements of Temporal Geometry and Topology::TemporalGeometricPrimitive

9. Table 13 — Elements of Temporal Geometry and Topology::TemporalGeometry

10. Table 14 — Elements of Temporal Geometry and Topology::TemporalTopologicalComplex

11. Table 15 — Elements of Temporal Geometry and Topology::TemporalTopologicalPrimitive

12. Table 16 — Elements of Temporal Geometry and Topology::TemporalTopology

Table 5 — Elements of Temporal Geometry and Topology::Duration

Table 6 — Elements of Temporal Geometry and Topology::EdgeT

Table 7 — Elements of Temporal Geometry and Topology::Instant

Table 8 — Elements of Temporal Geometry and Topology::Interval

Table 9 — Elements of Temporal Geometry and Topology::NodeT

Table 10 — Elements of Temporal Geometry and Topology::TemporalGeometricCollection

Table 11 — Elements of Temporal Geometry and Topology::TemporalGeometricComplex

Table 12 — Elements of Temporal Geometry and Topology::TemporalGeometricPrimitive

Table 13 — Elements of Temporal Geometry and Topology::TemporalGeometry

Table 14 — Elements of Temporal Geometry and Topology::TemporalTopologicalComplex

Table 15 — Elements of Temporal Geometry and Topology::TemporalTopologicalPrimitive

Table 16 — Elements of Temporal Geometry and Topology::TemporalTopology

The following requirement applies:

7.2.2.1.  Context and data model

Referring to Figure 5, ZoneGeometry is either a primitive of ZoneSingleGeometry or a compound of two ZoneSingleGeometry primitives — one spatial and one temporal.

Zones exhibit topology of the same spatio-temporal dimension as their geometry.

Figure 5 — Components of Zonal Geometry and Topology module

7.2.2.2.  Defining tables

1. Table 17 — Elements of Zonal Geometry and Topology::ZoneCompoundGeometry

2. Table 18 — Elements of Zonal Geometry and Topology::ZoneCompoundTopology

3. Table 19 — Elements of Zonal Geometry and Topology::ZoneGeometry

4. Table 20 — Elements of Zonal Geometry and Topology::ZoneSimpleGeometry

5. Table 21 — Elements of Zonal Geometry and Topology::ZoneSimpleTopology

6. Table 22 — Elements of Zonal Geometry and Topology::ZoneTopology

Table 17 — Elements of Zonal Geometry and Topology::ZoneCompoundGeometry

Table 18 — Elements of Zonal Geometry and Topology::ZoneCompoundTopology

Table 19 — Elements of Zonal Geometry and Topology::ZoneGeometry

Table 20 — Elements of Zonal Geometry and Topology::ZoneSimpleGeometry

Table 21 — Elements of Zonal Geometry and Topology::ZoneSimpleTopology

Table 22 — Elements of Zonal Geometry and Topology::ZoneTopology

The following requirement applies:

7.3.1.1.  Context and data model

ISO 19112:2019 describes spatial refencing by geographic identifiers, locations and location classes. The LocationS interface is a specialisation of the Location interface from ISO 19112:2019. See Figure 6. In the next section the Period interface is introduced as the temporal equivalent of LocationS.

Figure 6 — Context for LocationS

7.3.1.2.  Defining tables

1. Table 23 — Elements of Spatial Location::LocationS

Table 23 — Elements of Spatial Location::LocationS

The following requirement applies:

7.3.2.1.  Context and data model

Semantically, the terms period and zone are defined as the temporal and spatio-temporal equivalents of a location. These are represented in the data model by the interfaces Period and Zone.

Referring to Figure 7 showing the spatial classes on the left and the temporal classes on the right, it is noted that Period is augmented by:

• PeriodIdentifier data-type as the temporal equivalent of GeographicIdentifier,

• Period interface as the temporal equivalent of LocationS, see Figure 6,

• PeriodClass interface as the temporal equivalent of LocationClass, and

• TemporalReferenceSystemusingPeriodIdentifiers interface as the temporal equivalent of SpatialReferenceusingGeographicIdentifiers.

Figure 7 — Context for Temporal RS using Identifiers module

7.3.2.2.  Defining tables

1. Table 24 — Elements of Temporal RS using Identifiers::Period

2. Table 25 — Elements of Temporal RS using Identifiers::PeriodClass

3. Table 26 — Elements of Temporal RS using Identifiers::PeriodIdentifier

4. Table 27 — Elements of Temporal RS using Identifiers::TemporalReferenceSystemUsingPeriodIdentifiers

Table 24 — Elements of Temporal RS using Identifiers::Period

Table 25 — Elements of Temporal RS using Identifiers::PeriodClass

Table 26 — Elements of Temporal RS using Identifiers::PeriodIdentifier

Table 27 — Elements of Temporal RS using Identifiers::TemporalReferenceSystemUsingPeriodIdentifiers

The following requirement applies:

7.3.3.1.  Context and data model

Semantically zones are the spatio-temporal equivalent of periods and locations. Zones are represented in the data model by the interface Zone and along with it the following interfaces are also established.

• ZonalIdentifier,

• ZoneClass, and

• RSUsingZonalIdentifiers.

Referring to Figure 8, a ZonalIdentifier is either a zonal identifier primitive or a compound of two zonal identifier primitives, one spatial and one temporal.

Figure 8 — Primitives of ZonalIdentifier

Referring to Figure 9, a Zone is either a zonal primitive or a compound of two zonal primitives, one spatial and one temporal.

Figure 9 — Primitives of Zone

Referring to Figure 10, a ZoneClass is either a zonal class primitive or a compound of two zonal class primitives, one spatial and one temporal.

Figure 10 — Primitives of ZoneClass

Referring to Figure 11, an RSUsingZonalIdentifiers is either a zonal RS using identifiers primitive or a compound of two of its primitives, one spatial and one temporal.

Figure 11 — Primitives of RSUsingZonalIdentifiers

Referring to Figure 12, Zone, ZonalIdentifier and ZoneClass come together to form RSUsingZonalIdentifiers.

Figure 12 — Components of RSUsingZonalIdentifiers

7.3.3.2.  Defining tables

1. Table 28 — Elements of Zonal RS using Identifiers::RSUsingZonalIdentifiers

2. Table 29 — Elements of Zonal RS using Identifiers::RSUsingZonalIdentifiersCompound

3. Table 30 — Elements of Zonal RS using Identifiers::RSUsingZonalIdentifiersPrimitive

4. Table 31 — Elements of Zonal RS using Identifiers::ZonalIdentifier

5. Table 32 — Elements of Zonal RS using Identifiers::ZonalIdentifierComplex

6. Table 33 — Elements of Zonal RS using Identifiers::ZonalIdentifierPrimitive

7. Table 34 — Elements of Zonal RS using Identifiers::Zone

8. Table 35 — Elements of Zonal RS using Identifiers::ZoneClass

9. Table 36 — Elements of Zonal RS using Identifiers::ZoneClassComplex

10. Table 37 — Elements of Zonal RS using Identifiers::ZoneClassPrimitive

11. Table 38 — Elements of Zonal RS using Identifiers::ZoneCompound

12. Table 39 — Elements of Zonal RS using Identifiers::ZonePrimitive

Table 28 — Elements of Zonal RS using Identifiers::RSUsingZonalIdentifiers

Table 29 — Elements of Zonal RS using Identifiers::RSUsingZonalIdentifiersCompound

Table 30 — Elements of Zonal RS using Identifiers::RSUsingZonalIdentifiersPrimitive

Table 31 — Elements of Zonal RS using Identifiers::ZonalIdentifier

Table 32 — Elements of Zonal RS using Identifiers::ZonalIdentifierComplex

Table 33 — Elements of Zonal RS using Identifiers::ZonalIdentifierPrimitive

Table 34 — Elements of Zonal RS using Identifiers::Zone

Table 35 — Elements of Zonal RS using Identifiers::ZoneClass

Table 36 — Elements of Zonal RS using Identifiers::ZoneClassComplex

Table 37 — Elements of Zonal RS using Identifiers::ZoneClassPrimitive

Table 38 — Elements of Zonal RS using Identifiers::ZoneCompound

Table 39 — Elements of Zonal RS using Identifiers::ZonePrimitive

The following requirement applies:

8.2.4.1.  Cell simple geometry

Semantically, the terms cell and zone refer to different characteristics of the same region of space-time. Cells in a DGGS shall be geometrically simple. Simple geometries have the following properties:

1. they do not self-intersect;

2. they are topologically the same as a circle, or the circle’s equivalent in the dimension of the cell. e.g. to a sphere in three-dimensions; and

3. they enclose a region which is always measurable using a metric of the same dimensionality as the cell.

The following requirement applies:

8.2.4.2.  Cell position

Each cell’s zone has a fixed representative position in the space of the base CRS, recorded as a direct position.

The following requirement applies:

8.2.4.3.  Cell address

Each cell’s zone shall be assigned a unique address in the form of a zonal identifier. The value assigned to each address shall be structured on one or more of these four general indexing methods: hierarchy-based, space-filling curve based, coordinate [1] and encoded address schemas (such as those used for IP addresses [10]).

The following requirement applies:

8.3.3.1.  Overview of topological query functions

The Topological Query Functions module implements the DE9IM [5] functionality defined in ISO 19107:2019 Geometry::Query2D and Geometry::Query3D for zonal topology. This is achieved through a single interface called ZoneQuery (Figure 16, Table 53). By default ZoneQuery operates at the dimensionality of the DGGS’s zones. Changes in dimensionality are controlled with an optional parameter projectTo that constrains ZoneQuery to a specified reference direction, surface or volume.

Two additional operations are provided that are based on the temporal concept of relative position. These are called relatePosition and relativePosition. These are generalized for use on any single reference direction specified by projectTo, not just the temporal direction.

Six additional operations are provided in ZoneQuery that leverage the ZoneClass hierarchy. These are called parent, child and sibling and parentOf, childOf and siblingOf.

ZoneQuery operations are defined in Figure 16 and Clause 8.3.4. The following parameters are shared by many of the operations as specified in <Table 53

another

type ZonalIdentifier, mandatory.
Specifies the target region for the query. In zonal query a zone’s identifier provides sufficient description of its topology. ZonalIdentifier therefore takes the place of the geometry data used in Query2D and Query3D for both the source and the target.

inheritID

type Boolean, optional, default ⇐ False
When inheritID has a value of True the result «set» only contains cells for which the IDs have shared inheritance, and a value of False indicates that inheritance is ignored.

projectTo

type directPosition[4], optional, default ⇐ (0,0,0,1) for relatePosition and relativePosition, otherwise (1,1,1,1)
projectTo specifies an optional reference direction, surface or volume for an operation.
Allowed values for each direction are 0 and 1, and spatial directions may also have a value of n.
projectTo defines a vector whose starting point is inferred as the point with each projectTo direction whose value is 1 set to 0. It takes one of three forms.
In its one-dimensional form for specifying a reference direction, one direction has a value of 1. For example (0,0,0,1) projects to the temporal axis, and (0,0,1,0) projects to the vertical axis.
In its two-dimensional form for specifying a reference surface, two directions have a value of 1. For example a surface at height n is specified by a projectTo value of (1,1,n,0) representing the vector [ (0,0,n,0), (1,1,n,0) ].
In its three-dimensional form for specifying a reference volume, three directions have a value of 1. For example (1,1,1,0) projects to a spatial volume without reference to time, and (1,1,n,1) projects to a surface spanning all time at height n.
Only the one-D\dimensional form is supported by relativePosition and relatePosition.
While this construct could be used to implement more complex spatio-temporal queries, that isn’t the intent of Query2D, and isn’t specified for ZoneQuery either.

rangeRefine

type refinementLevelRange, optional, default ⇐ [ min(source.refinementLevel,target.refinementLevel) : max(source.refinementLevel,target.refinementLevel) ].
Specifies the range of refinement levels to include in the return «set». The lower and upper bounds in the refinementLevelRange datatype are both included in the range.

levels

type Integer, optional, default ⇐ 1
Levels indicates the relative number of levels in the hierarchy to be traversed in assembling the result «set» Figure 15 illustrates the parent, child and sibling suite of functions through examples.

8.3.3.2.  Summary of operations in ZoneQuery

The following operations have the same topological meaning as their equivalent operations in ISO 19107:2019 Geometry::Query2D and Geometry::Query3D: distance, contains, crosses, disjoint, equals, intersects, overlaps, touches, within, withinDistance, difference, intersection, symDifference, union, and relate.

1. relativePosition: A.relativePosition(B, projectTo), returns the relativePosition enumerator that describes B‘s relative position to A with respect to the direction defined by projectTo.

2. relatePosition: A.relatePosition(B, relation, projectTo) returns whether B has the relative position to A given by relation with respect to the direction projectTo

3. parentOf: A.parentOf(B, inheritID, projectTo), returns whether A is a parent cell of B, optionally filtered by inheritID and projectTo.

4. childOf: A.childOf(B, inheritID, projectTo), returns whether A is a child cell of B, optionally filtered by inheritID and projectTo.

5. siblingOf: A.siblingOf(B, inheritID, projectTo), returns whether A is a sibling cell of B, optionally filtered by inheritID and projectTo.

6. parent: A.parent(inheritID, projectTo, levels), returns the unique «set» of zoneIdentifiers for zones that satisfy A.parentOf(B, inheritID, projectTo) applied recursively levels times up the parent hierarchy. The «set» will have at most one member from each level of the hierarchy if inheritID is True, and may have more than one if the cell refinementStrategy is not nested.

7. child: A.child(inheritID, projectTo, levels), returns the unique «set» of zoneIdentifiers for zones that satisfy A.parentOf(B, inheritID, projectTo) applied recursively levels times down the parent hierarchy.

8. sibling: A.sibling(inheritID, projectTo, levels), returns the unique «set» of zoneIdentifiers for zones that satisfy A.parentOf(B, inheritID, projectTo) applied recursively levels times outward on zones at the same refinement level. Multiple levels of sibling can also be thought of as the children of its parent(s) the specified number of levels up the hierarchy.

Figure 15 — Examples of parent, child, and sibling query operations

EXAMPLES

Parent, sibling and child queries for zone 40:
40.parent() returns {4}
40.sibling(inheritID=true) returns {40, 41, 42, 43}
40.sibling() returns {13, 22, 23, 31, 40, 41, 42, 43}
40.child(inheritID=true) returns {400, 401, 402, 403}

Parent, sibling and child tests for zone 40:
40.parentOf(400) returns true
40.siblingOf(41) returns true
40.siblingOf(31, inheritID=true) returns false
40.siblingOf(41) returns true
40.childOf(4) returns true

Parent and child tests for zones 31 and 33 with multiple parents:
31.childOf(4, inheritID=true) returns false
31.childOf(4) returns true
31.parent(inheritID=true) returns {3}
31.parent() returns {3, 4}
33.parent() returns {3, 4, 5, 6}

Parent and child queries with levels set to a value greater than 1:
400.parent(inheritID=true, level=2) returns {40, 4}
4.child(inheritID=true, 2) returns {40, 41, 42, 43, 400, 401, 402, 403, 410, 411, 412, 413, 420, 421, 422, 423, 430, 431, 432, 433}
400.sibling(inheritID=true, levels=2) returns {400, 401, 402, 403, 410, 411, 412, 413, 420, 421, 422, 423, 430, 431, 432, 433}
While some of these results extend to zones that are not drawn in the figure, the location indicated by their zonal identifier should be readily apparent from the pattern.

Further query and analysis functions may then be applied to the returned data through additional software bindings. This abstract specification does not specify any requirements for the binding or implementation of further, extension, query or analytic functions.

Figure 16 — Components of Topological Zonal Query Functions module

8.3.5.1.  Overview of interoperation functions

While the quantization and topological query functions enable a DGGS implementation to successfully operate internally, in order to facilitate connectivity with other spatial data infrastructures additional interoperation functions are required. As shown in Figure 17, the interoperation functions are split into two modules:

1. Interoperation Query: Interpret and translate external data queries sent to the DGGS implementation; and

2. Interoperation Broadcast: Convert the result set returned from a DGGS query operation from internal data format(s) (optimized for that DGGS implementation) to format(s) suitable for external data delivery.

This document does not specify the specific interface protocol encodings required to connect a DGGS implementation to an external client and to facilitate the transfer of information into and out of a DGGS. This abstract specification makes use of the tools available in ISO 19156:2011 to facilitate the linkage between external query operations and the data/observations assigned to the DGGS zone(s) of interest. Specific interface encodings are anticipated to be elaborated as extensions to this abstract specification.

Figure 17 — Components of Core Interoperation Functions module

8.3.5.2.  Defining tables

1. Table 55 — Elements of Interoperation::InteroperationFunctions

Table 55 — Elements of Interoperation::InteroperationFunctions

8.3.5.3.  Interoperation Query module

External queries may originate from an external client application and range in syntax from natural language queries (e.g. ‘Where are the gas pipelines in Western Canada located?’, or ‘How has the Murray-Darling Basin in Australia changed over the past 27 years?’, or ‘Compute the watershed area of the Kawarau Catchment in New Zealand’), to an OWS ‘GetCapabilities’ or similar type of query, to an SQL (or similar) statement. To support interoperability, a DGGS specification shall define methods to receive, interpret and translate an external data query (or process) request into a form that can be processed by the internal DGGS data retrieval and query functions.

Figure 18 shows the key functional elements required for DGGS to translate and execute an external query or process operations.

Figure 18 — Components of Interoperation Query module

8.3.5.4.  Defining tables

1. Table 56 — Elements of Interoperation Query::QueryComponents

2. Table 57 — Elements of Interoperation Query::QueryFunctions

3. Table 58 — Elements of Interoperation Query::QueryResult

4. Table 59 — Elements of Interoperation Query::QueryType

Table 56 — Elements of Interoperation Query::QueryComponents

Table 57 — Elements of Interoperation Query::QueryFunctions

Table 58 — Elements of Interoperation Query::QueryResult

Table 59 — Elements of Interoperation Query::QueryType

The following requirement applies:

8.3.5.5.  Interoperation Broadcast module

Just as it is necessary for DGGS to be able to interpret and execute external data queries, DGGS shall also define methods to broadcast results from data queries to external client(s) or data infrastructure(s). External clients are anticipated to be web-based client(s), software client(s) on the same ICT infrastructure as the DGGS, or other DGGS.

Figure 19 shows basic elements required to translate the result set(s) returned from a DGGS data query into a suitable data format for transfer and broadcast the reformatted result set via one or a number of data or information transfer protocols.

Figure 19 — Interoperation Broadcast

8.3.5.6.  Defining tables

1. Table 60 — Elements of Interoperation Broadcast::BroadcastFunctions

2. Table 61 — Elements of Interoperation Broadcast::TranslationType

3. Table 62 — Elements of Interoperation Broadcast::TranslationType

Table 60 — Elements of Interoperation Broadcast::BroadcastFunctions

Table 61 — Elements of Interoperation Broadcast::BroadcastType

Table 62 — Elements of Interoperation Broadcast::TranslationType

The following requirement applies:

9.1.4.1.  Tessellation overview

A multiresolution hierarchical tessellation of cells is created by constructing a sequence of discrete global grids, each with successively finer cell resolutions. First an initial discrete global grid is constructed as described in subclause Clause 9.1.4.2. The cells of this initial tessellation are then iteratively refined by application of cell refinement method(s) [2] to create finer resolution child cells. The initial tessellation, the cell shape, the refinement methods and indexing methods may all vary for different DGGSs.

9.1.4.2.  Initial tessellation

The entire surface of the Earth is partitioned to a finite/discrete set of regions. Most methods initially approximate the Earth’s surface using a simple base unit polyhedron which is scaled so that all vertices are located on the surface model of the Earth, and the edges are warped so they also lie on the surface model. The resulting edges may be any of the types listed in EA_CurveType. These include geodesics, small circles, small ellipses and lines that project to a straight line on a plane. These all result from intersections of a plane and an ellipsoid. The initial discrete global grid tessellation has the same form as the base unit polyhedron. Each EA_Cell of the initial tessellation represents one face of the chosen base unit polyhedron mapped to the chosen surface model of the Earth. This document refers to the initial tessellation as a “polyhedral tessellation”. The most common choices for an initial base unit polyhedron are discussed in subclause Annex C.4 [2].

The following requirement applies:

9.1.4.3.  Tessellation sequence

DGGS EAERS comprise a discrete sequence of global grids formed from recursive application of a tessellation method to refine the grid cells, so that each global grid has a progressively finer spatial resolution.

The following requirements apply:

9.1.4.4.  Global area preservation

Preservation of total surface area throughout the range of hierarchical tessellations is a necessary property of DGGSs in order to represent information consistently at successive resolutions. This requirement ensures that each level of grid refinement completely covers the Earth’s surface without cell overlaps.

The following requirement applies:

9.1.4.5.  Defining tables

1. Table 67 — Elements of Equal-Area Tessellation::EA_BaseUnitPolyhedron

2. Table 68 — Elements of Equal-Area Tessellation::EA_DiscreteGlobalGrid

3. Table 69 — Elements of Equal-Area Tessellation::EA_DiscreteGlobalGridTessellation

4. Table 70 — Elements of Equal-Area Tessellation::EA_InitialDiscreteGlobalGrid

5. Table 71 — Elements of Equal-Area Tessellation::EA_PolyhedralTessellation

6. Table 72 — Elements of Equal-Area Tessellation::EA_RefinedDiscreteGlobalGrid

Table 67 — Elements of Equal-Area Tessellation::EA_BaseUnitPolyhedron