[PROJ] Questions about declaring a CRS
Even Rouault
even.rouault at spatialys.com
Mon Jun 28 08:15:58 PDT 2021
Floris,
I believe we'll have to support indefinitely PROJ.4 style CRS strings
since there are "everywhere", at least from a legacy point of view.
They're for example included in some geospatial datasets to define their
CRS (netCDF, other formats handled by GDAL). They have clearly some
limitations, but are sufficient for many use cases.
I'd suggest looking at PROJJSON
(https://proj.org/specifications/projjson.html), which is a JSON-ified
version of WKT, with the same expressiveness but a less awkward syntax.
It is not yet standardized, but there's an effort just starting to make
it a OGC standard/community standard.
Even
Le 28/06/2021 à 16:47, Floris Vanderhaeghe via PROJ a écrit :
> 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/>
>
> ///////////////////////////////////////////////////////////////////////////////////////////
>
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210628/e1c398e3/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/e1c398e3/attachment-0001.png>
More information about the PROJ
mailing list