OGC CDB Version 2 - Part 1: Core Standard

Data that have been processed to a minimum set of requirements and organized into a form that allows immediate use with a minimum of additional user effort for further interoperability both through time and with other datasets. (source: CEOS http://ceos.org/document_management/Meetings/Plenary/30/Documents/5.5_CEOS-CARD4L-Description_v.22.docx). ARD is an abstract concept that can only be implemented in the context of a common domain of application. The CDB 1.x standard specifies how to structure, attribute, and curate geospatial (2d and 3d) data to make that data ready for the simulation domain of application.

Other characteristics of ARD include the following.

In terms of the architecture, ARD fits well with the requirements specified in an application profile. An application profile of the CDB Core would provide requirements for data content and structure for a given domain, such as simulation or tactical.

Officially recognized data that can be certified and is provided by an authoritative source.

(SOURCE: Authority and Authoritative Sources: Clarification of Terms and Concepts for Cadastral Data. FGDC/NIST 2008)

An information technology (IT) term used by system designers to identify a system process that assures the veracity of data sources. These IT processes should be followed by all geospatial data providers. The data may be original or it may come from one or more external sources all of which are validated for quality and accuracy.

(SOURCE: Authority and Authoritative Sources: Clarification of Terms and Concepts for Cadastral Data. FGDC/NIST 2008)

A data store is a repository for persistently storing and managing collections of data which include not just repositories such as databases, but also simpler store types such as simple files, metadata, models, etc.

Requirements class which has a direct dependency on another requirements class.

Authoritative data and models that have been curated and stored in a CDB repository. Foundation data uses known and agreed to controlled vocabularies for attribution, has been curated based on the requirements as stated in the CDB standard or some other authoritative source, and supported by required metadata.

For example, as per the CDB 1.3 Standard (and industry best practice), a road network (RoadNetwork dataset in CDB 1.3) could be considered as foundation data. In CDB 1.3, there are a set of requirements associated with how the roads data are structured and attributed and stored in a CDB repository. The specification of any foundation data layer (such as RoadNetwork) at the logical model level can be 100% independent from the storage environment, end user use case(s), and so on while at the same time also having the requirements based on industry knowledge and use case requirements.

Any CDB 2.X foundation data requirements should not mention the actual storage structure, enabling software, storage formats, tiling structure, and so forth.

Specification or standard consisting of a set of references to one or more base standards and/or other profiles, and the identification of any chosen conformance test classes, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. [ISO/IEC TR 10000-1] In the usage of this standard, a profile will be a set of or extensions to requirements classes or conformance classes (either preexisting or locally defined) of the base standards.

In the CDB 2.0 Standard and later, the requirements and any related extensions are based on the use cases and interoperability requirements of a specific domain or information community. Some example Profiles are could be for tactical training, for gaming, and for flight simulation. All of these and any other defined profiles shall implement and be consistent with conformance classes as defined in the CDB Core Standard.

entity to which some requirements of a standard apply. (The Specification Model — A Standard for Modular specifications)

For the CDB Standard, the standardization target for the core would be any extension, application profile and implementation of a CDB data store conformant with the core. So, for example, the standardization target for an extension would be the core conformance class. Specifically, every requirements class in a standard shall have a standardization target type which is a subtype of that of the core and shall have the core as a direct dependency.

The CDB standard makes use of namespaces to isolate the definitions of required schemas. The name of these namespaces is built around the base CDB URL.

The following is in reference to how global metadata, vocabularies, and enumerations are provided as part of the CDB Standard on the OGC website. These schemas can be used as the source to populate the global metadata folder in a CDB datastore.

The target namespace of all CDB schemas for vocabularies and enumerations follow this pattern:

"http://opengis.net/cdb/Version/Name

Where the Name is identical to the filename or URI portion of the file containing the schema and Version is the version number of the schema.

To illustrate how a target namespace/URI is composed, here is the target namespace for the Lights vocabulary provided as XML schema:

"http://opengis.net/cdb/2.0/Lights.xml"

Controlled vocabularies provide a way to organize knowledge for subsequent retrieval and use. They are used in subject indexing schemes, subject headings, thesauri, taxonomies and other forms of knowledge organization systems. Controlled vocabulary schemes mandate the use of predefined, authorized terms that have been preselected by the designers of the schemes, in contrast to natural language vocabularies, which have no such restriction. The use of controlled vocabularies in standards such as CDB can significantly increase interoperability and consistent understanding of the semantics. Controlled vocabularies typically are managed through formal processes and official governance.

In computer programming, an enumerated type (also called an enumeration) is a data type consisting of a set of named values called elements, members, or enumerators of the type. The enumerator names are usually identifiers that behave as constants in the language. Similarly, in a database enumerated (enum) types are data types that comprise a static, ordered set of values. They are equivalent to the enum types supported in a number of programming languages. An example of an enum type might be the days of the week, or a set of status values for a piece of data.

The following is from Technopedia.

A datastore is a repository for storing, managing and distributing datasets typically at an enterprise level. Datastore is a broad term that incorporates all types of data that is produced, stored and used by an organization. The term references data that is at rest and used by one or more data-driven applications, services, or individuals.

A datastore may include data from end user database applications, files or documents, or the random data property of an organization or an information system. Data may be structured, unstructured, or in another electronic format.

Depending on the organization, a datastore may be classified as an application-specific datastore, operational datastore or centralized datastore. Moreover, a datastore may be designed and implemented by using purpose-built software or through typical database applications.

The CDB 2.0 Standard is grounded in a number of OGC Abstract Specifications, ISO TC 211 91xxx series International Standards, and standards from other Standards Development Organization such as the W3C and the IETF. The OGC Abstract Specification and ISO 19xxx Standards provide the conceptual foundation for many OGC standards development activities. They also provide a conceptual (abstract) foundation for many other geospatial standards development activities in the IETF, W3C, OASIS, and a large number of government organizations. Open interfaces and protocols can be designed, built, and referenced against the Abstract Specification, thus enabling interoperability between different platforms, applications, and different spatial processing systems. The Abstract Specification provides a reference model for the development of standards that can be implemented.

The CDB Core consists of core requirements modules and corresponding conformance classes that any extension, application profile, or implementation of the CDB Standard shall be conformant with. For example, any implementation of an Application Profile (aka Profile) shall inherit and be dependent on the conformance classes as defined and implemented in the Core. In the above diagram, several requirements modules are mandatory. Any application profile (including extensions) shall conform with the requirements stated in those modules. However, if an optional core module is specified in an application profile (including extensions) then that profile shall conform with the requirements stated in those modules.

The CDB Fundamental Core is comprised of a set of abstract requirements modules and related conformance modules. These requirements modules are defined by an aggregate of requirements and recommendations that are abstract in the sense that they cannot be directly implemented. Instead, they need to be profiled or profiled with extensions in order to be implemented. However, any profile, profile with extensions, or implementation of any given requirements class shall be conformant with that core requirements class.

Another key design concept of the Core is that each specified requirements module - as defined by one or more requirements classes - has no dependencies on any other core requirements module. For example the CRS Core Requirements Module has no dependencies on Geometry and visa-versa. The only exception is the metadata core module. More on that below.

The CDB 2.0 core is not implementable. While the core consists of requirements classes and related conformance classes, profiles that restrict any given requirement or requirements module are necessary to create a set of requirements and conformance classes that can be implemented. In CDB 2.0, these are called application profiles.

For example, CDB 2.0 Core specifies a Coordinate Reference System (CRS) Requirements Module]. This requirements Module does not mandate which CRS is to be used for a given implementation instance or profile. Instead, that restriction would be specified in a profile or profile with extensions. The CRS requirements module also specifies requirements such as that the ISO/OGC Well Known Text for CRS (WKT for CRS) shall be used to encode the CRS metadata for storage in a CDB datastore.

