[PROJ] Units in a derived system
Even Rouault
even.rouault at spatialys.com
Thu Aug 4 09:29:55 PDT 2022
Le 04/08/2022 à 18:09, Javier Jimenez Shaw a écrit :
> 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)
yes
> b) In this case transverse mercator returns meters (the input unit for
> the operation method). Is that the case for every projection?
yes
> 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.
yes
>
> 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.
yes
> 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.
It depends... When creating PROJ pipelines at hand, you can trick PROJ
to do "non-standard" things, and if you know that your input/output is
us-ft, using a xoff= in us-ft will work given that it is a simple
addition, and thus works as soon as you use consistent units for the
step parameter and the input coordinates. But in general, you should use
the units advertized in the documentation of the PROJ operation method.
In particular, when embeding a PROJ string into a DERIVINGCONVERSION
> 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 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.
>
--
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/819597ff/attachment.htm>
More information about the PROJ
mailing list