The following comments pertain to how I understand the CDB 3.0 specification and typical run-time publisher behaviors. I do not yet have much experience with TerraVista 6.0 CDB usage or database output, however.
Roads & railroads
I have added vector data for roads and railroads. In the final CDB output these are also represented as linear features in the shapefile. But does this mean that I can not assign a texture to the roads anymore that makes them look like a typical European road?
What do you mean by also represented?
In order to model a texture under the CDB 3.0 specification, you must use an OpenFlight model as described in section 5.3.1.4 Explicitly Modeled Representations. This is optional for lineal features as described in section 5.3.1.4.2 Referenced by Lineal Features.
The obvious problem with this method is how to make a static OpenFlight road or railroad model that properly integrates with the run-time published terrain. A set of diced point features, containing skirted raised road beds, possibly marked with footprint attributes as described by CDB 3.1 Specification Addendum - 3D Model - part 2, appears to be your only problematic option. I believe the wording of the latter addendum needs to more precisely define the expected RTP behavior, though.
Vector features that do not use the optional MODL Shapefile attribute to refer to an explicit OpenFlight model are described by section 5.3.1.5 Implicitly Modeled Representations. The RTP treatment of these features is entirely undefined, and may result in anything from a sophisticated procedural representation that takes into account the regional characteristics you desire, to completely ignoring the features. There is currently no way for the creator of a CDB database to convey their intent when specifying a particular vector feature; they can only convey its existence. Requesting specific RTP behavior for particular vector feature classes can only be accomplished through RTP specific configuration, if at all :-(.
In my opinion, this is an area of CDB that needs significant improvement, and I have been lobbying for this improvement since CDB 2.1; so far, without much success.
Airport layout
For constructing airport layouts we normally use shapefiles to define the aprons, taxiways, markings, etc. For CDB I could give those features the proper FACC attributes, but to me it seams that approach will not give enough flexibility. For example when constructing markings with different colours on the aprons. Or does the CDB approach assume that an airport is build as a 3D model using an OpenFlight file and only then imported into the CDB?
I agree, CDB 3.0's set of defined attributions for airport areal and lineal features is inadequate for many flight simulation training needs. For a discussion of some of these issues, please refer to this forum thread: CDB 3.1 Addendum - Attributions. I am still eagerly awaiting the proposed addendum for how to use a "small OpenFlight model" to accomplish may of these goals.
Currently, CDB 3.0 specifically forbids any explicitly modeled representation (OpenFlight model) of an areal feature as described in section 5.3.1.4.3 Referenced by Areal Features. The TerraVista 6.0 example database, however, uses a man made point feature with skirts (AKA "site model") to represent the Camp Pendleton, California (KNFG) airport. (Actually, it redundantly specifies the point feature many times, but that may be a TerraVista bug). As such, you are currently subject to varying RTP procedural representations (including nothing but geo-specific texture in many cases ;-) of airport areal and other vector features.
During past CDB user group forums, specifically one at I/ITSEC 2008, Presagis floated a proposal for amending the CDB specification to formally support this airport "site model" technique in the interest of leveraging existing OpenFlight centric airport libraries when migrating to CDB. Unfortunately, they have yet to formally define their usage, especially with respect to reconciling redundant information created by overlapping OpenFlight model and airport vector datasets, as well lost attribution due to non-overlapping airport vector and Openflight model attributions. The off-the-cuff response to the former was to use the footprint attribute to define the region to be replaced, if I recall correctly. I don't recall any such response to the latter issue, however.
Generic buildings
To populate cities in the database we often make use of the generic buildings in TerraVista which are extruded based on the footprints provided as areal features. To fit this in the CDB approach would that mean that TerraVista would make all those 3D models and they are put as 3D OpenFlight models in the CDB or does the CDB also allow them to be defined as footprint, where the RTP does the extrusion?
To represent this type of feature in a CDB compliant, RTP independent manner, TerraVista would have to create either geo-specific, or geo-typical, man made OpenFlight point feature models for each unique extrusion. Conceptually, I believe this is equivalent to how TerraVista treats other output formats. As previously discussed however, it is undefined, but allowed by the CDB specification for a particular RTP (possibly elaborately configured for each building vector feature class) to accomplish the equivalent (or better ;-) result.
The other not yet mentioned down side to RTP specific procedural vector data interpretation is the obvious correlation problems introduced due to subtly different, or entirely missing, features. This invalidates the Common Environment (CE) aspect of the CDB specification.
Just a quick clarification on the use of the term Common Environment (CE) and its relationship to the CDB.
The term CE/CDB is often used interchangeably with just CDB when in fact they are separate concepts. The CDB represents the (mostly static) geospatial environment while the CE represents the dynamic aspects typically referred to as the CGF or SAF and the simulation interoperability standards. PEOSTRI released a set of "Sources Sought" documents in 2008 that defined the CE. From the commander's intent document:
"The purpose of the Common Environment (CE) is to provide a synthetic battlespace where Special Operations Forces (SOF) can train as they fight and conduct mission rehearsal on demand, in a cost effective manner, through the use of a common architecture, common subsystems, and simulation interoperability standards. The CE will enable Training and Mission Rehearsal using Live, Virtual, and Constructive Resources."
Of course, the requirement was also that the CDB be used as the database for the CE.
This was not intended to downplay the challenge of correlating CDB databases across end-client devices, simply as a clarification of the original intent of USSOCOM.
Craig
Hi,
Now that TerraVista 6.0 with CDB output has been released, I am trying to build a CDB database. While doing this a few questions arose on how certain things are supposed to be done in CDB. Hopefully someone can enlighten me a bit more about these subjects, so that I can understand the consequences of using CDB on the database construction process.
Roads & railroads
I have added vector data for roads and railroads. In the final CDB output these are also represented as linear features in the shapefile. But does this mean that I can not assign a texture to the roads anymore that makes them look like a typical European road?
Airport layout
For constructing airport layouts we normally use shapefiles to define the aprons, taxiways, markings, etc. For CDB I could give those features the proper FACC attributes, but to me it seams that approach will not give enough flexibility. For example when constructing markings with different colours on the aprons. Or does the CDB approach assume that an airport is build as a 3D model using an OpenFlight file and only then imported into the CDB?
Generic buildings
To populate cities in the database we often make use of the generic buildings in TerraVista which are extruded based on the footprints provided as areal features. To fit this in the CDB approach would that mean that TerraVista would make all those 3D models and they are put as 3D OpenFlight models in the CDB or does the CDB also allow them to be defined as footprint, where the RTP does the extrusion?
Arno