[PROJ] Synthetic Coordinate System

[Even Rouault]

Hi Ben,

I don't think PROJ API is the best fit for DGGS implementations. 
Probably https://github.com/ecere/dggal would be a better host (I 
haven't used it myself)

And AFAIK, WKT / ISO-19111 hasn't been designed with DGGS use cases in 
mind either.

Even

Le 22/03/2026 à 15:32, Ben Griffin via PROJ a écrit :
> 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

-- 
http://www.spatialys.com
My software is free, but my time generally not.