<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear PROJ community,</p>
<p>I recently had the chance to integrate an implementation of the
inverse transformation for the <a
href="https://proj.org/en/9.4/operations/projections/isea.html">Icosahedral
Snyder Equal-Area (ISEA) projection</a> (<a
href="https://github.com/OSGeo/PROJ/pull/4211">PR #4211</a>
which was recently merged).</p>
<p>Doing so resulted in some initial re-factoring to share code
between the forward and inverse projection.</p>
<p><b>Deprecating grid parameters</b><br>
</p>
<p>During this process, I realized that several parameters for the
projection (+proj=isea) really have nothing to do with the
projection itself, but are parameters for constructing discrete
global grids on top of an ISEA projection.<br>
<br>
In fact, <a
href="https://github.com/OSGeo/PROJ/blob/master/src/projections/isea.cpp#L931">the
code applying these parameters</a> happens as a later step after
the default planar projection (with the exception of the trivial <a
href="https://github.com/OSGeo/PROJ/blob/master/src/projections/isea.cpp#L656">isea_tri_plane()</a>).</p>
<p>Therefore, I suggest this code really does not belong in the PROJ
library, but outside, in the implementation of a discrete global
grid system, such as in libraries like <a
href="https://github.com/sahrk/DGGRID">DGGRID</a> and <a
href="https://github.com/mocnik-science/geogrid/">geogrid</a>,
and these parameters should be deprecated.</p>
<p>In addition:</p>
<p>- there is no documentation at all for the parameters and they
are very poorly understood,<br>
- there are no existing tests for these parameters,<br>
- the new inverse transformation does not support these
parameters.</p>
<p>The three parameters proposed for deprecation are:</p>
<p><b>+mode</b> which can be set to <i>plane</i> (the default), <i><b>di</b></i>,
<b><i>dd</i></b>, or <i><b>hex</b></i><br>
The default mode is <i>plane</i> which would become the
only thing supported.<br>
<br>
<i>hex</i> referred to returning coordinates related to a
hexagonal grid, but it is really not clear.<br>
<i>di</i> and <i>dd</i> seemed to refer to a rhombus
grid, in a way very similar to the approach we use for an <a
href="https://docs.ogc.org/DRAFTS/21-038.html#isea9r-dggrs">ISEA9R
DGGRS</a> (or ISEA4R for a quad-tree).<br>
The ISEA planar projection can be very easily transformed
to a space where icosahedron triangles merge into 10 axis-aligned
rhombuses by applying a 60 degrees rotation and 30 degrees
horizontal shearing, which can be done with +proj=affine.<br>
This seems to be what <a
href="https://github.com/OSGeo/PROJ/blob/master/src/projections/isea.cpp#L669">isea_ptdd()</a>
is doing for <i>dd</i>.<br>
<i>di</i> seems to be referring to an extra step done in
<a
href="https://github.com/OSGeo/PROJ/blob/master/src/projections/isea.cpp#L849">isea_ptdi()</a>.
I have no idea what this is doing.</p>
<p><b>+aperture</b> which is the aperture (refinement ratio) of the
discrete global grid for those di, dd and hex modes</p>
<p><b>+resolution</b> which I am not sure how it affects the di, dd,
and hex modes, but is only used with those modes proposed for
deprecation</p>
<p>Systems using these parameters could still extract the code for
these extra steps in its <a
href="https://github.com/OSGeo/PROJ/blob/2ce6c7a9b1ca44b8a7cfb1acca7ff10c8c616774/src/projections/isea.cpp">current
state</a>, and invoke as an extra step after the planar
projection (after undoing the trivial 180 deg rotation and
translation that <a
href="https://github.com/OSGeo/PROJ/blob/master/src/projections/isea.cpp#L656">isea_tri_plane()</a>
is doing).<br>
</p>
<p>If you make use of these parameters and object to their
deprecation, please reply with feedback.<br>
I plan to submit a pull request for a staged deprecation, which
first mentions in the documentation that these parameters will be
deprecated in a future version.<br>
</p>
<p>On the flip side, I hope to eventually contribute support for the
remaining <b>+azi</b>= parameter not yet supported by the inverse
projection (which allows support for orientations such as the R.
Buckminster Fuller's Dymaxion Orientation).<br>
Possibly also eventually allowing to specify an arbitrary latitude
and longitude for the first icosahedron vertex, as opposed to the
two available options of +orient=pole and +orient=isea with fixed
values.<br>
</p>
<p><b><br>
Proposing to interpret input latitude as authalic latitude</b><br>
</p>
<p>As <a
href="https://github.com/OSGeo/PROJ/pull/4211#issuecomment-2275206640">discussed
in the PR</a>, the ISEA projection is only defined on a sphere.</p>
<p>Although I clarified this in the <a
href="https://osgeo-proj--4211.org.readthedocs.build/en/4211/operations/projections/isea.html">documentation</a>,
the most common use case is having geodetic WGS84 latitude and
longitude coordinates which you want to project to the ISEA planar
projection.</p>
<p>This includes the use case of integrating data into a discrete
global grid system using a DGGRS based on the ISEA projection,
such as ISEA3H or ISEA9R.</p>
<p>Before applying the spherical projection with a sphere whose
surface area is the same as the GRS80 or WGS84 ellipsoid (authalic
sphere), the geodetic latitude should be converted to an <a
href="https://en.wikipedia.org/wiki/Latitude#Authalic_latitude">authalic
latitude</a>.<br>
</p>
<p>This is already done by PROJ in other projections, including the
Lamber Azimuthal Equal-Area projection of which ISEA is modified
form, if I understand correctly (see
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/blob/master/src/projections/laea.cpp#L38">https://github.com/OSGeo/PROJ/blob/master/src/projections/laea.cpp#L38</a>
and
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/pull/4211#issuecomment-2284383509">https://github.com/OSGeo/PROJ/pull/4211#issuecomment-2284383509</a> ).<br>
</p>
<p>I propose that the geodetic latitude be automatically converted
to an authalic latitude when using the projection with a
non-spherical ellipsoid (which is the default, and therefore
currently quite prone to misuse).</p>
<p>Please reply if you see any issue with this change, for which I
also plan to submit a pull request.</p>
<p>Thank you very much!</p>
<p>Kind regards,</p>
<p>-Jerome<br>
<br>
</p>
</body>
</html>