Overview
Studio provides several built-in, or default, datums within the default system catalog. These include datums for Levels, Foundations, and Facades. There are instances when it's necessary to have a datum that is system-agnostic, meaning it can be shared or used by any entity or system within Studio.
Origin Relative Datums are fixed vertical reference points that levels, components, and other entities share across your model. You create an Origin Relative Datum once within your datum catalog, then reference it wherever vertical positioning (offsets) is needed. Because a single datum can be shared across entities, any change to that datum updates every system that uses it automatically.
This article covers the following topics:
Creating & Applying Origin Relative Datums
Level Behavior: Stacking and Datum Orientations
Creating Origin Relative Datums
In the Project Browser, within the Catalogs tab, add a new datum using the + button. Choose "Origin Relative Datum" from the dropdown list.
In the Inspector, define the vertical position, or Z-value, within the ‘Offset’ box.
Name newly created datums clearly and consistently. Descriptive names prevent confusion when many systems are tied to the same references.
Tip: It’s recommended to establish your naming conventions before referencing datums across systems. Renaming widely-referenced datums after the fact may add unnecessary rework down the road.
Apply the datum(s) to any system that requires vertical coordination, such as levels or components.
To apply an Origin Relative Datum to a level, select the level in the Explorer, and in the Inspector, under Placement Type, change from "Stacked" to "Datum." Then choose the datum you want to reference.
Validate that referenced entities or systems update as expected when a datum value changes.
To apply an Origin Relative Datum to a Component Instance, select the instance in either the Explorer or Canvas, then in the Inspector, under Datum, choose the datum you want to reference from the dropdown list.
Validate that referenced entities or systems update as expected when a datum value changes.
Tip: Establish your naming conventions before referencing datums across systems. Renaming widely-referenced datums after the fact may add unnecessary rework.
Level Behavior: Stacking and Datum Orientations
Levels in Higharc Studio can be associated with each other in two ways: via Origin Relative Datum, or relative to each other via Stacked. Your choice determines how floor-to-floor relationships behave when levels are added, moved, or removed. Datum orientation further controls how downstream systems — entities, plans, and components — interpret each level's position.
With Origin Relative Datums, each level holds its own fixed position independently. With the default stacking, levels are positioned relative to one another, so shifting a base level carries dependent levels with it.
Decide whether the level stack should be absolute (datum) or relative (stacked) based on your project needs. In the example below, Level 2, by default, stacks on top of an intermediary Split-Level.
Applying an Origin Relative Datum to the Split-Level changes its and Level 2's vertical position.
Disabling 'Automatic Stacking' allows you to manually choose which level to 'Stack' on top of or below which other level. In this example, Level 2 ignores the intermediary Split-Level and drops down to stack on top of Level 1.
Run a quick validation, for example, change a datum associated with a level and confirm stacking changes propagate as expected.
Note: Level-above and level-below behaviors control how floor-to-floor relationships propagate when a level is added or removed. Configure these before referencing levels in downstream systems.