<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><blockquote type="cite">ah ok I jumped too far to conclusion seeing DGGS mentioned. I
read too quickly and am not familiar with HEX9.<br></blockquote><div>:-) It’s a rite of passage for me with this work. I need to write it on my forehead, I guess. </div><br><blockquote type="cite"><div><div><p>Do you plan to submit your work to PROJ upstream?</p></div></div></blockquote><div>If there is interest, then yes - definitely. I personally believe that the system has a lot to offer; like any projection, it’s not a universal solution - but it certainly offers benefits for those who are looking at developing well-defined binning strategies that rest upon strong mathematical foundations.</div><blockquote type="cite"><div><div><p>I don't think it would make sense in the PROJ API to report the
octant number in PROJ_COORD or in WKT, since it isn't needed to
unambiguously qualify a location: just X and Y are sufficient,
right ?</p></div></div></blockquote></div><div>There are two major approaches here - the underlying structure is the unit octahedron - the fundamental CRS converts WGS<->Unit Octahedron with high fidelity. However, the way in which we visualise is mainly on the 2D plane, so then each side / octant of the Unit Octahedron must be rotated onto the 2D plane - and then (via rigid transforms) placed with the other sides into a net or similar map.</div><div><br></div><div>The projection engine itself works directly from the WGS longitude/latitude to the 2D plane - but each face of the octahedron is centred on the origin. Therefore, there is an ambiguity arising as to which face is being looked at without some means of octant identity.</div><div><br></div><div>One may further suggest that I nominate a 2D projection (like the ‘butterfly’ projection linked to earlier) - but then that adds a discontinuity on the edges of the map which are not ‘felt’ in the 3D representation. </div><div><br></div><div>I can project the 2D+octant back down to the 3D xyz octahedral surface - but the approach is adding the matrix transform just for the sake of data storage / WKT declaration - as it is the 2D projection derivatives that are of interest.</div><div><br></div><div>Again, the challenge with 3D is that there could be a presumption that the underlying shape is ellipsoidal - where it is not - although it is (currently) strongly dependent upon WGS 84 (both via the analytic calculations and the warp matrix). Therefore, it feels better and more suitable to go for an [X,Y, Octant] scheme.</div><div><br></div><div>Anyway - my post was me wondering aloud if the approach (X, Y, Octant) is considered reasonable. </div><div><br></div><div><br></div></body></html>