[PROJ] Synthetic Coordinate System

[Ben Griffin]

Hi Even,
Thank-you for your thoughts.

As mentioned in my OP, the CRS isn’t a DGGS. It is a continuous CRS that acts as the backbone for a DGGS.
Consider, please, the net projections that are run using the current system (albeit via the python module).

https://raw.githubusercontent.com/MrBenGriffin/hex9/refs/heads/main/images/rhombus.jpg 

Or

https://raw.githubusercontent.com/MrBenGriffin/hex9/refs/heads/main/images/butterfly.jpg

Those are projections under the CRS declared in the OP - they are not representative of a DGGS.
I’m not denying that the CRS is related to (and supports) DGGS - but it is not a DGGS.

The query concerned how best to capture a global coordinate that involves an octahedral scheme - It feels like you picked up on something else.
One of the aspects of this, which to me feels the most obvious, is that a CRS is continuous, while a DGGS is not.

I feel that my position on this is defensible.

Best regards
	Ben.

> On 22 Mar 2026, at 16:47, Even Rouault <even.rouault at spatialys.com> wrote:
> 
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260322/db3dcd3f/attachment.htm>