[PROJ] Questions about declaring a CRS

[Floris Vanderhaeghe]

Hi,

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 /can/ 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.

After reading through several PROJ documentation pages, and observing 
output from 'projinfo':

 1. 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. ==> *QUESTION*: _Is specifying a CRS with a
    PROJ string going to receive continued support, or will it
    eventually be dropped? And related with that, __[*QUESTION*:] should
    we still advertise and use it to represent a CRS?_ The current state
    may appear somewhat unclear:
      * There is support for '+type = crs' (to declare a CRS)
          o e.g. projinfo does accept a PROJ string as input to
            represent a CRS, by inclusion of '+type=crs'
      * There is (still) support for '+towgs84' (to declare a BOUNDCRS,
        hence not defining the datum directly)
          o Cf. mention of '+towgs84' in the context of a pipeline, in
            https://proj.org/operations/operations_computation.html#when-the-source-or-target-crs-is-a-boundcrs
          o '+towgs84' can be still used in a PROJ string that
            represents just a CRS (combining '+towgs84=' and '+type=crs')
      * However, PROJ strings are now generally described in the
        documentation as representing a coordinate operation, including
        datum /shifts/ 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.
      * In several places the /deprecation/ of '+towgs84' is referred
        --> *QUESTION*: _will '+towgs84' be dropped eventually? _
      * 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. *QUESTION*:
        _Will__'+type = crs' get continued support, or is it intended to
        eventually end support for '+type=crs'?_
      * A comment in the second code chunk under
        https://proj.org/development/migration.html#code-example 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 proj_create()
        <https://proj.org/development/reference/functions.html#c.proj_create>
        and discouraged.
 2. /If PROJ strings should not be used to define a CRS, then:
    /[*QUESTION*:] _is it possible, with currently advised methods, to
    define a __/custom/__CRS in a relatively short way_, 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.

Thanks in advance! I am not an experienced PROJ user.

With regards,

Floris


mailhandtekening

*Floris Vanderhaeghe*

Flemish Government
RESEARCH INSTITUTE FOR NATURE AND FOREST
Team Biometry, Methodology and Quality Assurance
Havenlaan 88 bus 73, 1000 Brussels
Belgium
floris.vanderhaeghe at inbo.be <mailto:floris.vanderhaeghe at inbo.be>
www.inbo.be <http://www.inbo.be/>

///////////////////////////////////////////////////////////////////////////////////////////


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210628/bfdf66d3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dahbgdngngpfdomg.png
Type: image/png
Size: 6484 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210628/bfdf66d3/attachment-0001.png>