[PROJ] Units in a derived system
Javier Jimenez Shaw
j1 at jimenezshaw.com
Thu Aug 4 09:37:45 PDT 2022
Hi Even. I have been testing your branch (I hope correctly) with the method
"Affine parametric transformation". Whit this derived CRS (very similar to
the previous example)
DERIVEDPROJCRS["derived from EPSG:6507",
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",
METHOD["Affine parametric transformation",
ID["EPSG",9624]],
PARAMETER["A0",42,
LENGTHUNIT["US survey foot",0.304800609601219],
ID["EPSG",8623]],
PARAMETER["A1",1,
SCALEUNIT["coefficient",1],
ID["EPSG",8624]],
PARAMETER["A2",0,
SCALEUNIT["coefficient",1],
ID["EPSG",8625]],
PARAMETER["B0",999,
LENGTHUNIT["US survey foot",0.304800609601219],
ID["EPSG",8639]],
PARAMETER["B1",0,
SCALEUNIT["coefficient",1],
ID["EPSG",8640]],
PARAMETER["B2",1,
SCALEUNIT["coefficient",1],
ID["EPSG",8641]]],
CS[Cartesian,2],
AXIS["(Y)",north,
ORDER[1],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003]]],
AXIS["(X)",east,
ORDER[2],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003]]]]
and I get these transformations:
$ projinfo -s "EPSG:6507" -t "$(cat derived.wkt)" -o proj -q
+proj=pipeline
+step +proj=unitconvert +xy_in=us-ft +xy_out=m
+step +proj=affine +xoff=42 +s11=1 +s12=0 +yoff=999 +s21=0 +s22=1
$ projinfo -s "EPSG:6318" -t "$(cat derived.wkt)" -o proj -q
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +proj=tmerc +lat_0=29.5 +lon_0=-88.8333333333333 +k=0.99995
+x_0=300000
+y_0=0 +ellps=GRS80
+step +proj=affine +xoff=42 +s11=1 +s12=0 +yoff=999 +s21=0 +s22=1
The first case is just applying the derived conversion because the input is
"the same" as the base (well, I swapped the axes). If I understood
correctly "+xy_out=m" is converting to meters, so the affine operation is
done in meters easting-northing, regardless the unit I wrote in the
parameters. But nothing is done later (like correcting the out units an
order as in your PR)
On the second command, where the input is geographic coordinates, the input
for the affine is also meters, but no conversion at the end.
Am I right?
Thanks.
PS what if I make a compound of a derived projected and vertical? Is that a
problem?
.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.
On Thu, 4 Aug 2022 at 18:09, Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:
> 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/61967256/attachment-0001.htm>
More information about the PROJ
mailing list