A CDB 2.0 compliant datastore can be implemented using the Attribution rules and requirements as specified in the CDB 1.3 Standard. An example of this approach is provided in the CDB Version 2.0 GeoPackage Profile for CDB 1.x Datastores Standard.

If the CDB 1.3 approach to attribution is not desired, then the following requirements class should be used.

The following is the CDB 2.0 Attributes Requirements Class.

For the purposes of this document, the following additional terms and definitions apply. The definitions for “height” and “depth” are meant to be general and are derived from ISO 19111. However, the reader should note that there ma be domain specific variations or enhancements of the definitions used in this standard.

The CRS for any Coverage content in a CDB datastore has to be the same as specified by the global CRS metadata defined as per the CRS Requirements module.

At a minimum any Coverage content must have a minimum set of resource (dataset) metadata as defined in the CDB Core Metadata Module.

The following provides additional information on the domainSet metadata elements.

While there is no a specific CDB requirement that a coverage be tiled, for the vast majority of use cases coverages are tiled. This requirement is driven by performance requirements. There, tiling coverages in a CDB datastore is recommended. As such, if a coverage is tiled then the following requirements are mandatory.

The following is the CDB Core CRS requirements class.

CDB 1.x series of standards specified a consistent set of file extensions for any resource containing content. For example, every Shapefile in a CDB datastore has the .shp file extension. The use of these file extensions, along with others, continue to be used and specified in CDB 2.0 and later. The table below the next requirement provides a list of file types/encodings used in CDB version 1.x as well as additional file types and extensions that may be used in CDB 2.0 and later implementations.

