[PROJ] Synthetic Coordinate System

[Thomas Knudsen]

> The octant component is ordinal/nominal, not a third spatial axis — there's no
> meaningful interpolation between octant 3 and octant 4.
> I'm encoding it as a 3rd Cartesian axis with orientation=unspecified and
> SCALEUNIT["unity",1] because OrdinalCRS isn't composable with
> ProjectedCRS in current PROJ. Is there a better-supported pattern for this?

Perhaps a variant of the German "UTM zone 31N/32N/33N with zone prefix"
(CRS EPSG:5651/52/53) using false eastings of 31500000, 32500000, 33500000,
respectively, to force the first two digits of the easting to signify
the zone number

/Thomas

Den søn. 22. mar. 2026 kl. 15.32 skrev Ben Griffin via PROJ
<proj at lists.osgeo.org>:
>
> I am working on a CRS of the work I’ve been doing involved a series of novel projections. (The current python module is hhg9),
> My current  PROJ (C++) implementation shows an RTE (round-trip error) of about ~15nm - and has been extensively tested.
>
> The natural encoding of HEX9 a co-ordinate is hybrid, and involves a separation of the WGS84 ellipsoid into octants (carved at 0,90, etc).
> This lends itself to a 3-tuple x,y, octant_id. Therefore I am currently using
>
> PROJCRS["HEX9 Octahedral Barycentric",
>     BASEGEOGCRS["WGS 84”, …. ],
>     CONVERSION["H9 Octahedral Barycentric",
>         METHOD["PROJ h9_boct",
>             ID["HEX9","h9_boct"]]],
>     CS[Cartesian,3],
>         AXIS["hex9 x (X)",east,
>             ORDER[1],
>             LENGTHUNIT["metre",1]],
>         AXIS["hex9 y (Y)",north,
>             ORDER[2],
>             LENGTHUNIT["metre",1]],
>         AXIS["hex9 octant (O)",unspecified,
>             ORDER[3],
>             SCALEUNIT["unity",1]],
>     ID["HEX9","Oct”]]
>
> (This is the registration of the underlying continuous projection — the octant component plays the same role as, for example, a UTM zone number.
> The discrete hex-cell addressing scheme of the supported DGG built on top of this CRS is not what's being registered here).
>
> The octant component is ordinal/nominal, not a third spatial axis — there's no meaningful interpolation between octant 3 and octant 4. I'm encoding it as a 3rd Cartesian axis with orientation=unspecified and SCALEUNIT["unity",1] because OrdinalCRS isn't composable with ProjectedCRS in current PROJ. Is there a better-supported pattern for this?
> Is there any precedent for face-indexed projections (eg, HEALPix has the same issue — 12 faces, each with a local Cartesian frame)?  I considered using EngineeringCRS but that seems to be a mistake - it is strongly tied to WGS84, and lends itself better to DerivedGeographicCRS.
>
> So, the last axis is not strictly Z.
> The X, Y axes are also octant-specific and while X is ‘east’, and Y is on the north/south axis, the direction of north is inverted on some octants.
>
> I will be adding ProjectedCRS to the above base - but I thought it wise to post a line to the list at this point.
>
> Thoughts/Suggestions welcome!
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj