[estebanzimanyi]

tools/oo_codegen/codegen.py reads the meos-idl.json catalog of the MEOS
the package builds against, given by --idl or MEOS_IDL, and writes the
regular method families of TCbuffer, TPose, TNpoint and TRgeometry, the
comparisons, the spatial relationships, the distances and the
restrictions, as the mixins pymeos/main/_generated/_methods.py:
each method dispatches by the argument's type to the pymeos_cffi
function of its overload, and each temporal class takes its mixin as its
first base, so the generated method is the one the class answers with
and its fallback reaches Temporal. The constructors, the conversions, the
accessors, the transformations and the input and output stay in the
hand-written classes.

The generator writes a mixin through ruff check --fix and ruff format, so
the committed file is its output and passes the ruff workflow; a catalog
argument token the family model does not map, or that has no place in
the dispatch order, stops it with the token's name. --check accounts for
every catalogued function, emitted or counted under a named exclusion.
The rigid geometry family reads the trgeometry token of the catalog and
restricts through the public trgeometry_at_* and trgeometry_minus_*
functions, to a geometry, a pose, a set of poses and the time types; a
temporal pose restricts to an elevation span through tpose_at_elevation
and tpose_minus_elevation.

The test workflow sets MEOS_IDL to the catalog it derives;
tests/test_oo_codegen_coverage.py checks the accounting, that every
committed mixin is the generator's output on that catalog and that every
function a mixin calls is a function of the catalog.

Witness: against PyMEOS master 59191dd,
TPoseSeq('[Pose(Point(1 1 1),0.0,0.0,0.0,1.0)@2001-01-01, Pose(Point(1 1
3),0.0,0.0,0.0,1.0)@2001-01-03]').at(FloatSpan('[1.5, 2]')) raises
TypeError and a TRgeometry has no within_distance; against this branch
the first answers {[Pose(POINT Z (1 1 1.5),0,0,0,1)@2001-01-01
12:00:00+00, Pose(POINT Z (1 1 2),0,0,0,1)@2001-01-02 00:00:00+00]} and
the within_distance of a moving triangle with itself at 1.0 answers
{[t@2001-01-01 00:00:00+00, t@2001-01-03 00:00:00+00]}.

Measured: on the catalog of MobilityDB 5bf840dca5, 5446 functions
accounted for, 123 regular methods across the six families, 77 of them
wired into the four classes, 76 in place of the hand-written methods of
the same name and TRgeometry's within_distance; a second generator run rewrites the
four mixins byte for byte; 4851 tests, 6 of them the new restrictions and
within_distance; ruff check and ruff format report no finding.

Why: the bindings are projections of the MEOS catalog, so a method
family that the catalog states is generated from it and follows it as
MEOS gains overloads, where a hand-written family falls behind.

[estebanzimanyi]

The generated method families land as one pull request on master, generated from the catalog CI derives at its MobilityDB commit; this branch stays as a reference.