NOTE 1: In the CDB 1.x Standard, the root directory/folder was identified as \CDB

NOTE 2: In CDB 2.0 and later, the concept of the root location is identical to the OGC API concept of landing page.

The following is the Simple Features Geometry Class Hierarchy.

Geometry is the root class of the hierarchy. Geometry is an abstract (non-instantiable) class. The instantiable subclasses of Geometry defined in this Standard are restricted to 0, 1 and 2-dimensional geometric objects that exist in 2, 3 or 4-dimensional coordinate space (ℜ2, ℜ3 or ℜ4). Geometry values in R2 have points with coordinate values for x and y. Geometry values in R3 have points with coordinate values for x, y and z or for x, y and m. Geometry values in R4 have points with coordinate values for x, y, z and m where "m" is a measure which could be date and time. (Source: Simple feature access - Part 1: Common architecture)

Geometry types specified in the model that can be used in a CDB 2.0 or later data store are defined in the following table. Please note that an CDB application profile can extend the allowed set of Geometry Types. Please also note that A GeometryCollection is a geometric object that is a collection of some number of geometric objects. All the elements in a GeometryCollection shall be in the same Spatial Reference System. This is also the Spatial Reference System (or Coordinate Reference System) for the GeometryCollection.

Table Geometry 1: Core Geometry Types

The following table is the set of core geometries that may have a Z element or coordinate associated with the geometry coordinates. Typically the Z value is the height above or below the elipsoid but could also be the height of a building or the depth of a well. The z coordinate value traditionally represents the third dimension (i.e. 3D). For example: A map might have point identifying the position of a mountain peak by its location on the earth, with the x and y coordinate values, and the height of the mountain, with the z coordinate value.

The following table is the set of core geometries that may have a M element associated with the geometry. M stands for a measure, such as precipitation or soil accidity.

NOTE 1: The Name of the geometry type as used in CDB 2.0 is consistent with the OGC Simple Features, GeoPackage, GeoJSON and other standards that reference Simple Features as normative.

NOTE 2: The codes are consistent with those specified in GeoPackage.

The above geometry types are considered to be components of the core. The following geometry types may also be specified for use as extensions in any CDB 2.0 application profile.

The following is the Geometry Requirements Class.

All Geometry classes described in this Standard are defined so that instances of Geometry are topologically closed. In other words, all represented geometries include their boundary as point sets.

Templated links may used used in a CDB data store. Templated linksare used to bind to resources that may require additional information in order to access the resources. For example, simply knowing the URL of a legacy OGC service such as WMS or WFS is not sufficient to access resources offered by those services. Additional information in the form of request parameters and values are required in order to have a complete link to a resources. A templated link with variables can provide this additional context. In a CDB datastore, a typicaly use for a templated link would be to access additional information related to an entry in the attribute model.

Metadata and controlled vocabularies in a CDB datastore are encoded as XML or JSON. Additionally, resources may be encoded as GeoPackages, GeoJSON, Shapefiles, OpenFlight models, glTF, and so on.

The following table lists the Media Types to use for CDB metadata and datasets. This table can be extended as required.

Metadata is data that provides information about other data. In the geospatial community and the rapidly emerging spatial web community, metadata is critical to operations such as discovery and determining whether a resource is “fit for purpose”. Three distinct types of metadata exist: descriptive metadata, structural metadata, and administrative metadata (National Information Standards Organization (NISO)).

The geospatial community has a long and extensive history in defining and using metadata for geospatial resources. Without metadata, discovery of required resources and determination of whether a resource is “Fit for Purpose” becomes difficult if not impossible. The geospatial community makes use of all three types of metadata, although the first and third are more critical. The CDB use of metadata focuses on use cases 1 and 3.

While much of the CDB Core requirements, such as the CRS requirements, are related to metadata in one form or another, this sestion specifies requirements targeted at 1.) Global Metadata for a CDB datastore and 2.) more "traditional" metadata for location enabled resources and datasets. There are a number of metadata and controlled vocabularies, such as Lights and Version, that may be used as part of a CDB datastore implementation. The global metadata properties and controlled vocabulary elements are described with requirements in their own Clauses in the core CDB 2.0 Standard.

The CDB Core Standard provides the requirements for:

More specifically, Global metadata, including vocabularies, are data such as CDB version or Lights are global to an entire CDB data store instance. Individual file sets, tiles, and other resources in a CDB data store may also have metadata. These resources are termed “resource” metadata.

Resource metadata refers to metadata specific to a given dataset within a CDB data store. This level of metadata is the minimum core for geospatial datasets regardless of the specific geospatial subject (i.e., vector, raster (imagery), sensor, or model). Metadata at this level is designed to assist in discovery, retrieval and semantic description of the data. Dataset level metadata is typically stored at the model or tile level.

In CDB 1.x the majority of CDB controlled vocabularies, enumerations, and metadata files are encoded using eXtended Markup Language (XML) files. In CDB 1.x the XML schemas can be found in the \CDB\Metadata\Schema\ folder delivered with the CDB standard. In CDB 1.x the exceptions are the global and local geospatial metadata files which may be XML schema, JSON, JSON schema, or some other internationally recognized encoding. In CDB 2.0 and later, any metadata may be encoded using XML, JSON or stored in a database table. However, the encoding chosen shall be consistent throughout a given CDB datstore instance.

Resource Metadata may also be stored in a GeoPackage using the GeoPackage Metadata Extension.

The following requirements class specifies the required metadata elements applicable to an entire CDB datastore.

Each of the fundamaental metadata requirements are now defined.

The following figure, based on the Tiling Abstract Specification Logical Model, shows the properties by class (concept) and the relationships between the classes.

The CDB Abstract Tiling Requirements module is optional. However, if tiling is to be implemented in a CDB data store, then this is a mandatory requirements class. Any tiling implementation, profile, extension, or application profile shall conform with this requirements class and related conformance class.

Version 1 of OGC Two Dimensional Tile Matrix Set (2DTMS) defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids defining a domain (tile matrix). Version 1 provided a limited list of scales in a Coordinate Reference System (CRS) as defined in [OGC 08-015r2] Abstract Specification Topic 2: Spatial Referencing by Coordinates. The latest revision of 2DTMS titled OGC Two Dimensional Tile Matrix Set and Tile Set Metadata provides numerous changes including detailed guidance and examples for specifying a tiled CDB datastore.

A key concept in 2DTMS that is relevant to the recommended CDB tiling scheme (CDB1GlobalGrid) is Variable width tile matrices. Many tiling schemes assume that matrixWidth is constant for all tile rows. This is common usage for projections that do not distort the Earth too much. However, when using any regular tessellation, the distortion increases for tiles closer to the poles. In the extreme, the upper row of the upper tile (the one representing the North Pole) contains a list of repeated values that represents almost the same position in the space.

