Space (Usage) — Occupancy Types & Space Names

Value catalogues backing the Space (Usage) IfcSpace properties OccupancyType and SpaceName, extracted verbatim from the official IFC-SG glossary page (source, retrieved 2026-07-19). These lists are inlined as allowed_values in arc/space_usage/parameters.json.

The two catalogues classify different things. OccupancyType classifies the development — or, in a mixed-use development, the part of it a space sits in — and is the crosswalk to each authority's project-level classification. SpaceName classifies the space's own function. Every space carries both.

Occupancy types (95)

What an occupancy type classifies. These 95 values are development-typology classifications, not room functions. Most are introduced on the official page by an "Applicable for a …" line naming building or development types — Single dwelling residential is "Applicable for a bungalow, detached house, semi-detached house, or terrace house" — and each sits under a table crosswalking that typology to every authority's own project-level classification: SCDF Table 1.4A Purpose Group, BCA Table 2.2A Type of Occupancy, BCA Accessibility Code 2019/2025 Building Type, PUB Sewerage and Sanitary Works (SSW), and NEA. One occupancy type therefore describes a development, or in a mixed-use development a part of one, rather than a room: every IfcSpace in that part carries the same OccupancyType. It is not picked per space from what the room is used for — that is SpaceName.

They are still the input list for the per-space parameter. OccupancyType is an IfcSpace property on the Space Usage (Others) table, whose value cell reads "Refer to list of Occupancy Types in Modelling IFC+SG (Space Usage)" — this list. So the 95 names below stay inlined unchanged as allowed_values for OccupancyType in arc/space_usage/parameters.json; what is corrected here is how a value is chosen, not which values are valid.

SCDF Purpose Group (Table 1.4A) and BCA Type of Occupancy (Table 2.2A) are parsed; the BCA Accessibility Code (2019/2025) and PUB SSW columns use nested rowspans on the source page and are omitted here pending manual verification. The "Applicable for …" line is kept as applicability in space_usage.json for the 59 types that publish one; the rest are presented on the page inside a shared group.

Space name categories (16)

Each category below is the official table as published: the SpaceName value on the left, paired row by row with the SCDF Functional Space it maps to. SpaceName records the space's own function — as against OccupancyType's development typology — and only the left column is a valid input. SpaceName allowed_values is the deduped union of that column across the 16 categories (421 values); the SCDF Functional Space column is a classification mapping, reference only, never a SpaceName input. Values may repeat across categories, and the page says why: "This is because the SCDF Occupancy Load (OL) will differ depending on where the Bedroom is located."

How the pair resolves. Many functional-space strings end in a parenthetical list of building types — Guestroom/ Accommodation Unit - (Capsule Hotel), Area of Refuge – (Hospital) — and that parenthetical is the occupancy type. SpaceName selects a name's group of rows and OccupancyType selects the row within it; the SCDF Functional Space that results is what Table 1.4B (Occupant Load Factors) of the SCDF Fire Code is read against for occupant load. The Temporary residences legend states it outright: "Note that the OL of Guestroom Space will depend on what is indicated in its Occupancy Type" — "Guestroom" spans three functional-space rows there, one per accommodation typology.

Rows follow the official rowspan groups, so a space name paired with several functional spaces prints once per pairing; each heading counts distinct SpaceName values, not rows. Values are listed unmarked. The official page prints footnote markers against some of them (*, **, ^), and those carry real obligations — occupant load depending on the Occupancy Type, declaring ParkingType, modelling IfcStair. The marker is not part of the value, so it is stripped here and captured per row as notes, with each category's full legend, in space_usage.json.

The pairing is reproduced, never interpreted into a SpaceName → OccupancyType join table: only a handful of the 200 functional-space strings match an occupancy type name outright, and resolving "Area of Refuge – (Hospital)" against Hospital with A&E services or Hospital without A&E services would be a guess.

Living spaces (22 SpaceName values)

Temporary residences (6 SpaceName values)

Non residential toilet spaces (for spaces with WC) (12 SpaceName values)

Resting, care, hygiene spaces (for spaces without WC) (13 SpaceName values)

Commercial, work, institutional spaces (83 SpaceName values)

F&B spaces (14 SpaceName values)

Medical, healthcare spaces (16 SpaceName values)

Assembly Spaces (28 SpaceName values)

Supporting spaces for performing (9 SpaceName values)

Entertainment, recreation spaces (57 SpaceName values)

Open spaces and open-sided spaces (14 SpaceName values)

M&E spaces (67 SpaceName values)

Storage spaces (16 SpaceName values)

Commuter facilities (13 SpaceName values)

Circulation spaces (41 SpaceName values)

Other non simultaneous spaces (22 SpaceName values)