<div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;">Hi Jérôme,</div><div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;"><br></div><div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;">this is all very logical, dropping those DGGS paramaters and adding azi= instead.</div><div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;"><br></div><div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;">I wonder whether the angular coordinates interpretation shouldn't also be left to the user to decide. Eventually with the authalic transformation as default behaviour.</div><div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;"><br></div><div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;">Regards.</div>
<div class="protonmail_signature_block" style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;">
<div class="protonmail_signature_block-user">
<div><br></div><div>-- <br></div><div>Luís Moreira de Sousa</div><div>Mastodon: <span><a href="https://mastodon.social/@luis_de_sousa" rel="noreferrer nofollow noopener" target="_blank">https://mastodon.social/@luis_de_sousa</a></span><br></div><div>URL: <a href="https://ldesousa.codeberg.page">https://ldesousa.codeberg.page</a></div>
</div>
<div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;"><br></div>
<div class="protonmail_signature_block-proton">
Sent with <a target="_blank" href="https://proton.me/">Proton Mail</a> secure email.
</div>
</div>
<div style="font-family: Menlo, Consolas, Courier New, Monospace; font-size: 14px;"><br></div><div class="protonmail_quote">
On Saturday, 24 August 2024 at 15:36, Jérôme St-Louis via PROJ <proj@lists.osgeo.org> wrote:<br>
<blockquote class="protonmail_quote" type="cite">
<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" target="_blank" rel="noreferrer nofollow noopener">Icosahedral
Snyder Equal-Area (ISEA) projection</a> (<a href="https://github.com/OSGeo/PROJ/pull/4211" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">DGGRID</a> and <a href="https://github.com/mocnik-science/geogrid/" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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" target="_blank" rel="noreferrer nofollow noopener">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 href="https://github.com/OSGeo/PROJ/blob/master/src/projections/laea.cpp#L38" class="moz-txt-link-freetext" target="_blank" rel="noreferrer nofollow noopener">https://github.com/OSGeo/PROJ/blob/master/src/projections/laea.cpp#L38</a>
and
<a href="https://github.com/OSGeo/PROJ/pull/4211#issuecomment-2284383509" class="moz-txt-link-freetext" target="_blank" rel="noreferrer nofollow noopener">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>
</blockquote><br>
</div>