coordsys_bridge_traits
namespace nin {
template <typename Br>
concept coordsys_bridge_traits;
}
Any coordinate system bridge must satisfy the coordsys_bridge_traits concept.
A bridge connects two coordinate systems that live in different spaces — for example,
linking a 2D planar (R2) coordinate system with a 3D spatial (R3) one.
Requirements
A type Br satisfies coordsys_bridge_traits if:
| Requirement | Description |
|---|---|
|
The first coordinate system traits type. Must satisfy |
|
The second coordinate system traits type. Must satisfy |
Inherits |
The bridge is itself a coordinate system in space A. |
Inherits |
The bridge is also a coordinate system in space B. |
|
Converts a coordinate from space A to space B. |
|
Converts a coordinate from space B to space A. |
Because a bridge inherits from coordsys on both sides, it occupies a position in the
kinematic tree of both spaces simultaneously. This is what allows mapCS() to traverse
from a coordinate system in space A, through the bridge, and into space B.
The concept additionally constrains the bridge’s layout:
sizeof(Br) == sizeof(coordsys<coordsys_traits_A>) + sizeof(coordsys<coordsys_traits_B>).
A bridge type must therefore add no data members of its own beyond the two coordsys
subobjects it inherits. State that varies at runtime (per-bridge offsets, calibration
data) belongs in one of those coordsys subobjects' backends, not in the bridge type
itself.
Usage with mapCS
Bridges appear as intermediate arguments to mapCS():
coord_tf tf = mapCS(cs_2d, bridge, cs_3d);
Multiple bridges can be chained to cross several spaces in a single call.
The convert() functions define how coordinate values change representation at each
crossing point.
See also
For a step-by-step recipe on writing your own bridge, see How to define a bridge between two coordinate spaces.