This Engineering Report (ER) documents the results and recommendations of the rapid prototyping activites conducted during the 3D Geospatial Series Tech Sprint II - OGC CDB 2.0 (aka CDB X). This activity was performed in support of Special Operations Forces (SOF) Future Concepts. This effort hopes to accelerate evolution of the OGC CDB standard to meet the needs of planning, rehearsal, and Mission Command systems providing decision support to Special Operations Forces and enabling SOF tactical and operational advantage. OGC industry standards enable interoperability of geospatial data across systems and applications that SOF Operators and analysts use across warfighting functions.
Short summary of CDB X goal: Meeting the requirements for tactical GEOINT that can be used across warfighting functions.
Beginning in 2018 the CDB community has discussed and considered what CDB version 2.0 might might provide in terms of capabilities. These discussion also touched on architecture and related logical models. Many of the CDB 2.0 discussion occurred as part of the OGC standards work. More recently, other organizations such as SOCOM and NGA, have vigorously engaged in these discussions. However, progress has been relatively slow.
Therefore, in order to accelerate the development of CDB 2.0, in May 2020 SOFWERX announced the 3D Geospatial Series Tech Sprint II – OGC CDB 2.0. In support of SOF Future Concepts, this effort hopes to accelerate evolution of the OGC CDB standard to meet the needs of planning, rehearsal, and Mission Command systems providing decision support to Special Operations Forces and enabling SOF tactical and operational advantage. Additionally, a requirement to better align aspects of the CDB standard with the One World Terrain activity was expressed during the initial workshop.
The CBD Tech Sprint was comprised of five (5) key work phases:
Phase 1: 22 June 2020 to 26 June 2020 Virtual Concept Development: In a series of virtual workshop conferences, participants discussed CDB 2.0 requirements and design objectives with a focus on defining conceptual and logical models for the CDB 2.0 standard. The discussion focused on five key topics: Attribution, 3D Models, Vector Data/GeoPackage, Coverage Tiling (and LoDs and general tiling), and Top Level Metadata. This models and related topics discussions served as the basis for technical experimentation in Phase 2.
Phase 2: 06 July 2020 to 31 July 2020 Virtual Tech Sprint: Participants, and/or their organizations, will provide prototype implementations of the conceptual model documented in Phase 1. Through technical integration experimentation, the model will be updated and refined.
Phase 3: 03 August 2020 to 28 August 2020 Engineering Report (ER): Participants will complete the project Engineering Report detailing the conceptual model and results of the technical integration experiments.
Phase 4: 07 September 2020 to 25 September 2020 Proposed Draft Specification: Participants will create a proposed draft specification for “CDB 2.0” based on work in the previous phases, to be submitted to the appropriate working groups within OGC, Khronos, and/or SISO.
|
Note
|
Once the experimentation activities started, the participants in concert with SOFWERX and SOCOM determined that writing a draft specification was beyond the scope of this project. Instead, the focus increased on the experiments and prototyping to provide key recommendations to be communicated in this ER and submitted to the OGC CDB Standards Working group (SWG) to provide the foundation for the actual standards development work. |
Phase 5: 05 October 2020 to 5 November 2020 Final Report: Participants will write a final report summarizing activities to date, recommendations for the OGC SWG and other standards bodies to consider, and contributions of each participant.
In order to accomplish the target deliverables of this activity, the participants, based on their expertize, were allocated to five focus groups:
-
3D Subgroup
-
Attribution Subgroup
-
Coverages/Tiling Subgroup
-
Vectors in GeoPackage Subgroup
-
Metadata Subgroup
These teams focused on specific experiments and prototyping tasks to test key design concepts for inclusion in CDB-X. The results are documented in this ER.
|
Note
|
The CDB X Design Goals, Use Cases, and Conceptual/Logical Models chapter in this ER provides additional requirements and recommendations. These are phrased as general design goals based on group discussions, design threads in the recommendations below, and discussions in the OGC CDB Standards Working Group. |
The following are the key recommendations for changes, enhancements, and design principals for not just CDB-X but also CDB version 1.3. The version 1.3 changes are viewed as important enhancement that resolve both existing user specified needs as well as helping to provide a transition path for the future major CDB version. The following are the major recommendations. A complete summary of all Attribution recommendations can be found in Annex A.
|
Note
|
A key requirement for a CDB datastore is the ability to version content. This requirement was not addressed in any of the Subgroup experiments. However, all the Sprint participants agreed that version management is a critical requirement for CDB-X. The CDB Versioning, old and new chapter of this ER provides details. |
|
Note
|
A recurring discussion topic during the Sprint was a desire to better align the CDB Standard with the ongoing One World Terrain activity. This was a major determining factor in how the Attribution experiments and the use of GGDM were structured. This desire also helped direct the work of the 3D Modeling experiments. These experiments were successful. |
The following are the recommendations from the 3D Models and other 3D Content Subgroup.
Recommendation 1: The 3D model group recommends that a new CDB standard adopts the latest version of OpenFlight, leveraging the extended materials, hot spots and other important constructs it brings.
Recommendation 2: Complete the EXT_CDB draft glTF extension that adds required CDB simulation capabilities identified as missing from glTF. The new (and prototype) extension defines CDB-specific constructs such as points, zones, lights, light maps, and extended texture types.
Recommendation 3: Consider possible standalone glTF extensions for:
-
Coordinate Reference System: Shared interest with One World Terrain and possibly wider glTF ecosystem.
-
Switch nodes: Shared interest with One World Terrain moving models format. Note: Node switching is supported in the I3S Community standard.
-
External references: Some interest in wider glTF ecosystem, but many unresolved implementation details.
Recommendation 4: Leverage existing glTF extensions:
-
Articulations: This extension adds articulations, attach points, and related metadata to the glTF model (see AGI_articulations).
-
Metadata: Consider the EXT_feature_metadata extension. This extension is for storing metadata at different levels of granularity including per-mesh, per-face, per-vertex, and per-texel. This could be a good candidate for CDB model attributes and material map textures.
Recommendation 5: Consider a Model indexing file that includes the following: Model LODs, Interior and exteriors, Navigation and collision mesh
Recommendation 6: To reduce the current number of files in CDB 1.x, a recommendation is to group each model data into a zip (all LODs, textures etc…) while keeping the xml (index file) separate. A quick access to the index file would allow identifying what is required to be loaded into each ZIP. 9See Recommendation 5). This is a possible CDB 1.3 enhancement.
The following are the major recommendations from the Attribution Subgroup. Each of the major recommendations contain multiple "minor" recommendations that result from considering the implication of the major recommendation. The complete list of major/minor recommendations for Attribution are found in both the Attribution section and Annex A.
Recommendation 1: The subgroup recommends extending the current CDB XML metadata to add the NAS metamodel capabilities that are currently not supported.
Recommendation 2 and design goal: The CDB core conceptual model should not mandate any particular data dictionary or content, but rather provide the conceptual and logical metamodel for describing any ISO 19109 compliant application schema to the maximum extent practical. There should be no technical reason why one could not develop an extension profile for CDB for any particular data dictionary that complies with ISO 19109.
Recommendation 3: Adopt NAS-compliant logical entity-attribute model for CDB X with extensions for CDB use cases.
Recommendation 4: Delegate entity and attribute physical encoding choices to vector and 3D model containers instead of specifying globally.
Recommendation 5: Define backward-compatible extensions in CDB 1.3 to add constructs necessary to move toward NAS-compliant attribution
The following are recommendations for possible inclusion in CDB version 1.3.
Version 1.3 Recommendation - Extended Attributes The subgroup discussion on this topic is titled: Should Extended Attributes be preserved at the logical data model level? The suggestion is that the CDB SWG discuss this issue and possible solution as a possible change for CDB version 1.3. Some additional testing may be required to determine if this capability can be added to version 1.3 or not.
Version 1.3 Recommendation - Attribute default values: The subgroup discussion on this topic is titled: Attribute Default Values #32. The recommendation is that Defaults.xml can be used to define global attribute defaults as well as per-dataset defaults. Doing per-entity defaults would be a straight forward extension that could be proposed for CDB 1.3 as a transition path. The subgroup suggests that the CDB SWG discussion this for possible inclusion in version 1.3. A change request for this approach to specifying default values is also suggested.
Version 1.3 Recommendation - Attribute Terms The subgroup discussion on this topic is titled: Capture Attribute Terms (Enumerants) in Metadata #31. Attributes describing qualitative values are present in CDB 1.2 and the list of valid values for each attribute are documented in the human-readable specification with both the vocabulary term name and its integer numeric value (index). However, the machine-readable XML metadata does not contain any of this information and treats these attribute types as raw integers with only a minimum and maximum value constraint. It may make sense as a transition path to update CDB 1.3 to define additional XML elements in a backward compatible way to capture these definitions from the existing specification into the machine-readable XML metadata. The conceptual model in the CDB 1.2 specification does align with how GGDM treats such attributes, so there is no fundamental incompatibility, and the proposed CDB X dictionary design accounts for properly tracking the terms for qualitative attributes in a machine-readable way in SQLite.
The following are the recommendations from the Coverages/Tiling Subgroup.
Recommendation 1: Any tiling schemes specified in a CDB X data store (repository) SHALL be based on and consistent with the: OGC Core Tiling Conceptual and Logical Models for 2D Euclidean Space (19-014r3) and OGC Two Dimensional Tile Matrix Set Standard (17-083r2)
Recommendation 2: LoD Grouping - For users at the edge and smaller areas, that all the CDB-X coverage layers be present within a single GeoPackage container.
Recommendation 3: LoD Grouping - For Modeling and Simulation uses as well as data repository cases, that a series of GeoPackage containers be used to store CDB X coverage layers.
Recommendation 4: Define the capability for splitting GeoPackages based on a specific tiling scheme outside of the CDB X standard so that this split content can be used by itself as a component of other non-CDB based applications.
Recommendation 5: Use the proposed cdb.json index of packages and data layers. This would allow defining the description of the packages and LOD grouping outside of the CDB-XX standard so that description can be used elsewhere as well.
Recommendation 6: Elevation min-max - Move the minimum and maximum elevation values for the gridded elevation coverage contained in a tile to the tile metadata.
Recommendation 7: Image Compression - That loss-less and lossy image compression solutions be explored for use in CDB-X. Any such solutions are not viewed as a replacement for JPEG 2000 but instead as alternatives.
Recommendation 8: Materials - CDB-X needs to support material data to provide the same functionality as CDB 1.x. To also reduce the number of files, this can be accomplished by putting all the raster material data (including material table) in a single CDB data layer in GeoPackage, perhaps using the GeoPackage Related Tables Extension.
Recommendation 9: Although the use of non-tiled vector data layers (e.g. storing the geometry as WKB in GeoPackage features tables) should also be specified in the CDB Standard, the use of a tiled vector data extension should also be allowed. In particular, tiling vector data is essential for dealing with features spanning a very large geospatial extent, such as coastlines.
Recommendation 10: GeoPackage. The imagery in these GeoPackages is lossy. Therefore, allow the use of JPEG-2000 and/or additional lossless formats more compact than PNG in GeoPackages. This should be submitted as a change request to the GeoPackage Standards Working Group.
Recommendation note: Supporting more than one tiling scheme in a version of CDB is not recommended. The choice of the tiling scheme is foundational to how data layers are processed and stored and accessed.
The Metadata chapter in this ER provides the following guidance and recommendations:
Recommendation 1: All Sprint participants agreed that metadata including provenance is a critical requirement for the CDB-X Standard. They also agreed that some elements should be mandatory.
Recommendation 2: Metadata and provenance content should be self-describing.
Recommendation 3: Keep the core set of mandatory metadata elements limited and simple. Collecting and maintaining metadata can be costly – unless workflows are designed to capture metadata as part of the production process.
Recommendation 4: Define an extensible CDB metadata model that allows for easily incorporating additional metadata elements for specific data types, domains or applications. A good example would be the metadata required to make SWIR and NIR in a CDB data store useful by discovery, access, processing, and visualization services for those data types.
Recommendation 5: Discuss and agree on element names for the mandatory elements. This is because each metadata standard names elements differently. This also suggests that a metadata element crosswalk document may be required. The beginnings of such a document were developed as part of the CDB 1.1 revision work.
Recommendation 6: Every CDB dataset should have its own metadata that describes the content of that specific dataset. This will allow for much more flexible extensibility of new data types, enhances the value of existing datasets and enhances discoverability.
Recommendation 7: Consider whether the GeoPackage Metadata extension is robust and flexible enough to meet CDB-X requirements.
The following are the key recommendations from the Vectors in GeoPackage Subgroup>>.
Recommendation 1: Storing large numbers of feature data in single GeoPackage containers and retrieving that data by applying spatial and attribution filters that correspond with typical CDB access patterns appears to be practical. Therefore, the CDB-X core standard should specify requirements that support storing all vector data in a single GeoPackage.
Recommendation 2: Spatial filters appear to easily mimic the existing CDB tiling scheme. Therefore, the CDB-X core standard should specify requirements that support the ability to 1.) Specify such filters and 2.) Provide highly performant queries.
Recommendation 3: Storing ‘significant size’ on model instancing point features can significantly improve the model retrieval scheme, rather than storing models in the significant size related folder scheme. Storing and evaluating significant size on instancing points can make visual content and performance tuning much more practical.
All questions regarding this document should be directed to the editor or the contributors:
Contacts
| Name | Organization | Role |
|---|---|---|
David Graham |
Eaglecapsystems |
Editor |
Carl Reed, PhD |
Carl Reed & Associates |
Editor |
Kevin Bentley |
Cognitics |
Contributor |
Holly Black |
CAE |
Contributor |
Hermann Bressard |
Presagis |
Contributor |
Patrick Cozzi |
CESIUM |
Contributor |
Brian Ford |
FlightSafety |
Contributor |
Ryan Franz |
FlightSafety |
Contributor |
Jay Freeman |
CAE |
Contributor |
Jérôme Jacovella-St-Louis |
Ecere |
Contributor |
Michala Hill |
Cognitics |
Facilitator/Contributor |
Greg Peele |
Geometric Progress |
Contributor |
Vaughn Whisker |
ARL PSU |
Contributor |
Tracey Birch |
CloudLake/USSOCOM SOF AT&L |
Emeritus |