Below are the highlights of the proposed CDB 3.2 Draft Specification. We will be posting the full draft in the coming weeks, in time for review and discussion at the CDB User Group at I/ITSEC.

For CDB v3.2, there are 6 major themes

2DModels: Up to now, we only had terrain-related datasets (elevation,

imagery, material) and 3DModels. The new 2DModel Dataset is

specifically tailored to efficiently handle the modeled representation of

2DModels that must be conformed to the terrain surface. Examples of such

models include roads, runways, taxiways, surface markings and

contaminants. The 2DModel Dataset can also be used to model geo-typical

terrain, i.e. an overlay a mesh of 2D textured polygons overlaid onto the

terrain skin. The i2DModel Dataset is based on the OpenFlight file

format. This addendum describes how OpenFlight files can now be used to

model 2D surface features that must be conformed to the underlying

terrain skin:

a) Modeled representation of geo-typical and geo-specific 2D

lineal-features such as roads, runways and taxiways.

b) Modeled representation of geo-typical and geo-specific 2D

areal-features such as aprons, industrial parks, campground and farms.

While it was theoretically possible to very accurately model man-made

terrain-conformed features (such as roads, aprons, runways) using the

current Terrain Elevation and VSTI Datasets, the storage size of a CDB

could escalate rapidly as these datasets were implemented to large number

of levels-of-detail. Furthermore, the performance requirements of

client-devices also escalated rapidly if they are to access all of these

LODs in order to meet their simulation application requirements. This

addendum proposes a more economical approach (from a storage and

computational perspective) to the modeling of terrain-conformal features.

Today, the integration of terrain-surface conformed features into the

terrain skin has always been performed by the Synthetic Environment (SE)

content creation tools during an off-line SE compilation process (SECORE

did this). Modeler’s lay-down terrain surface conformal polygons that

provide the feature’s outline and texture. Unfortunately, this approach

does not allow for the independent management of terrain LODs and

modeled-feature LODs. Without these mechanisms, client-devices are

unable to smartly manage their computational load and as a result,

synthetic environments are typically compiled for the lowest common

denominator client-device within a simulation federation.

This addendum resolves these shortcomings. The proposed approach retains

independent datasets for both the terrain skin and the terrain-feature

2DModels; each dataset has its own LOD hierarchy so that client-devices

can access and independently manage both of the respective LOD

hierarchies. In addition, the proposed revision is designed to

facilitate the “integration” of such models onto the terrain skin at

runtime by re-visiting and clarifying the rules that guides the placement

of the models in the CDB LOD structures.

KEY FACTS TO REMEMBER:

• This addendum allows us to model highly-detailed roads without having

to brute-force terrain imagery down to centimeters.

• This addendum allows us to more readily convert legacy databases (ours

and competitors) which all used 2D modeled geometry to model roads.

• This addendum allows us to more readily convert legacy databases (ours

and competitors) which all used 2D modeled geometry to geo-typical

textured areas. (aka geo-typical terrain imagery databases)

• This addendum helps remove any doubts people may have as to CDB’s

suitability for land applications.

CDB Versioning: The versioning scheme of the CDB has been enhanced.

Prior to the v3.2, the versioning scheme allowed user’s to support

multiple versions of their database on a geocell by geocell basis;

however, the whole database had to be at a same CDB specification

version. Now, modelers not only can have multiple versions of a

geocell, and each version of the database is tied to a specific version

of the CDB Specification.

Sample Use-Case : User has v3.0 simulator and a v3.2 simulator.

Database is CDB v3.0 and is huge. Some geocells have been modeled in

multiple versions to reflect flooded and non-flooded terrain conditions.

User wishes the v3.2 simulator to take advantage of improved

functionality and performance in certain limited areas, but doesn’t the

time/money to convert the entire database. Also, user wishes to support

his v3.0 simulator and to perform joint (correlated) mission using both

simulators. With CDB v3.2, the user only needs to upgrade a few

geo-cells (say target areas) to CDB 3.2 to take advantage of new

functionality and performance. He does so, by adding another version of

the affected geo-cell and tagging them to CDB v3.2. The rest of the

database remains unchanged. When he loads his v3.0 simulator with the

CDB, everything is the same as before, ie. the v3.0 simulator loads only

v3.0 geocells and ignores geocell versions that are tagged with CDB v3.2.

In the case of the v3.2 simulator, he can also choose to load only CDB

v3.0 geocells versions (to maintain absolute correlation with the other

simulator); alternately, he can configure the simulator to ignore CDB

v3.0 geocells when they are superseded by CDB v3.2 geocell versions.

Tunnels/Wells: Prior versions of the CDB made provisions for the

modeling of tunnels/wells through a subordinate elevation dataset; while

the additional layers of altimetry handled the geometry of such

structure, there were no means to apply/control texture and materials.

