<div dir="ltr"><div dir="ltr"><div>Thanks Even.</div><div><br></div><div>I tried to show two things in the example about "Affine parametric transformation", if I understood correctly the results.</div><div>a)
it was not considering the units of the parameters, and using always
meters. You already said that it is not clear in the EPSG guidance. (I
can use always meters in the parameters in case of doubt. It should be
the safe).<br></div><div>b) the final output of the derived crs is in
meters easting-northing, regardless the axis defined. I do not know if
you noticed that.</div><div><br></div><div><br></div><div>Related to b), I have been thinking on the derived vertical. I tested this in your branch and seems to work properly<div><br></div><div><span style="font-family:monospace">VERTCRS["Custom Vertical",<br> BASEVERTCRS["NAVD88 height (ftUS)",<br> VDATUM["North American Vertical Datum 1988"]],<br> DERIVINGCONVERSION["vertical offs",<br> METHOD["Vertical Offset",<br> ID["EPSG",1046]],<br> PARAMETER["Vertical Offset",2,<span><br> LENGTHUNIT["US survey foot",0.304800609601219],<br></span> ID["EPSG",8603]]],<br> CS[vertical,1],<br> AXIS["gravity-related height (H)",up,<span><br> LENGTHUNIT["US survey foot",0.304800609601219]],<br></span> USAGE[<br> SCOPE["unknown"],<br> AREA["World"],<br> BBOX[-90,-180,90,180]]]</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">$ projinfo -s EPSG:3855 -t "$(cat v.wkt)" -o proj -q<br>+proj=pipeline<br> +step +proj=vertoffset +lat_0=0 +lon_0=0 +dh=0.609601219202438 +slope_lat=0<br> +slope_lon=0<br> +step +proj=unitconvert +z_in=m +z_out=us-ft</span></div><div><br></div><div><span style="font-family:monospace">$ projinfo -s EPSG:6360 -t "$(cat v.wkt)" -o proj -q<br>+proj=pipeline<br> +step +proj=unitconvert +z_in=us-ft +z_out=m<br> +step +proj=vertoffset +lat_0=0 +lon_0=0 +dh=0.609601219202438 +slope_lat=0<br> +slope_lon=0<br> +step +proj=unitconvert +z_in=m +z_out=us-ft</span></div><div><br></div><div>It not only converts to us-ft at the end, but also understands the units in the parameter. Cool.</div></div><span><div><div><div dir="ltr"><br></div><div dir="ltr"><br></div></div></div></span><div><div dir="ltr" data-smartmail="gmail_signature">.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... .... ._ .__<br>Entre dos pensamientos racionales <br>hay infinitos pensamientos irracionales.<br><br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Aug 2022 at 19:10, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hum, it seems I was too fast about "Affine parametric
transformation". The implementation in PROJ voluntarily ignores
the unit specified to the A0/A1/A2/B0/B1/B2 and takes the value as
it, and the axis order. I'm not completely if it is the right
thing to do, but EPSG guidance 7-2 note isn't super clear about
what to do. In their example, they use metre unit for A0 and B0,
to go from a CRS in Clarke's foot to a CRS in metres. The value of
the A1 and B2 scaling coefficient is close to the conversion
factor of Clarke's foot to metre (but slightly different). PROJ
reproduces the expected transformation on that example. We don't
have an example of what we should do if the transformation
parameter units aren't metre/coefficient (I see that there's a
deprecated EPSG:10088 transformation that uses Clarke's foot but
we can't ask it for comparison as the deprecation comment mentions
that there was an error in coefficient values). I let you ask IOGP
if you wish to clear that up. But in the meantime, you'd be better
assuming that there's no unit transformation done for that
particular method. Doh, coordinate transformations are hard and
confusing :-)<br>
</p>
<div>Le 04/08/2022 à 18:37, Javier Jimenez
Shaw a écrit :<br>
</div>
<br>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div></div>