<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<p>Below are some questions about the usage of 'PROJ strings' (as
opposed to using WKT or AUTHORITY:CODE) as an option to declare
the CRS of coordinates. The context is geospatial work in R with
PROJ >= 6, the fact that users <i>can</i> still input PROJ
strings to declare an object's CRS, and the question what to
advise to users. We already had some discussions on this in the
R-spatial community, which lead me to posing some questions here.<br>
</p>
<p>After reading through several PROJ documentation pages, and
observing output from 'projinfo':</p>
<ol>
<li>It is clear that currently, support for representing a CRS by
using a PROJ string is only partial, especially because the
datum can often not be specified. ==> <b>QUESTION</b>: <u>Is
specifying a CRS with a PROJ string going to receive continued
support, or will it eventually be dropped? And related with
that, </u><u>[<b>QUESTION</b>:]
should we still advertise and use it to represent a CRS?</u>
The current state may appear somewhat unclear:</li>
<ul>
<li>There is support for '+type = crs' (to declare a CRS)</li>
<ul>
<li>e.g. projinfo does accept a PROJ string as input to
represent a CRS, by inclusion of '+type=crs'<br>
</li>
</ul>
<li>There is (still) support for '+towgs84' (to declare a
BOUNDCRS, hence not defining the datum directly)</li>
<ul>
<li>Cf. mention of '+towgs84' in the context of a pipeline, in
<a class="moz-txt-link-freetext"
href="https://proj.org/operations/operations_computation.html#when-the-source-or-target-crs-is-a-boundcrs"
moz-do-not-send="true">https://proj.org/operations/operations_computation.html#when-the-source-or-target-crs-is-a-boundcrs</a><br>
</li>
<li>'+towgs84' can be still used in a PROJ string that
represents just a CRS (combining '+towgs84=' and
'+type=crs')</li>
</ul>
<li>However, PROJ strings are now generally described in the
documentation as representing a coordinate operation,
including datum <i>shifts</i> when using a pipeline string.
That is, the pipeline itself does not define input and output
datums, but may contain a transformation step to perform a
datum shift.</li>
<li>In several places the <i>deprecation</i> of '+towgs84' is
referred --> <b>QUESTION</b>: <u>will '+towgs84' be
dropped eventually? </u></li>
<li>Although using '+type = crs', the datum cannot be specified:
it is WGS84 when no '+ellps' is provided, and else 'unknown'.
But with an unknown datum, the CRS is incomplete. <b>QUESTION</b>:
<u>Will</u><u> '+type = crs' get continued support, or is it
intended to eventually end support for '+type=crs'?</u></li>
<li>A comment in the second code chunk under <a
class="moz-txt-link-freetext"
href="https://proj.org/development/migration.html#code-example"
moz-do-not-send="true">https://proj.org/development/migration.html#code-example</a>
clearly disrecommends PROJ strings to define a CRS (as opposed
to WKT or AUTHORITY:CODE), but generally this advice seems
rather sparse in the documentation. In fact, the
still-supported use of a PROJ string to define a CRS is only
touched under <a
href="https://proj.org/development/reference/functions.html#c.proj_create"
moz-do-not-send="true">proj_create()</a> and discouraged.</li>
</ul>
<li><i>If PROJ strings should not be used to define a CRS, then: </i>[<b>QUESTION</b>:]
<u>is it possible, with currently advised methods, to define a </u><u><i>custom</i></u><u>
CRS in a relatively short way</u>, i.e. not having to write
out a full WKT? Perhaps having the possibility to refer an
authority CRS (just using its code or name), and a way to alter
specific (WKT?) parameters, could work, although I don't know
whether specification of the second part can be standardised
easily.</li>
</ol>
<p>Thanks in advance! I am not an experienced PROJ user.<br>
</p>
<p>With regards,</p>
<p>Floris</p>
<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</span><span
style="font-size:9pt;font-family:Verdana,sans-serif"><br>
<a href="mailto:floris.vanderhaeghe@inbo.be"
style="" moz-do-not-send="true"><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"
moz-do-not-send="true"><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"><font
size="1"><img
src="cid:part6.FF2AF5AC.2C30ACD5@inbo.be"
alt="" class="" width="346" height="44"></font></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</body>
</html>