Adding CDB-specific attributes with their semantics to Vol 1

[sarasaeedi]

After removing all the attributes from vol 1 and cross-referenced them to the CDB_Attributes.xml file, the next step is: -Adding attributes only from CDB with their semantics in the table in the section "10.7.1.3. CDB Attributes". The suggestions in the previous meetings were to document CDB model related attributes, CNAME and FSC.

For now we have added these attributes and their semantics:

• Class Name (CNAME)
• Feature Sub Code (FSC)
• Bounding Boxes Height (BBH), Width (BBW) and Length (BBL)
• Bounding Sphere Radius (BSR)
• AHGT, HGT, and Z Attributes
• AO1

I was wondering if there are any other attributes that are good to be defined in Vol 1? The rest are CDB_Attributes.xml file.

[UnclePoole]

I agree with the attributes Sara listed since they all affect either feature type, database layout, or model placement. Additionally I suggest these attributes may need to be documented depending on whether they are used as described by their XML:

• Airport ID (APID) - says this is a cross-reference to Airport or Heliport dataset
• CDB Extended Attribute Index (CEAI) - affects database structure and attribute layout
• CDB Composite Material Index (CMIX) - reference into Composite Material Table therefore affects cross-reference structure
• End Junction ID (EJID) - affects cross-references between feature geometries and between datasets via relationship file, affects database structure
• Feature Attribute Classification Code (FACC) - identifies feature type
• Gate AirPort ID (GAID) - cross-reference into NavData dataset, affects structure
• Geomatics Extended Attribute (GEAI) - affects database layout, not currently deprecated - is this used?
• Junction ID (JID) - affects cross-references between feature geometries and between datasets via relationship file, affects database structure
• Layer Priority Number (LPN) - affects feature depth ordering
• Light Type (LTYP) - special instructions specific to CDB light hierarchy
• Model Level of Detail (MLOD) - affects model instantiation interpretation and thus CDB structure
• Model Name (MODL) - affects model instantiation and thus CDB structure
• Model Type (MODT) - affects model instantiation and thus CDB structure
• Network Component Selector 1 (NCS1) - affect cross-referencing between datasets
• Network Component Selector 2 (NCS2) - affects cross-referencing between datasets
• Network Dataset Code (NDSC) - affects cross-referencing between datasets
• Relative Tactical Importance (RTAI) - documented guidance affects client side rendering decisions for model instantiation
• Runway ID (RWID) - cross-reference to NavData setasets
• Scaling X-Axis (SCALx) - documentation says this affects model rendering decisions
• Scaling Y-Axis (SCALy) - documentation says this affects model rendering decisions
• Scaling Z-Axis (SCALz) - documentation says this affects model rendering decisions
• Start Junction ID (SJID) - affects cross-referencing between feature geometries and datasets
• Taxiway ID (TXID) - affects cross-reference to NavData datasets
• Vendor Extended Attribute Index (VEAI) - affects database structure and attribute layout

[UnclePoole]

I ignored all deprecated attributes under the assumption that it is not worth the time to deal with them.

[UnclePoole]

There are more attributes that affect dataset cross-references than I expected, one suggestion to consider might be to organize the attributes in three main groups:

• Feature type, subtype, class name, light, material, and extended attribute indices
• Model placement and client rendering attributes
• Topology, junction, and navigation cross-references

[UnclePoole]

Almost all of these attributes, except for AO1 and HGT, are custom to CDB affecting database traversal interpretation and are not defined by a prior standard like FACC or EDCS, which is probably a good general rule to use to decide if attributes need special handling.

[sarasaeedi]

@UnclePoole and @DavidFLOR , I have updated volume 1 with a new table. The table is shown below: https://docs.google.com/document/d/1-F-_X7q6JXQkOtq2EMvUu5PwwWOKxMLsKm7ZygmKDxw/edit?usp=sharing

The table includes CDB specific attributes in three groups. Please let me know if it needs any improvement (preferably by this Friday).

[UnclePoole]

@sarasaeedi This table looks great to me, it's pretty much exactly what I had in mind.

[ryanfranz]

I like the table. Some possible fixes:

