Splitting CDB X into multiple parts/documents

[ryanfranz]

Something that David said (I think during the CDB SWG meeting) about possibly separating out the core of CDB is intriguing to me. To have a valid CDB 1.x, almost nothing has to be present in the CDB, except for the core Metadata directory. I think breaking in up into pieces might help move things along better in the SWG, and help us focus our thoughts and ideas. So here is a half baked proposal:

Create a core CDB X standard, and have it contain the root conceptual model, the required directories/containers and machine readable files to describe a CDB X, and contain all the core concepts and definitions (for tiling, LODs, significant size, directory structure). After this, I think we could split the rest of the work into separate documents that could refer back to the core:

• Basic Coverages
  • Layers like elevation or imagery
  • Concepts like gamma or point vs area coverage
• Advanced Coverages
  • More advanced layers like raster materials, terrain light maps, multi-spectral imagery
  • Concepts like electromagnetic spectrum, reflective vs emissive, or physical materials (which is not related to PBR)
• Vector data (points, lines, and polygons whether tiled or not)
  • Layers like man-made features, vegetation/natural features, non-visual features (like country boundaries), navigation networks (roads or AI/human movement areas)
  • Maybe this is too much here and needs to be split further
• 3D content
  • Layers like models and textures with LODs
  • Concepts like model LODs, PBR, etc
• Attribution profiles
  • Although with the structure the attribute group is creating, maybe this belongs in the core
• Aerospace navigation (DAFIF/ARINC)
  • Only needed for flight sim or related use cases

So core could define a feature for handling unknown/default values (currently Defaults.xml). And each additional CDB document drills down into how to use this feature (defaults for attributes, or values for missing elevation). Or core defines how tiling works, but each additional CDB document decides whether tiling is appropriate for it or not. And something like 3D content could require the use of man-made and natural vector data, and describe the additional attributes (or use an attribute profile defined for visualization) needed for that vector data.

Could a breakdown (that is better thought out than this) help support different profiles. Thus one profile might need 3D content, while another doesn't, and makes implementing a CDB easier for first time users.

Thoughts?

[cnreediii]

@ryanfranz Believe it or not I actually worked for a bit on trying to tease out a "core" for CDB 1.2. I have a copy - the issue I ran into was how some discussions and concepts are wrapped up more like a ball of twine than the logical grouping you are suggesting we target. Thanks for starting this discussion. Very important - at least from point of view as the editor :-)

[UnclePoole]

Conceptually I agree with this approach wholeheartedly and this will make it much easier to find specific details when you need it. The devil's in the details of course.

[UnclePoole]

For the attribution groupings specifically, I think the Core should define the mechanism for defining such groupings and any baseline core types that would be reasonably used everywhere (very common properties like WID and HGT maybe). But the domain specific stuff for ground, interiors, aeronautics, etc. should ideally be grouped with anything else that's domain specific I think.