[Proposal] Expose a physical-vs-conceptual category classification

[SamuelAB-VIM]

Environment

• vim-web 1.0.0-alpha.0, IIFE build (dist/vim-web.iife.js) loaded via <script>
• API: VIM.Core.Webgl.createViewer() (headless, custom UI)
• Chromium / desktop, devicePixelRatio 1.75
• Model: 2,547 elements (2,264 with geometry), 12 Revit categories, structural

---

Best filed against vimaec/vim-format (data layer shared by vim-web and VIM Flex), with
a vim-web doc/helper on top.

Problem. When building a cost/takeoff/QC tool, you need to keep physical building elements
and drop conceptual ones (Views, Cameras, Levels, Grids, Reference Planes, Section Boxes,
groups/containers). Today consumers reinvent this filter — and the obvious heuristics are all wrong:

• el.instances?.length > 0 includes Cameras: the 9 OST_Cameras here are saved-3D-view
  cameras (family "3D View"), each with instances: 2 but getBoundingBox() === null — phantom
  instances, no mesh. So instance count ≠ "has geometry".
• category.getCategoryType() === 'Model' also includes Cameras (OST_Cameras reports
  Model; see table).
• await el.getBoundingBox() != null does correctly exclude them, but it's async/per-element
  and doesn't scale (Initial Rust support #5), and hasMesh/hasGeometry — which should encode exactly this — are
  broken (RemoteG3d #1).

The discriminating data exists but is undocumented (category.getCategoryType() and
category.getBuiltInCategory()):

Category	categoryType	builtInCategory	Physical / costable?
Structural Framing	Model	OST_StructuralFraming	✅
Floors	Model	OST_Floors	✅
Structural Columns	Model	OST_StructuralColumns	✅
Structural Foundations	Model	OST_StructuralFoundation	✅
Walls	Model	OST_Walls	✅
Levels	Annotation	OST_Levels	❌
Model Groups	Internal	OST_IOSModelGroups	❌ (container)

So categoryType alone is leaky; the reliable discriminator is builtInCategory against a
curated set of non-physical OST_* categories.

Asks (any of):

1. Document getCategoryType() / getBuiltInCategory() (values, semantics, and the caveat
   that categoryType === 'Model' is not sufficient to mean “physical”).
2. Ship a maintained classification so every consumer doesn’t re-derive it, e.g.
   category.isModelGeometry / category.classification (physical | annotation |
   datum | view | container), or an element-level el.isPhysical.
3. Provide the curated non-physical exclusion set (OST_Cameras, OST_Levels, OST_Grids,
   OST_ReferencePlanes, OST_SectionBox, OST_Views, OST_RvtLinks, …) as data.

Why it matters for VIM specifically. This same classification is needed by VIM Flex
(Estimator, takeoffs, model-health dashboards). Putting it in vim-format means web + desktop
share one correct definition instead of three subtly-different ones.