[PROJ] Synthetic Coordinate System

[Javier Jimenez Shaw]

Hi Ben

I think I see your point. I have been recently developing some code related
to GBT and DGGS.
What I do not completely understand is how the face is part of the
projection, specially in PROJ. Yes, it can be easier to implement. However
all the other polyhedral projections in PROJ are doing the forward and
inverse transformation without relying on that information.
I think the projection in PROJ should be like the other ones, taking lat
and lon, and return x and y (and viceversa).
Deciding on with face is the point and what to do with it is a task for the
algorithm on top of it.

Cheers,
Javier

On Mon, 23 Mar 2026 at 21:22, Ben Griffin via PROJ <proj at lists.osgeo.org>
wrote:

> I am honoured to have met both of you, Even, Martin - and I really do
> value your respective thoughts;
> I have invested quite a bit of research time and work I’ve put into this
> project so far, and your opinions are really valuable.
>
> Martin, your points on ISO 19111/19112 are really well made.
>
> As I understand it - and I am happy to be corrected,  it appears that you
> are confirming that there is not (yet) an
> agreed standard as to what a DGGS should be in ISO terms.
>
> However, I feel that ISO 19112 (referencing by identifiers — "what cell am
> I in?") is a natural home for the DGGS addressing layer: given a location,
> return an
> identifier: That's the H9 address, the H3 index, the S2 cell ID… and it's
> a different question from "what are the coordinates of this location in the
> Hex9 projection?”
> — which is unambiguously ISO 19111 territory.
>
> My work - Hex9 - straddles both standards cleanly:
>   - The projection (continuous CRS) — ISO 19111
>   - The addressing system (H9 cell hierarchy) — ISO 19112
>
> It seems that most DGGS systems have historically conflated these two
> things.
>
> When I designed Hex9, it became clear that they are better refactored into
> genuinely separate layers which, while being architecturally unusual, feels
> arguably correct. (I chose to design the system so that the cell hierarchy
> is a consumer of the projection rather than intrinsic to it.  This, I feel,
> was a design decision with consequences: Any hierarchical resolution can
> sit on top of the same CRS without changing the projection.
>
> The PROJ plugin I am currently working on would implement the ISO 19111
> layer.
> The Python hhg9 package, and/or additional software libraries would
> implement the ISO 19112 layer on top of it.
>
> Hex9 is truly continuous (although both the python and the PROJ C++
> implementation hit machine epsilon limits).  The PROJ implementation
> achieves sub-25nm round-trip geodesic accuracy in current testing — the
> continuous nature of the CRS is not just theoretical.
>
> There is an additional question worth addressing directly: the CRS is
> octahedral, and the coordinate geometry is inherently triangular. The
> hexagonal cell structure arises as a precise consequence of that
> triangulation — it is not imposed on the projection but derived from it. I
> will  admit that in my own earlier documentation I conflated the projection
> geometry with the cell addressing, which likely contributed to the DGGS
> framing. That conflation was mine to make, not the architecture's — and
> separating them clearly is part of what this PROJ submission is intended to
> establish.
>
> Kind regards.
>  -Ben.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260323/31fc3d43/attachment.htm>