<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thank you for the helpful feedback!</p>
<p>Most geospatial R packages (such as sf, sp, stars, raster, terra)
accept the input that GDAL or PROJ accept, so using AUTHORITY:CODE
or WKT2 is no problem. I believe most developers follow that it is
to be advised (as do I, in the role of user).<br>
</p>
<p>On the other hand, an inconvenience that was raised is that
custom CRSs will need more work to specify, if not using PROJ
strings for that. Using a current standard is only 'convenient'
for registered CRSs (like: EPSG:27700).<br>
</p>
<ul>
<li>If I understand correctly, for PROJ strings to represent a
complete CRS, i.e. with a datum, this can either happen directly
by referring one of the remaining supported datums with '+datum'
(AFAIK wgs84, nad27 or nad83), or indirectly for all other
datums, as a BOUNDCRS (i.e. including a transformation to the
WGS84 datum).</li>
<li>While using '+towgs84' is not optimal, it seems the only way
if one still wants to use PROJ strings to properly define a
custom CRS, in the non-wgs84/nad27/nad83 case.</li>
</ul>
So I guess '+towgs84' is also a feature that will remain?? (I ask
because '+towgs84' and '+datum' are considered deprecated.)<br>
<p>Further, after comparing projinfo (in PROJ 7.2.1) and gdalsrsinfo
(in GDAL 3.2.1), it can be seen that:</p>
<ul>
<li>PROJ needs '+type=crs' in an inputted PROJ string to define a
CRS, otherwise it is seen as a coordinate operation (as expected
from most PROJ documentation)<br>
</li>
<li>GDAL seems to always interpret a PROJ string as a CRS, also
without '+type=crs'. This seems in contradiction with PROJ (but
maybe has its reasons)</li>
<li>both projinfo and gdalsrsinfo currently honour '+towgs84' in
the input (returning a BOUNDCRS), and repeat the exact same PROJ
string in the output (except that GDAL drops '+type=crs').
However '+towgs84' (as well as '+datum') is not in the returned
PROJ string if the input is AUTHORITY:CODE, so such PROJ strings
are partial CRS representations.<br>
</li>
</ul>
<p>With regards,</p>
<p>Floris<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Op 28/06/2021 om 18:38 schreef Martin
Desruisseaux:<br>
</div>
<blockquote type="cite"
cite="mid:485adbb2-a930-c4f2-0325-099565964572@geomatys.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">
<p>Hello Floris</p>
<p>If a choice is possible, I would encourage to use one of the
approaches recognized by international standards:</p>
<ul>
<li>Authority codes with axis order and units as defined by
authority (e.g. "EPSG:4326" is <i>latitude</i>, <i>longitude</i>;
if the reverse order is wanted then "CRS:84" can be used
instead).</li>
<li>Well Known Text version 2 (a.k.a. ISO 19162).</li>
<li>Possibly the JSON format cited by Even in the future.</li>
</ul>
<p>PROJ 6 and later support all the above. I think they are
preferable to PROJ strings for at least 2 reasons:</p>
<ul>
<li>They are portable, with WKT 2 possibly the safest bet for
now since it is an existing OGC and ISO standard. While PROJ
is the most popular, it is nevertheless not the only map
projection engine available, with each engine having their
advantage and inconvenient. Other map projection engines are
more likely to understand a CRS defined by international
standards than by PROJ-specific strings. Even if R uses only
PROJ, a R script may want to fetch data from a distant
server backed by a different map projection engine.</li>
<li>For educational reason: the PROJ string syntax evolved
from a system initially designed for map projections only,
not for the more general context of transformations between
arbitrary pairs of CRS. If users educate themselves by
learning from PROJ strings, there is a risk that they
confuse CRS with operations, that they believe that
"+towgs84" is good practice, etc.<br>
</li>
</ul>
<p>Regards,<br>
</p>
<p> Martin</p>
<p><br>
</p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<br>
<div class="moz-signature"
signature-switch-id="00c931c5-ac87-4320-bd6b-0311b8c0cbad">
<title>mailhandtekening</title>
<link rel="important stylesheet"
href="chrome://messagebody/skin/messageBody.css">
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<p><font color="#666666"><b
style="font-size:12.8px"><span
style="font-size:9pt;font-family:Verdana,sans-serif"
lang="EN-US">Floris Vanderhaeghe</span></b><br>
</font></p>
<p><font color="#666666"><span
style="font-size:9pt;font-family:Verdana,sans-serif">Flemish
Government<br>
RESEARCH INSTITUTE FOR NATURE AND FOREST<br>
</span><font face="Verdana, sans-serif"><span
style="font-size:12px">Team Biometry,
Methodology and Quality Assurance<br>
</span></font><span
style="font-family:Verdana,sans-serif;font-size:9pt">Havenlaan
88 bus 73, 1000 Brussels<br>
Belgium<br>
</span><span
style="font-size:9pt;font-family:Verdana,sans-serif"><a
href="mailto:floris.vanderhaeghe@inbo.be"
style=""><font color="#666666">floris.vanderhaeghe@inbo.be</font></a><br>
</span><a href="http://www.inbo.be/"
title="http://www.inbo.be/
blocked::http://www.inbo.be/"
target="_blank"
style="font-family:Verdana,sans-serif;font-size:9pt"><font
color="#666666">www.inbo.be</font></a></font></p>
<div
style="color:rgb(136,136,136);font-size:12.8px"><span
style="font-family:verdana,sans-serif"><font
size="1" color="#666666">///////////////////////////////////////////////////////////////////////////////////////////</font></span></div>
<div
style="color:rgb(136,136,136);font-size:12.8px"><span
style="font-family:verdana,sans-serif"><font
size="1"><br>
</font></span></div>
<div
style="color:rgb(136,136,136);font-size:12.8px"><span
style="font-family:verdana,sans-serif"><br>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</body>
</html>