[PROJ] Units in a derived system

Thu Aug 4 09:09:48 PDT 2022

Thank you Even!

To confirm that I understood your changes and how to use it.
a) the PROJ-based operation method must work in meters and easting-northing
(converting from-meters at the beginning and to-meters at the end if I want
to keep my values unchanged)
b) In this case transverse mercator returns meters (the input unit for the
operation method). Is that the case for every projection?
c) your changes add a unit conversion and a swap axis if needed at the end.
That will produce a sensible output even with a no-op toperation (like
xoff=0) But as said in a), it is not affecting the units and order of the
operation method.

Does this apply to other derived operations, like "Affine parametric
transformation"
https://epsg.org/coord-operation-method_9624/Affine-parametric-transformation.html
? I guess it may have a similar problem.
I do not have clear if the parameters of "Affine parametric transformation"
must be in the meters, in the same unit as the system, or it is
transforming it depending on the value in the WKT2.
I will use your branch and try an example.

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.

On Thu, 4 Aug 2022 at 17:14, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
> I have had a bit of hesitation if the current behaviour was a feature or a
> bug, and opted for the later while investigating what happened: the axis
> unit and order of the source CRS (projected CRS) were well taken into
> account to "normalize" to metre, easting/northing order before applying the
> user provided PROJ string, but the axis unit and order of the target CRS
> (derived projected CRS) were ignored.
>
> I've addressed this per https://github.com/OSGeo/PROJ/pull/3281 . It
> might potentially break people that have compensated for that, but I feel
> it is such a marginal use case that fixing it is the best thing.
>
> Note however that you must adjust your PROJ string: xoff must be expressed
> in meters. So you should change xoff to 65.6166666666667. Or do like I did
> in the test I added, that is convert xy from m (as I said above, PROJ
> normalizes to (resp. from) metre, easting/northing  each step before (resp.
> after) applying the user PROJ string) to us-ft, then apply the affine with
> xoff=20, and finally convert back from us-ft to xy.
>
> Even
>
>
> Le 03/08/2022 à 19:52, Javier Jimenez Shaw a écrit :
>
> Hi
>
> I am trying to make a derived projected CRS... in feet.
> The conversion method is a "PROJ-based operation method" with an affine
> transformation (simplified here with just xoff of 20 feet).
> https://proj.org/operations/transformations/affine.html
>
> The derived system is something like this (my data is 3D, but in 2D is
> also reproduced):
>
> $ cat derived.wkt
>
> DERIVEDPROJCRS["Custom Site Calibrated CRS",
>     BASEPROJCRS["NAD83(2011) / Mississippi East (ftUS)",
>         BASEGEOGCRS["NAD83(2011)",
>             DATUM["NAD83 (National Spatial Reference System 2011)",
>                 ELLIPSOID["GRS 1980",6378137,298.257222101,
>                     LENGTHUNIT["metre",1]]],
>             PRIMEM["Greenwich",0,
>                 ANGLEUNIT["degree",0.0174532925199433]]],
>         CONVERSION["SPCS83 Mississippi East zone (US Survey feet)",
>             METHOD["Transverse Mercator",
>                 ID["EPSG",9807]],
>             PARAMETER["Latitude of natural origin",29.5,
>                 ANGLEUNIT["degree",0.0174532925199433],
>                 ID["EPSG",8801]],
>             PARAMETER["Longitude of natural origin",-88.8333333333333,
>                 ANGLEUNIT["degree",0.0174532925199433],
>                 ID["EPSG",8802]],
>             PARAMETER["Scale factor at natural origin",0.99995,
>                 SCALEUNIT["unity",1],
>                 ID["EPSG",8805]],
>             PARAMETER["False easting",984250,
>                 LENGTHUNIT["US survey foot",0.304800609601219],
>                 ID["EPSG",8806]],
>             PARAMETER["False northing",0,
>                 LENGTHUNIT["US survey foot",0.304800609601219],
>                 ID["EPSG",8807]]]],
>     DERIVINGCONVERSION["Affine transformation as PROJ-based",
>         METHOD["PROJ-based operation method: +proj=pipeline +step
> +proj=affine +xoff=20"]],
>     CS[Cartesian,2],
>         AXIS["easting (X)",east,
>             ORDER[1],
>             LENGTHUNIT["US survey foot",0.304800609601219]],
>         AXIS["northing (Y)",north,
>             ORDER[2],
>             LENGTHUNIT["US survey foot",0.304800609601219]],
>     REMARK["EPSG:6507 with 20 feet offset"]]
>
> But the output I get seems to be in meters (I deduced that running with
> PROJ_DEBUG=3) It is kind of ignoring the CS.
> $ echo 29 -88 0 | cs2cs EPSG:6318 EPSG:6507
> 1250642.38 -180875.29 0.00
> $ echo 29 -88 0 | cs2cs EPSG:6318 "$(cat derived.wkt)"
> 381216.56 -55130.90 0.00
>
> If I concatenate the pipeline with cct, I get the result I was expecting
> (20 feet more in the x):
> $ echo 29 -88 0 | cs2cs EPSG:6318 EPSG:6507 | cct +proj=pipeline +step
> +proj=affine +xoff=20
> 1250662.3800   -180875.2900        0.0000
>
> Is that expected? Am I doing anything wrong?
>
> Thanks.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://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/20220804/278a5f72/attachment-0001.htm>