<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Luís,</p>
<p>Thanks for the input.<br>
</p>
<div class="moz-signature">
<blockquote type="cite">adding azi= instead.</blockquote>
To be clear, the +azi= parameter is already there for the forward
projection, just not in the new inverse yet.<br>
</div>
<div class="moz-signature"><br>
<blockquote type="cite">
<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>
</blockquote>
</div>
<div class="moz-signature">Do you mean by introducing an additional
parameter? I don't think this should be necessary, and I think it
would go against how ellipsoids are generally handled for all
projections in PROJ.<br>
<br>
If using a perfectly spherical ellipsoid, all types of latitudes
are the same.<br>
<br>
The bold title I used for that section of my last e-mail was
confusing, sorry.<br>
<br>
What I meant is that if an oblate spheroid ellipsoid is used
(which is the default if you don't specify any ellipsoid parameter
e.g., simply saying +proj=isea), then the latitude should be
interpreted as geodetic latitude, but it should be transformed to
an authalic latitude prior to applying the ISEA projection which
is only defined on a sphere, just like it is already being done
for Lambert Azimuthal Equal-Area. This is the only correct thing
to do I believe.</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">Some systems do, arguably incorrectly,
take the geodetic latitude, and directly apply the ISEA spherical
projection pretending that latitude is already the authatlic
latitude on the sphere.</div>
<div class="moz-signature">This could still be done with PROJ simply
by specifying +R=6371007.18091875, and still giving the same
geodetic latitude as input.<br>
</div>
<div class="moz-signature"><br>
Other systems (still arguably incorrectly, like ours currently)
convert the geodetic latitude to geocentric latitude before
applying the ISEA projection.<br>
This could still be achieved by specifying +proj=pipeline +step
+proj=geoc +step +proj=isea +R=6371007.18091875</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">Therefore I think even these incorrect
interpretations could still be explicitly specified by the user,
using the non-projection-specific PROJ mechanisms, without the
introduction of a projection-specific parameter.</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">But the default when using a
non-spherical ellipsoid would be the correct way of first
transforming geoetic latitude to authalic latitude.<br>
</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">I hope that makes sense.</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">Kind regards,</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">-Jerome<br>
<br>
</div>
<div class="moz-cite-prefix">On 8/27/24 5:20 AM, Luí s Moreira de
Sousa wrote:<br>
</div>
<blockquote type="cite"
cite="mid:MZfP2VtGCKEtOijfZE4tgDofp-TZ2icS7aeeaDBN9ejPGfBNedwpLEW8yxa5dFxz64VudF8QXJ4tKsAOyc1_XwZB8yGkZBgOFh66X2IoM1c=@protonmail.ch">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">https://mastodon.social/@luis_de_sousa</a></span><br>
</div>
<div>URL: <a href="https://ldesousa.codeberg.page"
moz-do-not-send="true" class="moz-txt-link-freetext">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/"
moz-do-not-send="true">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 <a class="moz-txt-link-rfc2396E" href="mailto:proj@lists.osgeo.org"><proj@lists.osgeo.org></a>
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"
moz-do-not-send="true">Icosahedral Snyder Equal-Area
(ISEA) projection</a> (<a
href="https://github.com/OSGeo/PROJ/pull/4211"
target="_blank" rel="noreferrer nofollow noopener"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">DGGRID</a>
and <a href="https://github.com/mocnik-science/geogrid/"
target="_blank" rel="noreferrer nofollow noopener"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</blockquote>
</body>
</html>