A coordinate can locate an object while leaving out how the design team positioned it. If a receiver needs to relate an element to a road, rail, tunnel, or design grid, a flattened XYZ value may not carry the reference, measure, direction, or offset that gives the placement its meaning.
First decide what the receiver needs. A static context model may require only positions in an agreed project frame. A design or coordination task may need the alignment or grid relationship so an element can be interpreted against the same reference.
Three placement choices
| Delivery choice | What it tells the receiver | What still needs to be declared |
|---|---|---|
| Alignment-relative | The object is positioned in relation to a named curve or alignment. | Which alignment and revision; the measure or station convention; direction of increasing measure; offset basis and sign; object orientation; engineering frame and units. |
| Grid-relative | The object is positioned from a named design grid or a pair of grid axes. | Which grid and revision; the axes or intersection; any offsets; the reference direction; placement parent; units and frame. |
| Flattened coordinates | The object has coordinates in a declared local or project frame. | Source and target frame, units, axes, operation if applicable, vertical meaning, and the relationship intentionally omitted. |
These choices are related but not interchangeable. An alignment is not a design grid, and neither is a coordinate reference system. A curve-relative placement may depend on a measure along a referenced alignment. A grid-relative placement may depend on an axis intersection, offsets, and a direction. A project CRS operation relates frames; it does not supply the alignment’s measure convention.
What the standards describe
OGC InfraGML 1.0 Part 3 describes the Alignment Requirements Class. That class is optional: an application may conform to InfraGML without implementing alignment support. The standard describes an alignment as a linear referencing system for locating physical elements. Its measure and offset definitions are tied to the represented alignment and curve; do not assume one universal station convention across projects or encodings.
The InfraGML record also qualifies its coordinate frame: AlignmentCurve geometry uses an Engineering CRS. That requirement does not itself define how the alignment is georeferenced to a map CRS, or how an IFC placement relates to it.
The current buildingSMART documentation pages for IFC linear placement, grid placement, and Alignment-based View are in the development documentation path. Treat them as Working Draft descriptions. The grid-placement page further states that IfcGridPlacement is not part of a standardized schema subset or implementation level. A published entity description or view purpose therefore does not prove that a selected release, view, sender, or receiver supports the relationship.
Build the placement requirement
Write down the relationship the receiving task needs before requesting a file:
| Requirement field | Record |
|---|---|
| Object population | Which elements require alignment-relative or grid-relative placement. |
| Reference identity | Alignment, curve, grid, axis, revision, and authoritative source. |
| Position measure | The station/distance value and the convention that defines its origin, direction, and units. |
| Offset | Reference side, sign, vertical or lateral meaning, and units. |
| Orientation | How element axes follow or differ from the alignment tangent or grid direction. |
| Frame relationship | Engineering/project frame, local placement parents, CRS/operation, and vertical context when needed. |
| Update behavior | What happens when the alignment, grid, or source model changes. |
| Permitted loss | Whether coordinates alone are acceptable and which design relationships may be omitted. |
| Evidence | How the receiver will identify the reference, measure, offsets, and resulting placement in the delivered data. |
Keep placement separate from other meanings. Spatial containment says where an object belongs in a project hierarchy. An alignment-relative placement says how it is located against a civil reference. An editable alignment model carries design intent beyond the placement of individual objects. Geometry, placement, containment, and editability need separate requirements when the receiving task depends on them.
When coordinates alone are sufficient
Flattening can be an intentional choice when the receiver needs only a stable spatial reference and has agreed that the alignment or grid relationship is not required. State that loss explicitly. If the receiver must update an element after an alignment revision, recover its station and offset, or coordinate it against a design grid, XYZ alone is not a complete requirement.
For local/project frame and CRS declarations, see coordinate context and georeferencing. For exact IFC release and view boundaries, see IFC exchange scope. Named route support and acceptance checks belong to the portal’s route and validation coverage.