@ifc-lite/data@3.5.1

Patch Changes

• #3325 111b733 Thanks @BIMvoice! - The Parquet Type column now names the IFC class the file declares, instead of the class its IfcTypeEnum value coalesces to.

  IfcTypeEnum maps several STEP class names onto one value on purpose, so the viewer's scope chips show one chip per family: IfcDoorStandardCase shares IfcDoor, IfcSlabStandardCase shares IfcSlab, and IfcDistributionFlowElement and IfcDistributionControlElement both share IfcDistributionElement. EntityTable.getTypeName resolves through that enum and only falls back to the parsed name when the enum says Unknown, so a known-but-coalesced class never reached the fallback and ParquetExporter wrote the coalesced name. A nine-entity model exported IfcDoor twice for one IFCDOOR and one IFCDOORSTANDARDCASE line, IfcDistributionElement three times for three different classes, and IfcSlab for an IFCSLABSTANDARDCASE — while IfcWallStandardCase came through intact only because it happens to hold its own enum value. The class is unrecoverable once written, and the archive disagreed with StepExporter, which re-emits every class verbatim.

  EntityTable gains an optional getExactTypeName, read through the new exactTypeName(entities, expressId) helper, which answers the declared class and falls back to getTypeName for table shapes that track no parsed names (a pre-v15 cache section, whose bytes never carried the column). Both table builders that keep their own columns now implement the accessor from one shared row reader, exactNameOfRow, also newly exported — so a model loaded from the server exports the same class as the same model parsed locally, rather than the coalesced one. getTypeName itself is unchanged, so the ~90 grouping, search and display callers that depend on the coalescing — the scope chips among them — keep the answer they had.

  CSV, JSON and ifcx exports read the class through other paths and still report the coalesced name; those are not addressed here.

• #3321 758ed93 Thanks @BIMvoice! - Three IFC classes are no longer reported as a different IFC class.

  IfcTypeEnum covers a fraction of the schema, so the table behind IfcTypeEnumFromString deliberately coalesces some classes onto a coarser one — IFCDOORSTANDARDCASE resolves to IfcDoor, which is lossy but sound because a door standard case is a door. Three rows pointed somewhere else entirely:

  • IfcTendonAnchor → IfcTendon — siblings under IfcReinforcingElement.
  • IfcFastener → IfcMechanicalFastener — the key's own child, so a plain fastener was reported as the narrower mechanical one.
  • IfcCableCarrierSegment → IfcCableSegment — siblings under IfcFlowSegment; the tray was reported as the cable it holds.

  entities.getTypeName() returned the wrong class for all three, which the Parquet exporter writes into its Type column. The rows are removed, so those classes fall through to the raw parsed name and keep their own spelling. A new test sweeps the whole table against the bundled IFC2X3/IFC4/IFC4X3 registries and fails any row whose key is not the class it resolves to or one of that class's ancestors, so this cannot come back under a different spelling.