The solution consists of reducing the number of tiles (matrixWidth) in the high latitude rows and generating those tiles with a compressed scale in the i dimension (see Figure 5). To allow this solution, the tile model must be extended to specify coalescence coefficients (c) that reduce the number of tiles in the width direction by aggregating c horizontal tiles but keeping the tileWidth (and tileHeight). The coalescence coefficient is not applied next to the Equator but is used in medium and high latitudes (the higher the latitude the larger the coefficient).

CDB1GlobalGrid The CDB1 Global Grid Tile Matrix Set defines tiles in the Equirectangular Plate Carrée projection (EPSG:4326 CRS) for the whole world, based on the level of details and zones defined by the OGC CDB 1.x Standards, which can be encoded following this standard with the use of variable widths. For the tile matrices with negative identifiers of the CDB1GlobalGrid, the tiles' geographic extents remain the same as those of tile matrix 0, but the tile size in cells is reduced. For the CDB1GlobalGrid, the polar adjustment zones corresponding to coalescence factors are the same (at a given latitude) for all tile matrices of the set.

Specifically, for the definitions and examples of a CDB1GlobalGrid, see:

Further, Annex E of 2DTMS includes definitions for TileMatrixSets utilizing the variable width capability. This capability allows for the coalescence of tiles in specific rows so that the overall width of the tile matrix is divided among fewer tiles. This is particularly well suited to define global grids in an Equirectangular Plate Carrée projection, where tiles closer to the pole cover a smaller physical area than tiles at the equator.

At each successive zoom level, each lower level tile is split into four new tiles at the next level of detail (zoom level). This subdivision can continue until the zoom level is high enough to accommodate the highest resolution data that is to be stored within a CDB X data store.

Annex G.2 of the 2DTMS Standard provides JSON and XML examples for the CDBGlobalGrid. Using the approach defined in Annexes E and G, one can define an arbitrary number of zoom levels. In the examples, 3 zoom levels are illustrated.

These are the JSON and XML definitions of the CDB1GlobalGrid tile matrix set (see CDB1GlobalGrid) that can be reproduced by other standards needing to define a tile matrix set. Not all TileMatrix elements need to be included and including other TileMatrices for more detailed scales is possible if they follow the same pattern.

The following figures depict the CDB 1.x zones, determining the coalescence coefficients, as well as the Levels of Detail, determining the tile matrices for the CDB1GlobalGrid.

The requirements specified in this Requirements Module are consistent with the guidance provided for the CDB1GlobalGrid as defined in Annexes E and G of the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard.

The OGC Two Dimensional Tile Matrix Set and Tileset Metadata (2DTMS) Standard defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids (tile matrices) defining a domain.

A key concept in 2DTMS that is relevant to tiling CDB data is variable width tile matrices. Many tiling schemes assume that the tile width is constant for all tile rows. This is common usage for projections that do not distort the Earth too much. However, when using Equirectangular Plate Carrée projection the distortion increases for tiles closer to the poles. In the extreme, the upper row of the upper tile (the one representing the North Pole) contains a list of repeated values that represents almost the same position in the space.

The solution consists of reducing the number of tiles (the matrixWidth property in the 2DTMS Standard) in the high latitude rows and generating those tiles with a compressed scale in the i dimension. To support this solution, the tile model must be extended to specify coalescence coefficients (c) that reduce the number of tiles in the width direction by aggregating c horizontal tiles but keeping the tileWidth (and tileHeight). The coalescence coefficient is not applied next to the Equator but is used in medium and high latitudes (the higher the latitude the larger the coefficient).

The latest revision of 2DTMS (see release notes) provides detailed description of variable width TileMatrixSets suitable for tiling CDB data stores, such as the GNOSIS Global Grid.

