Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions docs/cross-repo-handoff.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,11 +57,13 @@ results across all three platforms using the bare names only.
- **`cbuffer`, `npoint`, `pose`, `rgeo` are full user-facing temporal
types**, covered like every other type; they are never excluded from a
parity headline.
- **One base type carries several temporal types.** A geometry is the base of
`tgeompoint` and `tgeometry`, a geography of `tgeogpoint` and `tgeography`,
a pose of `tpose` and `trgeometry`. `typeRelations.byBase[...].temporal` is a
list for that reason, one entry or several, so a consumer reads one shape;
taking a single name loses three types MEOS has.
- **The instants of several temporal types store one base type.** Those of
`tgeompoint` and `tgeometry` store a geometry, of `tgeogpoint` and `tgeography`
a geography, of `tpose` and `trgeometry` a pose. `typeRelations.byBase[...].temporal`
is a list for that reason, one entry or several, so a consumer reads one shape;
taking a single name loses three types MEOS has. A `trgeometry` is not
`Temporal<pose>`: it is the concatenation of a reference geometry and a temporal
pose, its value at an instant the geometry the stored pose places.
- **A surface that speaks MF-JSON reads the type token from
`temporalTypes[...].mfjson`.** It differs per type and MEOS states it in one
place, `temptype_as_mfjson_sb`. A type the switch does not name carries no
Expand Down
15 changes: 10 additions & 5 deletions parser/typerelations.py
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,13 @@
and resolving through the names yields, for each base type name, the names of
its set, span, span set and temporal types.

``Temporal<T>`` is the one template a base instantiates more than once, so the
``temporal`` role is a list: a geometry carries ``tgeompoint`` and ``tgeometry``,
a pose carries ``tpose`` and ``trgeometry``.
The ``temporal`` role names every temporal type whose instants store a value of the
base, the inverse of ``temptype_basetype``, so it is a list: the instants of
``tgeompoint`` and ``tgeometry`` store a geometry, and those of ``tpose`` and
``trgeometry`` a pose. A ``trgeometry`` is not ``Temporal<pose>``: it is the
concatenation of a reference geometry and a temporal pose, each instant storing the
pose that places the geometry, so its value at an instant is a geometry while
``getValue`` reads the stored pose.

This is the static metadata a binding generator needs to pick the concrete
collection type of a value-domain result — ``SpanSet<float>`` is ``floatspanset``
Expand Down Expand Up @@ -135,8 +139,9 @@ def attach_type_relations(idl: dict, src_root: Path | None) -> dict:
related[role][meos_type] = fields[forward]
if inverse in fields:
related[role][fields[inverse]] = meos_type
# A base names no temporal type of its own, and one base carries SEVERAL of them: a
# geometry is the base of tgeompoint and tgeometry, a pose of tpose and trgeometry. So
# A base names no temporal type of its own, and the instants of SEVERAL may store it:
# those of tgeompoint and tgeometry a geometry, those of tpose and trgeometry (a
# reference geometry and a temporal pose) a pose. So
# the temporal role is the inverse of temptype_basetype, and it is every type naming
# that base, in MeosType order. Keeping one of them drops the others from the registry
# entirely, and a generator projecting the temporal types out of it then emits a
Expand Down
Loading