[PROJ] Questions about declaring a CRS

[Floris Vanderhaeghe]

Thank you for the helpful feedback!

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).

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).

  * 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).
  * 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.

So I guess '+towgs84' is also a feature that will remain?? (I ask 
because '+towgs84' and '+datum' are considered deprecated.)

Further, after comparing projinfo (in PROJ 7.2.1) and gdalsrsinfo (in 
GDAL 3.2.1), it can be seen that:

  * 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)
  * 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)
  * 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.

With regards,

Floris


Op 28/06/2021 om 18:38 schreef Martin Desruisseaux:
>
> Hello Floris
>
> If a choice is possible, I would encourage to use one of the 
> approaches recognized by international standards:
>
>   * Authority codes with axis order and units as defined by authority
>     (e.g. "EPSG:4326" is /latitude/, /longitude/; if the reverse order
>     is wanted then "CRS:84" can be used instead).
>   * Well Known Text version 2 (a.k.a. ISO 19162).
>   * Possibly the JSON format cited by Even in the future.
>
> PROJ 6 and later support all the above. I think they are preferable to 
> PROJ strings for at least 2 reasons:
>
>   * 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.
>   * 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.
>
> Regards,
>
>     Martin
>
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

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/20210629/9f8aecef/attachment.html>