In CDB v3.2, all underground models, eg. tunnels, wells, building

interior basements, etc. are handled as 3DModels. The entrance to

such structures is now handled as a “Cut-out”. A Model Cut-Out Zone

represents clipping geometry that is used to “cut-out” the terrain skin

from a 3DModel. The Model Cut-Out geometry defines a simple 3D convex

volume (open or closed). A typical implementation of a Model Cut-Out

Zone for a modeled building would consist of a simple cube. Similarly,

the Model Cut-Out Zone for a tunnel entrance would consist of a simple

cylinder.

CDB Gamma: It is now possible to associate a different gamma value (the

brightness response curve) with every version of a geocell of a CDB.

Note, that in the past, the brightness response curve dictated by the CDB

specification was fixed and global to an entire CDB. This implied that

everybody had to handle gamma correctly (per spec) so that the rendered

CDB content would look the same on any simulator, on any SE tools

workstation, etc. In practice however, there is always somebody in

the SE pipeline (both offline and runtime) that screws-up the

interpretation of gamma. Within a company, there may be a screwed-up

in the gamma process, but people (usually modelers) quickly compensate;

people may not even realize that the gamma is screwed up because the

content is always viewed on the same device(s). In the case of CDB, a

CDB may be used by others, and the handling of gamma may be different

than that implemented by the originator of the CDB database. With the new

capability, it is possible to simply tag the geocell with a revised gamma

value, thereby instructing the client-device to use a revised brightness

response curve. This is a use-case that is important to Earl Miller.

He has in the past “screwed-up” gamma, and without this addendum, he

would have to reprocess the colour/brightness of every single terrain

texture. With the new addendum, he need only tag each geo-cell with a

revised gamma value; this takes a fraction of the time compared to

reprocessing each terrain texture.

Material Composite Tables: This addendum provides a more compact and

efficient way to store these tables.

2DModels: How does this data set correlate with or replace the equivalent vector data sets? Can attributes from those vector data sets (like APID, RWID, RXID, GAID, APFN, etc.) be applied to these OpenFlight features?

Tunnels/Wells: Please make sure this addendum clearly defines and separates the meanings and use cases for "Model Cut-Out Zones" and "Cultural Footprints".

CDB Gamma: Would this per geocell gamma also apply to geo-specific and geo-specified (aka geo-typical) model texture as well? If not, how can gamma for these data sets be specified? Also, consider the case of "site models" needing to match geo-specific texture. We have seen databases produced by SOFPREP where this is a concern.

Material Composite Tables: From this description, I can't tell if this addendum is meant to address this proposal: Raster Material Mixture layer compression, or this issue: Composite Material Tables in Model Descriptors for (geo-typical) 3D Models with Material Textures is problematic, or both.

Please note the following other issues that remain open:

APFN String Length Limitation Exceeded (Also, an APFN for Runway Aim Point Markings (AC Section 2 10, AIM 2-3-3.d) is still missing)

Extended Attribution Scheme Significantly Increases Database Size

Lightpoint phase offset (LPH) not available in 3D models

FAA Obstruction Light Types Needed

Runway Contaminant Material Texture

Skin, Configuration, and Damage State for Moving Model Location Features

Moving Model Vehicle Numbers

Hi Brian

Regarding your questions on upcoming CDB v3.2

2DModels: How does this data set correlate with or replace the equivalent vector data sets? Can attributes from those vector data sets (like APID, RWID, RXID, GAID, APFN, etc.) be applied to these OpenFlight features?

ANSWER: CDB v3.2 re-enforces a clearer distinction between features and models. This is particularly true of the new i2DModels and i3DModels. The features will be there primarily for their semantic value, while the models will be there for geometry and rendering purposes. The two will coexist and each addresses specific needs. Many of the feature attributes will be applicable to Openflight models. Our current plan is to support the following in OpenFlight: APID, CEAI, FACC, FSC, GAID GEAI MODL, MMDC, RTAI RWID and TXID.

Tunnels/Wells: Please make sure this addendum clearly defines and separates the meanings and use cases for “Model Cut-Out Zones” and “Cultural Footprints”.

ANSWER: Yes, this has been done.

CDB Gamma: Would this per geocell gamma also apply to geo-specific and geo-specified (aka geo-typical) model texture as well? If not, how can gamma for these data sets be specified? Also, consider the case of “site models” needing to match geo-specific texture. We have seen databases produced by SOFPREP where this is a concern.

ANSWER: Previous versions of the CDB fixed the gamma of all imagery / textures to 1.0. This could be onerous when large amounts of imagery/textures were not CDB-compliant. In the roposed approach

users can now override the gamma in the “Defaults.xml” metadata file. There is a separate gamma override value for each of tiled datasets (VSTI, GSModels, i2DModels, i3DModels). Note that each version of the CDB has its own “Defaults.xml”.... and since each version has an geographic extent, gamma would now be distinct by region