The CDB GNOSISGlbalGrid Tiling Extension Requirements Module is based on the GNOSISGlobalGrid as specified in the OGC TileMatrixSet registry, and documented in informative annexes of the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata[OGC 17-083r4] Standard (2022). Specifically, for the definitions and examples of a GNOSISGlobalGrid, see:

The GNOSISGlobalGrid Tile Matrix Set defines tiles in the Equirectangular Plate Carrée projection (EPSG:4326 CRS) for the whole world while still attempting to approximate equal area tiles, even near the poles, by leveraging the 2DTMS variable width capability supporting the coalescence of tiles in specific rows so that the overall width of the tile matrix is divided among fewer tiles.

This is particularly well suited to define global grids in an Equirectangular Plate Carrée projection, where tiles closer to the pole cover a smaller physical area than tiles at the equator.

Starting at the tile matrix with identifier 1, a variable matrix coalescence factor is applied for polar tiles to tend towards equal area.

Using the approach defined in Annexes E and G, one can define an arbitrary number of zoom levels if they follow the same pattern. In the examples, 3 zoom levels are illustrated.

Levels 0 to 28 are officially defined, reaching a 2:1 scale while the matrix, row and column identifiers can still fit together within a single 64-bit key.

This extension is easy to implement procedurally: It is a quad-tree starting with eight 90 x 90 degree tiles at level 0, with the exception that tiles touching a pole are split into 3 tiles rather than 4 —  the part of the tile touching the pole is not split longitude-wise. Therefore, there will always be only 4 tiles touching each pole.

Note: The GNOSIS Global Grid scales match the GoogleCRS84Quad Well Known Scale Set, but starts at the third scale of the set.

Note: Aside from the variable width considerations, the only other difference with the WorldCRS84Quad TileMatrixSet is the fact that the latter starts at the second scale of the WKSS — its TileMatrix identifier 1 is equivalent to the GNOSISGlobalGrid TileMatrix identifier 0.

The following figure depicts the tiling configuration for Level 2 of the GNOSISGlobalGrid as defined in this extension.

The requirements specified in this Requirements Module are consistent with the guidance provided for the GNOSIS Global Grid as defined in Annexes E and G of the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard.

The levels 0 to 5 are shown in 2DTMS Annex E.1. Unlike the CDBGlobalGrid, for the GNOSISGlobalGrid, the coalescence factors for the polar zones are re-adjusted at each tile matrix of the set. Levels 0 to 3 are shown on the following picture.

In CDB 1.x, the concepts of topology, geometry, and features are "mixed" together and not treated as separate abstract classes. In reality, topology can be defined as a graph with no geometry and no feature type designations. Therefore, in CDB 2.0 and later, the following note is relevant in understanding the topology requirements module:

Figure: Topology Class Diagram. Source: ISO 19107:2017

The following are key definitions used in the CDB Core Topology Requirements Module. These definitions are extracted from ISO 19107:2017.

direct position
Position described by a single set of coordinates within a coordinate reference system (CRS).

directed edge
Directed topological object that represents an association between an edge and one of its orientations.

Note 1 to entry: A directed edge that is in agreement with the orientation of the edge has a + orientation, otherwise, it has the opposite (–) orientation. Directed edge is used in topology to distinguish the right side (–) from the left side () of the same edge and the start node (–) and end node () of the same edge and in computational topology to represent these concepts.

directed face
Directed topological object that represents an association between a face and one of its orientations.

Note 1 to entry: The orientation of the directed edges that compose the exterior boundary of a directed face will appear positive from the direction of this vector; the orientation of a directed face that bounds a topological solid will point away from the topological solid. Adjacent solids would use different orientations for their shared boundary, consistent with the same sort of association between adjacent faces and their shared edges. directed faces are used in the coboundary relation to maintain the spatial association between face and edge.

directed node
Directed topological object that represents an association between a node and one of its orientations.

Note 1 to entry: Directed nodes are used in the coboundary relation to maintain the spatial association between edge and node. The orientation of a node is with respect to an edge, "+" for end node, "–" for start node. This is consistent with the vector notion of "result = end - start".

edge
1-dimensional topological primitive.

