[PROJ] grid shift with GDA2020

[Greg Troxel]

Pierre Chaponniere <pierrechapo at gmail.com> writes:

> i am looking at transforming data into GDA2020 MGA zone 54 :

I am far from a GDA expert but it does not make sense to talk about
transforming data into a CRS without specifying the CRS the data is
already in.

> +proj=utm +zone=54 +south +ellps=GRS80 +units=m +no_defs +type=crs

This is a bare projection, and GDA2020 zone 54 is a projection based on
a datum. One is a way to take lat/lon into x/y, and the other is
something you can use to transform to/from other datums.

> But it seems this projection is associated with a transformation grid
>
> https://www.icsm.gov.au/datum/gda-transformation-products-and-tools/transformation-grids

The projection is not, but GDA94 to GDA2020 transformations are, as I
read that page.  (That makes senes to me; we have a similar situation
in the US among former/current/future national datums.)

> I have therefore dowloaded the corresponding .gsb transformation files
>
> https://github.com/icsm-au/transformation_grids
>
> However when I apply the transformation, it appears the process does not
> use the transformation files and generate data with planimetric and
> vertical offsets.

You didn't explain offset from what and why you think the result is
wrong.

> How can I make sure the transformation grid are applied and what file makes
> the link between proj code and transformation files - is this stored in
> proj.db ?

Almost certainly, label the input data as being in the CRS it is
actually in, and find a CRS for the GDA2020 zone that labels it as being
not just in UTM, but UTM GDA2020.  At least then you'll be asking proj
to do the right thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220629/a3a0d9be/attachment.sig>