This section captures the operational knowledge production workloads need on top of the function reference: when trgeometry is the right type relative to its neighbours (tpose and tgeometry), the frame conventions the implementation enforces, and the numerical hazards real rigid-body workloads hit. Most of these are surfaced separately throughout the chapter; the goal here is one place a new contributor can read end-to-end before instrumenting an application.
Three temporal types span the rigid-body / arbitrary-shape design space. Pick the narrowest type that fits the workload — narrower types pay less storage and produce sharper bounding boxes for the spatial index.
tpose — temporal position and orientation only; the body is treated as a point with a heading. Use when the shape is irrelevant to the query (kinematic tracking, heading-only collision proxies).
trgeometry — a single static reference shape that translates and rotates over time per a temporal pose. Use when the shape matters but is rigid: ships, vehicles, drones with fixed geometry, body-conforming exclusion zones. The reference geometry is stored once per row, not per instant, so storage is dominated by the underlying tpose.
tgeometry — temporal arbitrary geometry whose shape itself varies over time. Use when the shape is non-rigid: storm wind swaths, expanding plumes, evolving polygons.
A trgeometry can be projected to its underlying tpose (centroid trajectory) or to a fully-materialised tgeometry via the conversions in the section called “Conversions”. The reverse direction (lifting a tgeometry back to a trgeometry) is not generally well-defined since arbitrary shape changes do not factor cleanly into rotation + translation of a fixed reference.
2D-only reference geometry. The reference shape is a 2D polygon or polyhedral surface; the pose's rotation component is the 2D yaw angle from Chapter 11, Temporal Poses. There is no 3D rigid-body representation in this type — workloads needing full 3D orientation (quaternion) on a 3D shape should compose tpose with the materialisation step explicitly.
Single shared reference geometry. Every instant of a trgeometry shares the same reference shape; only the pose varies. The shape is stored once per row, not per instant.
Same-SRID requirement. The reference geometry and the temporal pose must share an SRID; the constructor rejects mismatches with the standard MEOS ensure_same_srid error. The materialised geometry inherits this SRID.
Centroid-based spatial-restriction semantics. atGeometry, minusGeometry, atStbox, and minusStbox test the centroid of the materialised shape against the region — not the materialised shape itself. A trgeometry whose centroid lies outside a region but whose body extends into the region is excluded. This mirrors the underlying tpose semantics (a pose is a point) and is a deliberate design choice; workloads needing whole-shape containment must materialise to tgeometry first.
Four hazards reliably bite real rigid-body workloads. The implementation mitigates each as follows:
Mixed-SRID inputs. Constructing a trgeometry from a reference geometry and a tpose in different SRIDs would silently produce wrong materialised positions if the SRIDs were not checked.
Mitigation: the constructor and every cross-type operator route through ensure_same_srid, which raises an error naming both SRIDs. The error path is loud and explicit; there is no implicit transform.
traversedArea sampling caveat. The traversedArea function samples at the input instants and connects them with the convex hull of the two endpoint polygons. Pure-translation segments are exact, but inter-instant rotations are approximated — for a 90° rotation between two instants, the swept ribbon is wider than the convex hull captures.
Mitigation: documented in the section called “Traversed Area”. Workloads needing tight swept-area bounds must up-sample the input tpose before constructing the trgeometry; the setInterp + sub-instant insertion pattern from the tpose chapter is the standard approach. Adaptive sub-sampling within traversedArea is a documented future refinement.
Adaptive sub-sampling tolerance in materialised distance. Continuous-distance kernels (tDistance, nearestApproachDistance) materialise the rigid shape per inter-instant gap and emit intermediate marks where the distance trajectory deviates from a straight line. The depth-cap is 32 marks per gap and the LINEAR-interpolated approximation between marks is bounded by 1e-3 (in CRS units).
Mitigation: the 1e-3 bound is a documented design choice. Pure-translation segments converge at depth 0; rotation-heavy segments use the full 32-mark budget. Workloads that need sharper precision on a specific operator should pre-process the input poses to denser instants rather than rely on tighter recursion.
Centroid-based spatial restriction surprise. atGeometry(trgeometry, geometry) tests the pose centroid against the region, not the materialised shape. A long ship whose stern is in a harbour but whose bow has crossed the harbour boundary will be reported as inside the harbour as long as its centroid is inside.
Mitigation: documented as a tier-D design choice in the section called “Spatial Restrictions”. Workloads needing whole-shape semantics must convert via trgeometry::tgeometry before applying the spatial restriction. The conversion materialises one polygon per instant and is correspondingly more expensive.
The on-disk representation of a trgeometry is the reference GSERIALIZED followed by the temporal-pose payload. The byte layout is stable: asBinary(trgeometry) / trgeometryFromBinary(bytea) round-trip preserves the value bit-for-bit (including the reference shape's SRID, Z and M flags, and the underlying tpose subtype), and the WKB / EWKB / HexEWKB serialisations follow the standard PostGIS endian-flag-then-payload pattern.
The asMFJSON(trgeometry) / trgeometryFromMFJSON(text) pair is bidirectional. Each instant renders as {"geometry":<reference-geojson>,"values":[<pose-payload>]}: the reference geometry uses the standard PostGIS GeoJSON shape and the pose payload follows the OGC GeoPose Basic-YPR conformance class layout ({"position":...,"quaternion":...} for 3D / {"position":...,"rotation":...} for 2D). The reference geometry is emitted once per instant in the current schema; future schema work could elevate it to a chapter-level header to avoid the per-instant repetition for long sequences.
The pg_dump output of a table containing trgeometry columns uses the WKT representation by default; pg_dump --binary-upgrade uses the WKB representation. Both are round-trip-stable across PostgreSQL major-version upgrades.