Note 1 to entry: The geometric realization of an edge is a curve. The boundary of an edge is the set of one or two nodes associated with the edge within a topological complex.

edge-node graph
Graph embedded within a topological complex composed of all of the edges and connected nodes within that complex.

Note 1 to entry: The edge-node graph is a subcomplex of the complex within which it is embedded.

end node
Node in the boundary of an edge that corresponds to the end point of that edge.

face
2-dimensional topological primitive.

Note 1 to entry: The geometric realization of a face is a surface. The boundary of a face is the set of directed edges within the same topological complex that are associated with the face via the boundary relations. These can be organized as rings (aka polygons).

interior Set of all direct positions that are on a geometric object but which are not on its boundary. In traditional GIS terminology, an interior is an island or hole contained within a polygon.

isolated node
Node not related to any edge. In traditional GIS, an isolated node with a direct position property is known as a point geometry.

start node
Node in the boundary of an edge that corresponds to the start point of that edge as a curve.

Figure: Example of Topology Primitives and related geometry elements.

In the above figure, the topological and related geometries are depicted. The tables are provided as examples of how the topological information could be organized. However, specific table organization is beyond the scope of the CDB Core Topology Module.

In the CDB 2.x context:

A node primitive is a 0 dimensional topological primitive. The node may have or not have additional properties such as height or depth and other attributes, such as a feature code or type. A node may or may not be connected to a network. An isolated node typically is a point feature with an associated coordinate (direct position). An example might be a lighthouse or fire hydrant. A node that has one or more associated edges is a directedNode and represents a node in a directed graph. A directed node differentiates between edges that start at the node and those adjacent edges that terminate at the node.

An edge is a one dimensional topological primitive defined by a set of linestring (curve) primitives that define the geometry connecting two nodes. A directedEdge begins at a start node and terminates at an end node. These start and end nodes are defined as directedNodes: The node is with respect to an edge, "+" for end node, "–" for start node. It is possible for two nodes to be connected with no geometry. An example is a straight line road segment between two road intersections. In this case, the line geometry is defined by the start and end nodes.

A face is a two dimensional topological primitive. The geometric realization of a face is a surface. The boundary of a face is the set of directed edges within the same topological complex that are associated to the face via the boundary relations. These can be organized as rings or as they are more traditionally known, polygons.

At the fundamental level, topology is an edge-node graph of primitive concepts with no geometry or attributes other than identifiers. Edge-node graphs are very useful in many applications. However, in the geospatial world the majority of topologically structured networks exist in relation to the surface of the earth and have geometries. The geometries specified for use in CDB 2.x are defined in the CDB Core Geometry Model Requirements Module.

Topology is represented as a graph. A "pure" topology graph does not have a coordinate system nor is there the concept of geometry or coordinates. The addition of spatial coordinates ties the graph to some coordinate system. For CDB all coordinates, bounding boxes, and so forth are expressed in the coordinate reference system as defined in the CDB Core CRS Requirements Module. The addition of coordinates to the model enables expressing nodes as points, edges as linestrings, and faces as polygons. The definition of any geometry in a CDB data store is defined in the CDB Core Geometry Requirements Module. While topology and geometry are useful in many applications, the majority of user facing GIS applications also have attributes associated with a geometry and may also have metadata. At this point, such entities are typically described as features.

The following table provides a terminology crosswalk between what is defined in the CDB 2.x Standard and what is defined in the Topology Clause of the CDB 1.x Standard. While there is not a one to one mapping, the concepts are closely aligned. The exception is the case for using Junction ID (JID) where the JID (node) is for relating two different feature types, such as a road intersecting a river. The other JID use case in 1.x is for a change of feature code within a network, such as a road changing from 2nd class to 3rd class. In 2.x, the case would just be a node primitive and not have a special ID.

The following specifies the set of requirements and recommendations that comprise the CDB Core Topology Requirements Module

Each of the core topology requirements is now described.

