CesiumJS ignores bounding volume metadata for implicit tilesets

[javagl]

Consider the following excerpt of a tileset JSON:

{
  ...
  "schema": {
    "id": "cesium-tiling-pipeline",
    "classes": {
      "tile": {
        "properties": {
          "tightBoundingBox": {
            "name": "Tight Bounding Box",
            "type": "SCALAR",
            "componentType": "FLOAT64",
            "array": true,
            "count": 12,
            "semantic": "TILE_BOUNDING_BOX"
          }
        }
      }
    }
  },
  "geometricError": 1370.9605003261136,
  "root": {
    "boundingVolume": {
      "box": [0, 0, 10, 10, 0.0, 0.0, 0.0, 10, 0.0, 0.0, 0.0, 10]
    },
    "geometricError": 39.57622101917514,
    "refine": "REPLACE",
    "metadata": {
      "class": "tile",
      "properties": {
        "tightBoundingBox": [0, 0, 5, 5, 0.0, 0.0, 0.0, 5, 0.0, 0.0, 0.0, 5]
      }
    },
    ...
  }
}

The TILE_BOUNDING_BOX semantic overrides the tile.boundingVolume, meaning that the bounding box of the root is [0, 0, 5, 5, 0.0, 0.0, 0.0, 5, 0.0, 0.0, 0.0, 5]. But for the special case where this is the root of an implicit tileset, CesiumJS causally suggests ambiguities and sliently ignores the metadata.

Note that changing this could be difficult, because there are already many tilesets out there that silently assume that CesiumJS shows the wrong behavior here. So the main purpose of this issue is just to serve as a link target for forum threads and issues where people are asking why different viewers and data sets behave inconsistently.

[lilleyse]

Summarizing an offline conversation about this... I believe the assumed order is:

• Bounding volumes are generated by subdividing the root tile's bounding volume
• Bounding volumes may be overridden by implicit tile metadata, e.g. TILE_BOUNDING_BOX
• The root tile's bounding volume may be further overridden by tile metadata in tileset.json, e.g. TILE_BOUNDING_BOX

The spec should clarify this behavior.

[javagl]

An attempt to illustrate (as a "quadtree", in 2D) what I perceive to be an inconsistency of which I'm not sure how to resolve it:

Referring to the large (cube-shaped) bounding volume, there is one "slice" of tiles available. Their bounding volume height matches the content.

When overriding the bounding volume with the "tight" one from the metadata, then the availability information does not change. Only the red "slice" is declared to be available, even though, in the tight bounding volume, all tiles should be available. The bounding volumes of that "slice" do not fully contain the geometry.

[javagl]

Just to wrap up the previous comment: This assumed a different order. The assumption now is that the inconsistency can be resolved by

1. first deriving the implicit child bounding volumes from the original bounding volume
2. then overriding the original bounding volume with the one from the metadata

This may require the client to offer different access functions, one for the original bounding volume and one for the overridden one. And this feels like it defeats the purpose and concept of "overriding". But we'll see how clients can handle this on a case-by-case basis.

[javagl]

The Specification currently says

The following constraints apply to implicit root tiles:
...
The tile shall omit the metadata property

So the given tileset is invalid.