<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Pierre,</p>
<p>This is a complicated "equation" due to WGS 84 being a
dynamic/non-plate-fixed datum and GDA94 & GDA2020 being
static/plate-fixed<br>
</p>
<p>- WGS 84 ~= GDA94 at epoch 1994.0, that is the transformation
between both is the identity<br>
</p>
<p>- WGS 84 ~= GDA2020 at epoch 2020.0, that is the transformation
between both is the identity</p>
<p>- but GDA94 and GDA2020 have a ~= 1.8 shift, that is modeled
either as a Helmert transformation or with one of the 2 available
GDA94-GDA2020 shift grids, all of them available in PROJ
(<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ-data/tree/master/au_icsm">https://github.com/OSGeo/PROJ-data/tree/master/au_icsm</a>)<br>
</p>
<p>You can play with "projinfo -s GDA94 -t GDA2020 --spatial-test
intersects" to see the different transformation pipelines<br>
</p>
<p>A 80 m error indicates that you have a more fundamental issue
somewhere.</p>
<p>> I'll therefore need to 'jump' from WGS84 to GDA94 and from
GDA94 to GDA2020 in one step, most probably using a pipeline - not
sure how though...and if possible...a sort of two-transform in one
go.</p>
<p>If you do "projinfo -s "WGS 84" -t GDA2020 --spatial-test
intersects", you'll see 2 different options: one that assumes that
WGS 84 ~= GDA94 and then uses one of the GDA94->GDA2020 shift
method, or the other one that assumes that WGS 84 ~= GDA2020 and
does a null transformation. It really depends on what "kind of
WGS84" data you have.<br>
</p>
<p>> And in more general terms I was questioning how PROJ is
doing the link between CRS codes and grid shift transformation
files - where can I find this information ?</p>
<p>See
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_transformation.sql">https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_transformation.sql</a>
for all grids known of EPSG and
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_alternatives.sql">https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_alternatives.sql</a>
for the mapping between a subset of those to PROJ's handled grids.
Helmert transformations are in
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/blob/master/data/sql/helmert_transformation.sql">https://github.com/OSGeo/PROJ/blob/master/data/sql/helmert_transformation.sql</a>
. But using projinfo is a convenient way of querying the database
+ benefiting from extra magic done by PROJ to chain up to 2
transformations when there's no direct one.<br>
</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 30/06/2022 à 09:19, Pierre
Chaponniere a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAAKeCHaz3he_woR0jFtG0at3i-Q_kiQKZGG0AOgjdVMKFs+V_Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Thanks for the reply Greg, I'll elaborate a little
on where I start from.
<div><br>
<div>Initially, data is in WGS84 (EPSG 4326), we use PROJ API
to transform coordinates from WGS84 to a user selected
transformation, in my case EPSG 7854</div>
<div>My problem is that GDA2020 is expressed from GDA94 using
the above mentioned transformation files.</div>
<div>I'll therefore need to 'jump' from WGS84 to GDA94 and
from GDA94 to GDA2020 in one step, most probably using a
pipeline - not sure how though...and if possible...a sort of
two-transform in one go.</div>
<div><br>
</div>
<div>And in more general terms I was questioning how PROJ is
doing the link between CRS codes and grid shift
transformation files - where can I find this information ?</div>
<div><br>
</div>
<div>Offsets that I observe from the data comparing ground
truth points (in EPSG 7854) and my data (supposedly in EPSG
7854 but I doubt as I don't think it is considering the
transformation grid) are in the order of 80m to the NNE from
where it is supposed to be.</div>
<div><br>
</div>
<div>Thanks for your help !</div>
<div>Best regards, </div>
<div>Pierre C</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le mer. 29 juin 2022 à 22:24,
Greg Troxel <<a href="mailto:gdt@lexort.com"
moz-do-not-send="true" class="moz-txt-link-freetext">gdt@lexort.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Pierre Chaponniere <<a href="mailto:pierrechapo@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">pierrechapo@gmail.com</a>>
writes:<br>
<br>
> i am looking at transforming data into GDA2020 MGA zone
54 :<br>
<br>
I am far from a GDA expert but it does not make sense to talk
about<br>
transforming data into a CRS without specifying the CRS the
data is<br>
already in.<br>
<br>
> +proj=utm +zone=54 +south +ellps=GRS80 +units=m +no_defs
+type=crs<br>
<br>
This is a bare projection, and GDA2020 zone 54 is a projection
based on<br>
a datum. One is a way to take lat/lon into x/y, and the other
is<br>
something you can use to transform to/from other datums.<br>
<br>
> But it seems this projection is associated with a
transformation grid<br>
><br>
> <a
href="https://www.icsm.gov.au/datum/gda-transformation-products-and-tools/transformation-grids"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.icsm.gov.au/datum/gda-transformation-products-and-tools/transformation-grids</a><br>
<br>
The projection is not, but GDA94 to GDA2020 transformations
are, as I<br>
read that page. (That makes senes to me; we have a similar
situation<br>
in the US among former/current/future national datums.)<br>
<br>
> I have therefore dowloaded the corresponding .gsb
transformation files<br>
><br>
> <a
href="https://github.com/icsm-au/transformation_grids"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/icsm-au/transformation_grids</a><br>
><br>
> However when I apply the transformation, it appears the
process does not<br>
> use the transformation files and generate data with
planimetric and<br>
> vertical offsets.<br>
<br>
You didn't explain offset from what and why you think the
result is<br>
wrong.<br>
<br>
> How can I make sure the transformation grid are applied
and what file makes<br>
> the link between proj code and transformation files - is
this stored in<br>
> proj.db ?<br>
<br>
Almost certainly, label the input data as being in the CRS it
is<br>
actually in, and find a CRS for the GDA2020 zone that labels
it as being<br>
not just in UTM, but UTM GDA2020. At least then you'll be
asking proj<br>
to do the right thing.<br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>