This section documents draft design objectives, the target use cases, and the CDB X Conceptual and Logical Models. This section is currently a work in progress.
|
Note
|
Some of the content in this section is paraphrased from the recently available USGIF/OGC paper, "Advancing the Interoperability of Geospatial Intelligence Tradecraft with 3D Modeling, Simulation and Game Engines." |
The following are summaries of key use cases identified during this project.
Tactical Use Case - CDB-T: Support tactical forces with CDB content for both planning and deployment. There is also the consideration of using the content on mobile devices for the Warfighter at the Edge. Possible impact: Define a profile of the foundation data in a form most suitable for tactical devices (CDB-T, where T is for tactical), such as ATAK. This is the CDB-T use case where "T" is for "Tactical".
Gaming Use Case - CDB-G: More and more gaming systems, such as Unity, are depending on "real" 2D and 3D geospatial content to add realism to their gaming systems. This is because gaming technology is supporting the visualization, content generation and hybrid-streaming of 3D geospatial data such as combining optimized performant content with dynamic geospatial events and condition. Possible impact: Define a derivative and optional structure of the foundation data in a form most suitable for gaming devices. This is the CDB-G use case where "G" is for "Gaming"
M&S Use Case - CDB-S: A CDB datastore needs to provide a modeled environment representation for distributed simulation applications. This representation needs to be currated, authoritative, and as up to date as possible. Possible impact: Define a porfile of the foundation data in a form most suitable for simulators. (CDB-S, where S is for simulators)
Analytics Use Case - CDB-A: Increasingly there is a need to access and use content available in a CDB datastore for analytics such as change detection, mobility analysis, and integration with other models. This leads to consideration of new approaches and methods for integrating 3D analytics with mission planning and mission rehearsal synthetic training environments such as the inclusion of ground-clutter in urban environments. Possible impact: Define a derivative and optional structure of the datasets in a form most suitable for analytics using AI/ML. This is termed CDB-A, where A is for analytics)
Data Transport Use Case <need short description> Possible impact: Optimize the speed data synchronization between all echelons and data systems for CDB-F and CDB-T
DDIL Deployment Use Case CDB-F, CDB-T, and CDB-A must be able to deploy in DDIL environments. Also see CDF-Tactical above
|
Note
|
Optimization For Use Cases: CDB-S, CDB-G and CDB-T may tile/generate LODs and derivative data types (assuming they are OGC and/or Khronos standards) in a manner to optimize efficiency and performance leveraging a small, finite set of tiling schemes (Profile should include Tiling structure, LOD structure, optimization, etc.) CDB-A may generate topology, extended attributes and derivative data types (assuming they are OGC and/or Khronos standards) in a manner to optimize efficiency and performance leveraging a small, finite set of relationship schemes |
This is future work and actually would not be part of a core CDB-X standard Configuration Management. Define an abstract mechanism for configuration management applicable to multiple deployment strategies (file systems, RDMS and cloud) relational databases for CDB-F, CDB-S, CDB-G, CDB-T and CDB-A. Support Versioning, attribution, synchronization
The following are the design goals and objectives for the development of CDB-X.
-
Be as performant as possible in terms of 1.) Speed of access and 2.) Impact on hardware resources.
-
Consider how to incorporate identified recommendations into the next minnor CDB revision (1.3) to
-
Enhance current capabilities,
-
Not break backwards compatibility,
-
Provide a more seamless migration path moving to CDB-X.
-
-
Geometry model: All geometry for any vector feature data shall be compliant with the OGC/ISO Simple Features Geometry Model.
-
Attribute model: CDB-X shall be consistent with the NAS/GGDM and harmonized as approporiate the current CDB attribution model.
-
CDB-X Standards Sructure: CDB-X should evolve the standard to a "Core" that specifies a set of requirements that all CDB extensions, profiles, and profiles with extensions shall conform to. Other characteristics of the Core are:
-
The core shall support the tiling of any layer as does the current CDB standard.
-
The core shall also specify that vector data does not need to be tiled.
-
The core shall support specification for LoDs.
-
The core shall be implementable in a file system (as today) or in a container technology such as GeoPackage.
-
The core shall be implementable in the cloud.
-
-
Any profiles based on the core shall have the following requirements:
-
Correlation Requirement: CDB-T, CDB-S, CDB-G and CDB-A profiles shall correlate to the data defined in CDB-F
-
Derivative and Optional structures: CDB-T, CDB-S, CDB-G and CDB-A profiles shall encode its rules and mechanisms for optimization in a self-describing form.
-
Holistic Foundation: CDB-T, CDB-S, CDB-G and CDB-A structures shall all be generated from the data defined in CDB-F
-
-
3D Graphics Models - CDB-X shall support additional model encoding beyond OpenFlight. glTF shall also be supported.
-
Metadata - CDB-X shall support mandatory and optional metadata elements including support for provenance. Any profiles shall clearly specify metadata elements/requirements for that profile.
-
The ability to version the contents of a CDB datastore is mandatory. The requirement is discussed in detail in the Versioning section of this ER.
The following section provides additional background on key concepts and/or overarcing requirements germane to the definition and development of a CDB-X Standard.
The Interoperability of software, workflows and data across the GEOINT and M&S communities is required to improve mission responsiveness by leveraging a growing diversity of geospatial information and just in time fusion of information from drones, body cameras, phones and other IoT sensors. Interoperability of all the formats, encodings, and models used in CDB-X will enhance the ability to discover, access, update, and use content in a CDB datastore to meet the needs of the use cases identifed above.
Foundation data are the authoritative data and models that have been curated per the rules defined in the CDB standard, and stored in a CDB repository. Foundation data utilizes known and consensus controlled vocabularies for attribution, has been curated based on the requirements as stated in the CDB standard, and the required metadata has been documented.
For example, as per the current CDB standard (and industry best practice), a road network (RoadNetwork dataset in CDB 1.2) could be considered as foundation data. In CDB 1.2, 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.
For example:
Requirement: The RoadNetwork shall be considered as a foundation data layer in a CDB repository.
Sub-requirement: All roads in a roads layer SHALL use a known road classification system to identify the roads type. This could be the US DoT classification, the current FACC classification, or the newer GDDM.
Sub-requirement: The RoadNetwork SHALL be topologically structured. (This enables network analysis etc). NOTE: The how is not specified at the logical model level.
Sub-requirements: The RoadNetwork Dataset SHALL be used to specify all of the road networks..
Notice that there is no mention of the actual storage structure, enabling software, storage formats, tiling and so forth.