Material Composite Tables: From this description, I can’t tell if this addendum is meant to address this proposal: Raster Material Mixture layer compression, or this issue: Composite Material Tables in Model Descriptors for (geo-typical) 3D Models with Material Textures is problematic, or both.

ANSWER: We are introducing a global Composite Material Table, the GCMT, that can be used in conjunction with all models (except MModels which has its own.) We are also introducing a local, per geocell, Composite Material Table, the GSCMT. This approach will reduce the number of CMTs and the replication of similar entries across the CMTs.

APFN string Length Limitation: ANSWER: Airport Point, Lineal and Areal Feature components have been eliminated, in favour of i2DModel dataset. As mentionned above, CDB v3.2 re-enforces a clearer distinction between features and models. In CDB v3.1, Airport Point, Lineal and Areal Feature components attempted to "model" such features by using Shapefile shapes and named Feature components. The problem with the approach was that Shapefile lacked sufficient capabilities to fully and unambiguously model airport features. As a result, we have opted for i2DModels, which are full fledged OpenFlight models (with zero height) that are surface-conformed to the underlying terrain. We have also added 35 additional FACCs, based on the DO-272B standard. These FACCs can be attributed to both features and i2DModels.

Extended Attribution Scheme: Significantly Increases Database Size

ANSWER: Yes we agree. Bear in mind that the use of such extended attribution falls outside the spec, ie. its use is non-standard and client-device behavior is not specified.

FAA Obstruction Light Types Needed:

ANSWER: All of the lights you suggested have been incorporated into the CDB FDD

Runway Contaminant Material Texture:ANSWER: The new i2DModels have a set of standardized contaminant textures, which can be invoked by a distinct texture component selector.

001 *.rgb i2DModel Contaminant - Wet

002 *.rgb i2DModel Contaminant - Patchy Wet

003 *.rgb i2DModel Contaminant - Snow

004 *.rgb i2DModel Contaminant - Patchy Snow

005 *.rgb i2DModel Contaminant - Ice

006 *.rgb i2DModel Contaminant - Patchy Ice

007 *.rgb i2DModel Contaminant - Slush

008 *.rgb i2DModel Contaminant - Patchy Slush

009 *.rgb i2DModel Contaminant - Skid Marks

010 *.rgb i2DModel Contaminant – Wet Skid Marks

011 *.rgb i2DModel Contaminant - Sand

012 *.rgb i2DModel Contaminant - Patchy Sand

013 *.rgb i2DModel Contaminant - Dust

014 *.rgb i2DModel Contaminant - Patchy Dust

015 *.rgb i2DModel Contaminant - Volcanic Ash

016 *.rgb i2DModel Contaminant - Patchy Volcanic Ash

Skin, Configuration, and Damage State for Moving Model Location FeaturesANSWER: We will look into enhancing the CDB data model to support this capability.

Moving Model Vehicle Numbers ANSER: We will look into enhancing the CDB data model to support this capability.

So from reading the CDB 3.2 bullet list above, I have some questions. If we had the actual spec, some of these questions would be answered, or not even make sense, but I have to ask them until we see the a draft of the spec.

2D Models: I still don't understand the distinction between models and features. Does this mean that the GeoTypical models are placed with the new i2DModels and i3DModels datasets, or can they be placed using the GeoSpecified vector features? Also, can we get support in OpenFlight for LPH (light phase, for animated [approach] lights) and VEAI (Vendor extended attributes, since CEAI and GEAI are present)? Can we get something better than number of bytes to calculate the potential IG load for these datasets?

CDB Gamma: Is there a gamma on the GeoTypical model textures? Is there still a GeoTypical model library?

Composite Material Tables: I like that we are coalescing these into fewer tables. Does this apply to the Raster Material Descriptor files?

Extended Attribution Scheme: I don't mind the extended attributes. My biggest concern is the movement of attributes useful to an RTP (in CDB 3.0) from a class-level attribute into extended. Just because an attribute didn't seem useful to Presagis or CAE, it doesn't mean that an RTP might not have a need for it. From the CDB 3.1 spec, things like CMIX and SCALx/SCALy/SCALz are preferred to be in the extended attribution, it seems like an RTP would need to read these. Also, stuff like the bounding box information ensure that the extended attribute file will be quite large.

APFN string Length Limitation: So if I read this correctly, the 35 new FACCs that are being added will completely cover all the old APFN attribute values? Does it contain Runway Aim Point Markings (AC Section 2 10, AIM 2-3-3.d)?

We would love to see a draft of the spec sometime, to see actual implementation details. I understand that it can change between now and release, but something is better than nothing. Thanks,

Ryan

Brian, Ryan, a draft of CDB 3.2 is available for download here.

Bernard