One could argue that this is not really a “documentation”, but a specification. And there, one has to go into certain details and present things in a certain structure and form that may not be easy to digest in order to “get started”.
There should be more “Tutorial-style” documentation with examples, and a better tooling support for creating this sort of data. It’s unfortunate that this does not exist yet, but the support (both in terms of ducumentation and tools) is likely to grow in the near future.
Regarding your questions:
- Contents of tileset.json vs. .gltf/.glb files: Could someone clarify what information is typically stored in the tileset.json file versus what’s contained within the individual tile .gltf files?
This question has a certain overlap to others, for example, Best practices for tileset and glTF structure and embedding metadata . You might find some helpful hints in this thread. But for this thread as well as your question, the overarching answer is (what I also wrote in my first response there): There are many engineering questions involved. There already is the question “What is a good structure for a tileset?”. And many trade-offs have to be considered there. And there is the additional question of “What is a good structure for the metadata of a tileset?”, and the answer involves many trade-offs, and depends on the answer to the first question.
Many words. Little information 
I’ll try to give a very rough summary, and this refers to the “granularities” image that is shown in the specification:
The tileset JSON describes the “coarse grained” structure. It could be a tileset that defines “a city”, and it could have tiles where each tile is “a building” or “a tree”. And the metadata in the tileset JSON covers this “coarse granularity”: You can associate metadata inside the tileset JSON, either with the tileset as a whole, with individual tiles, with groups of tiles, or with the content of each tile.
But sometimes, you need metadata on a much more fine-grained level: You might have one GLB file that does not define “one building”, but may contain geometry data from several buildings, and you might want to store metadata like “The front door of building 42 is made of wood”. You cannot store this information in the tileset JSON, because it refers to parts of the geometry that is stored in the GLB file. So you have to put it into the GLB file itself, using the EXT_structural_metadata extension.
Adding this metadata to the GLB is a bit more difficult than just adding it to some JSON - this is related to your question 3. below.
- Programming Tools for Metadata Integration: Are there programming tools available to facilitate the addition of metadata? I’m looking for ways to automate this process within my existing workflow.
There are no out-of-the-box solutions for that yet. One reason lies in the question of “Which programming language should this be in?”. But more generally: Support for handling metadata will have to be added to whatever library already is used for handling 3D Tiles tilesets.
This should be relatively easy for the JSON-based metadata. It’s a bit more tricky for ‘property tables’, where the metadata is stored in binary form. And this, in turn, is similar to the way how the metadata is stored within glTF, which leads to the next point:
- Encoding to GLB: I’ve encountered challenges when attempting to manually modify the GLB header. What methods or tools should I use to produce GLB files effectively?
I’m not sure what you mean by “manually” editing the GLB header. (Hopefully not a HEX editor…). Similar to the previous point: There should be support for metadata handling within the tool or library that you are already using for creating or manipulating glTF.
There is experimental support for handling the glTF metadata extensions as part of the 3D Tiles Tools. This is not a public API. It might change arbitrarily in the future. But it is an implementation of the glTF metadata extensions based on glTF-Transform. Preliminary demos for creating glTF with metadata are shown in the gltf-extensions demos.
(I once started adding support for the metadata extensions in JglTF as well, but the only thing that is public right now is the auto-generated classes for that. Without any “abstraction layer”, this is really hard to use, but unfortunately, I haven’t spent nearly enough time for that recently - it’s a “spare time project”, and as such, the progress there depends on “spare time”…)
- Where to test : I’ve tried babylon.js sandbox to check for metadata presence in my attempts, but so far no success. What’s the best way to verify the presence of metadata and eventually troubleshoot ?
This is the consuming side, and the idea is the same: The consuming side has to implement support for this metadata, to make any use of it.
The “reference implementation” for the client side is, of course, CesiumJS itself. But an increasing number of 3D Tiles rendering clients are adding support for 3D Tiles 1.1 with the associated metadata.
A helpful resource to get started should be the 3D Tiles Samples. They contain simple example tilesets with metadata, and CesiumJS Sandcastles that show how to render these tilesets and to access the metadata.
There als is a subfolder for the glTF Extensions, also with example data sets and the matching CesiumJS Sandcastles.
When you are already creating 3D Tiles with metadata, then the 3D Tiles Validator should allow you to check whether this metadata complies to the specification, but that may be a step that goes beyond “getting started”.
