[PROJ] grid shift with GDA2020

[Even Rouault]

Pierre,

This is a complicated "equation" due to WGS 84 being a 
dynamic/non-plate-fixed datum and GDA94 & GDA2020 being static/plate-fixed

- WGS 84 ~= GDA94 at epoch 1994.0, that is the transformation between 
both is the identity

- WGS 84 ~= GDA2020 at epoch 2020.0, that is the transformation between 
both is the identity

- 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 
(https://github.com/OSGeo/PROJ-data/tree/master/au_icsm)

You can play with "projinfo -s GDA94 -t GDA2020 --spatial-test 
intersects" to see the different transformation pipelines

A 80 m error indicates that you have a more fundamental issue somewhere.

 > 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.

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.

 > 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 ?

See 
https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_transformation.sql 
for all grids known of EPSG and 
https://github.com/OSGeo/PROJ/blob/master/data/sql/grid_alternatives.sql 
for the mapping between a subset of those to PROJ's handled grids. 
Helmert transformations are in 
https://github.com/OSGeo/PROJ/blob/master/data/sql/helmert_transformation.sql 
. 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.

Even

Le 30/06/2022 à 09:19, Pierre Chaponniere a écrit :
> Thanks for the reply Greg, I'll elaborate a little on where I start from.
>
> 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
> My problem is that GDA2020 is expressed from GDA94 using the above 
> mentioned transformation files.
> 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.
>
> 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 ?
>
> 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.
>
> Thanks for your help !
> Best regards,
> Pierre C
>
>
>
>
> Le mer. 29 juin 2022 à 22:24, Greg Troxel <gdt at lexort.com> a écrit :
>
>
>     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.
>
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220630/f553dcdc/attachment-0001.htm>