[Requests] comments on CDB candidate standard

JUTTEAU Christian christian.jutteau at thalesgroup.com
Thu May 26 16:13:20 EDT 2016


Please find enclosed Thales Training Simulation comments on CDB candidate standard.

Best regards,

Christian


PART A


1.      Evaluator:

2.      Christian JUTTEAU, Thales Training Simulation Australia/UK/France

christian.jutteau at thalesgroup.com<mailto:Volker.coors at hft-stuttgart.de>



3.      Submission: OGC 15-113: Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure


PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
CDB has been developed by CAE and Presagis (100% owned by CAE) only, with no other industrial partner contribution. Therefore, the data model is very much oriented and optimized for a use by CAE systems. Up to now, only CAE uses systematically CDB for their projects and programs, which explains the number of cited countries in the references. FSI, Rockwell-Collins or LMIS have used CDB for some US/UK DOD programs because it was a requirement. If CDB is a good conceptual idea, the way how it has been implemented doesn't comply anymore with 2016 technical standards.

PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
CDB has been designed for Modeling & Simulation training industry. Therefore CDB is not a technical standard for the geo-spatial industry, even if technical links exist between the two worlds


PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
SISO (Simulation Interoperability Standards Organization) is supposed to manage the standards for training Industry. CAE proposed CDB at SISO first as a shared specification and then withdrew it to be processed through OGC as a best practice. The fact that CDB is public is excellent, but it would sound more logical to submit to SISO first


PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
As it doesn't rely on up-to-date formats and data structures, and is not flexible at all, CDB doesn't favor innovation. CDB is behind what alternate visual technologies can provide (e.g. "point cloud" instead of polygons, ...)




PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
CDB has been designed for Air applications (commercial aircrafts, fast jets, helicopters) but is not suited for ground warfare applications, because of the terrain database complexity which is unmanageable through CDB structure (numerous buildings, streets, pavements with kerbs, ...




PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
CDB is based on old-fashioned formats (Shapefile, Open Flight, RGB, ...) which are not necessarily opened. On the other hand, Open Street Map is not supported while it is very commonly used.




PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
CDB structure relies on a huge collection of files while it should be managed with POST-GIS tables (Postgres SQL DBMS). Therefore, the coverage/accuracy of a given area are limited by file system capabilities. All levels of detail on imagery and terrain are kept in the CDB data which makes version control and distribution of large datasets more time consuming.




PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
Cartography requirements such as symbology are not managed by CDB




PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
Independent layers at raw data level are no more once in CDB structure. Imagery content is linked to the 3D representation (TTS has produced CDB for CAE IG, for which "baking" the image of the 3D airport in the imagery was required, making the imagery depending on 3D model.There is a strong dependency between GTModelInteriorGeometry and GTModelGeometry as they have to be perfectly correlated. Splitting models into those two dataset is completely specific to CDB and not representative of usual practices.).






PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
Recovering source data from a CDB database is complex and doesn't guarantee its completenes. For example, we could miss multi-texturing uv for apron light illumination, detail texture, animation, procedural position of vegetation or runway contaminations




PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
Moreover, from a shared training Industry point of view, CDB specification specifically warns against procedural improvement of terrain features, because it (obviously) breaks correlation. Procedural improvement means adding additional terrain fidelity that may not exist in the source data, for example improving ground clutter, adding detailed folds in the ground or adding traffic lights or road barriers. CDB (and any other mandated run-time terrain format) limits the ability of engine developers to innovate in their representation of terrain. For example, if CDB doesn't support definition for destructible tunnels, then the format either needs to be customized for the specific run-time (breaking the standard) or the standard has to be updated and this won't happen quickly




PART B


1.      Requirement: general

2.      Implementation Specification Section number: CDB Specification Volume 1 § 5.7.1

3.      Criticality: major

4.      Comments/justifications for changes:
Present CDB doesn't comply with Shapefile specifications (Features attributes are supported through shapefile with two dbf rather than one




PART B


1.      Requirement: general

2.      Implementation Specification Section number: CDB Specification p359, § 6.5.1

3.      Criticality: major

4.      Comments/justifications for changes:
OpenFlight format is not a standard as such, and some comments attributes have been assigned to a given meaning specific to CDB (For example, Model zones is encoded in the comments)


PART B


1.      Requirement: general

2.      Implementation Specification Section number: General

3.      Criticality: major

4.      Comments/justifications for changes:
Rather than looking for a universal 3D terrain format (for a real-time use or not), the future is certainly to use a complete "real 3D geographical format" at a source level which allowed to share, exchange, update and extend 3D terrain source data for various applications (e.g. Visual, tactical simulation, Cartographic display, geographic applications).In conclusion, a better solution would be to manage source at true GIS and Gaming format level to allow models and geospatial data to be updated or supplied from any number of sources.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160526/6152168a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: THALES Comments_CDB.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 25014 bytes
Desc: THALES Comments_CDB.docx
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160526/6152168a/attachment-0001.docx>


More information about the Requests mailing list