Open sarasaeedi opened 3 years ago
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:
I ignored all deprecated attributes under the assumption that it is not worth the time to deal with them.
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:
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.
@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).
@sarasaeedi This table looks great to me, it's pretty much exactly what I had in mind.
I like the table. Some possible fixes:
Are you planning to address other FACC style attributes, like TRF, USP, DIR, DEP, etc.
@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.
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.
@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
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.
@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?
@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?
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.
@ryanfranz, for the WGP, it is done! Thank you for that.
@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.
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:
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.