• It is missing the Vendor Extended Attributes Index (VEAI) that functions almost the same as CEAI and GEAI
• WGP is used quite often, it should be added
• Attributes like MLOD, MODL, MODT are both for rendering and also affect the CDB structure. These define the name of the model, whether the model is GeoSpecific or GeoTypical, and what lod of the model (of layer zip file) to load. This is a case where you have attributes in multiple categories. If I had to place them in one or the other, I would put them into the CDB specific category
• It missing Gate ID (GAID) that functions similar to the airport or runway id

Are you planning to address other FACC style attributes, like TRF, USP, DIR, DEP, etc.

[UnclePoole]

@ryanfranz Good catches there. The main intent of what I had in mind (that I think @sarasaeedi was also trying to do) was capture only attributes that have special meaning to CDB structure, model placement, or topology and thus would need to stay in place even with a NAS profile replacing FACC. FACC attributes are purely standalone semantic attributes so they don't need special clarification at the structural level.

[cnreediii]

Good discussion and table. So, this makes me wonder what aspects, such as "names" we should move forward into CDB-X. Some of the items being discussed are directly related to datatypes and the enumeration of datatypes and their names used in CDB 2.0/X.

[ryanfranz]

@UnclePoole - Got it, it is helpful to have CDB specific things that are present due to the CDB structure itself.

One more attribute that is CDB specific and I missed is MMDC

[sarasaeedi]

Thanks @ryanfranz and @UnclePoole for clarifications. I have added the following attributes as advised by @ryanfranz:

MMDC to Group I: CDB indexes that affect database structure and attribute layout. VEAI to Group I: CDB indexes that affect database structure and attribute layout.

WGP to Group II: CDB model placement and client rendering attributes. DEP to Group II: CDB model placement and client rendering attributes.

GAID to Group III: Cross-referencing between feature geometries, topology, navigation data and CDB datasets.

🚩Issue 1) For attributes like MLOD, MODL, MODT which are both for rendering and also affect the CDB structure, I put them in the first group (I) as they can be considered as an index for CDB structure! Please verify that is correct @UnclePoole and @ryanfranz 🙏

🚩Issue 2) Based on the question from @ryanfranz regarding attributes like TRF, USP, DIR, etc, we are not going to consider them as they are originally from other standards (e.g. DIGEST) and don't have special meaning to CDB structure, model placement, or topology.
However, I considered DEP as it is similar to AHGT, HGT, BSR, and BBH. @ryanfranz and @UnclePoole please confirm this.

[UnclePoole]

@sarasaeedi These changes make sense to me. One thing I saw in the latest version of the table that I didn't remember was a row at the end for various density attributes that doesn't seem to be attached to any of the three groups. Is that intended to be there?

[ryanfranz]

@sarasaeedi In the table, the WGP should be in group 2 attributes that impact rendering, but I see it in group 3.

All - do we want to group attributes that come from FACC separately (in another group)? Stuff like WGP, HGT, DEP are FACC attributes, and might or might not impact rendering (group 2), depending on whether that attribute was used or if your system cares about the attribute. Maybe this gets into what the purpose of group 2 is. If you want to render radar return off the ground, then using SRD (surface roughness description) is a rendering attribute that is in FACC. But other use cases likely don't use SRD. Attributes like AHGT, BSR, BBW, LPN, SCALx; these are all CDB specific and need to be grouped as well (original group 2). Do you think it is worth another group, to capture pure FACC attributes, no matter how they are used?

So I guess I am proposing splitting group 2 into two groups, one for CDB-only rendering attributes that are not FACC, and one for pure FACC attributes. Or is it better to group rendering attribute vs non-rendering attributes, no matter their source?

[sarasaeedi]

Thanks @UnclePoole. Regarding the density-related attributes, I am so sorry to confuse you with those! When I was trying to work on those TRF, USP, DIR, etc., I found these density related attributes that I thought they could be considered too. But then I decided to exclude them from the table as they are not relevant to the CDB structure.

[sarasaeedi]

@ryanfranz, for the WGP, it is done! Thank you for that.

[sarasaeedi]

@ryanfranz, I am not very familiar with the differences between pure "FACC-based" and "CDB-based" attributes for rendering. I will wait for the decision on this.