Faces are a two dimensional topological primitive that is generated by traversing a set of edges to generate an exterior boundary (aka polygon). Generation of faces is not required unless the application profile specifies the generation of polygon coverages as defined in ISO 19123:2005 - Schema for coverage geometry and functions. The Core Topology Requirements module does not specify winding order for the face. Further, this core module does not specify how topology traversal is accomplished nor how the face "tables" are structured. These are considerations for CDB Application Profiles and specific implementations.

The generation of faces is an optional requirements class. Traversal of the topology graph to form faces in order to create (when combined with geometry) polygons requires conformance to this class. Traversal of the graph to detect topological consistency errors does not require conformance to this class.

The following diagram is extracted from the 1984 Map Overlay and Statistical System Topology Implementation Study funded by the USGS. This diagram represents are fairly typical logical model for structuring topological relationships and content for use in a datastore. There are other similar examples from the late 1970’s through the 1980’s.

Any CDB datastore implementation needs to provide some mechanism for applying and tracking changes to the assets maintained in a CDB datastore.

A revision to a CDB datastore may include one to many changes to one or more assets in the datastore. These changes include modifications to geometry, attributes or both, updates to models, deletions, and additions and more. The set of changes is referred to as a versioning collection.

Need words on how to link the resource to additional information about the chnage to the asset, such as who did it and a description.

Any CDB implementation needs to support the traditional CRUD functions include adding, deleting, and updating assets in the datastore.

For update at a minimum a CDB implementation needs to support a file/table replacement mechanism. A CDB file replacement allows content in a CDB datastore to be easily updated. Examples are textures, models, or terrain datasets that have been updated and/or edited.

Quite often an asset in a CDB datastore will change state. For example, a road may be temporarily closed or a bridge damaged by a flood. These transitory events need to be reflected in a CDB datastore so that end user clients or simulators can use that information to modify a visualization, an analysis, or a simulation.

The following are the design principles for a CDB 2.0 and later tiling, levels of detail, and layering. These design principals were discussed and documented during Phase 1 discussions as well as during the experimentation. Again, for the purposes of expediting experimentation, GeoPackage was the choice for a standard container.

Metadata is data that provides information about other data. In the geospatial community and the rapidly emerging spatial web community, metadata is critical to operations such as discovery and determining whether a resource is “fit for purpose”. Three distinct types of metadata exist: descriptive metadata, structural metadata, and administrative metadata (National Information Standards Organization (NISO)).

The geospatial community has a long and extensive history in defining and using metadata for geospatial resources. Without metadata, discovery of required resources and determination of whether a resource is “Fit for Purpose” becomes difficult if not impossible. The geospatial community makes use of all three types of metadata, although the first and third are more critical. The CDB use of metadata focuses on use cases 1 and 3.

In Tier 2 of the architecture, specific implementable requirements are specified as part of the CDB Core. An example of implementable requirements are those that specifically describe the CDB Tiling structure. The Tiling structure in the CDB 1.x series of standards is well defined and widely implemented in the CDB community. However, the CDB tiling structure is not specifically tied to or consistent with international standards. Further, a number of issues have been documented over the years of CDB use. At the same time as recommended in the SOFWERX CDB Sprint, the CDB 2.0 tiling scheme must enable a "relatively" easy migration path from the CDB 1.1/1.2 tiling/LoD structure into the CDB 2.0 structure.

In this Tier, requirements related to specific categories of data content are specified. Many of the data content requirements specified in the current CDB 1.x Standards could be moved directly to CDB-X. Another characteristic of Tier 3 requirements is that they may or may not be in the core. This is because there is currently no requirement that a CDB data store implement any of the data content types detailed in the CDB 1.x Standard. An example is the current Volume 6: OGC CDB Rules for Encoding Data using OpenFlight

That said, there are also data content requirements that are specified in the Core. These are requirements for such elements as file naming. An example is provided below.

Another characteristic of the CDB 2.0 Tier 3 is the role of metadata. Unlike the current CDB 1.X Standard, there is no mandatory requirement for metadata at the data content storage level. In CDB 2.0, metadata is only recommended. In CDB 2.0, a minimal set of metadata is mandatory for any dataset in a CDB data store.