Proj.4/GDAL/QGIS Transformation between CRSs that are defined the same

Question

I'm helping to ensure that open source software can handle Australia's new datum appropriately, see ICSM's website for details on the GDA2020 project.

Now, QGIS has already got the definitions of GDA2020 included, via GDAL, I understand.

An example GDA2020 coordinate reference system is this:

+proj=utm +zone=55 +south +ellps=GRS80 +units=m +no_defs

And if you look at a GDA94 CRS, it's defined like this:

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

As you can see, these are very similar.

Now, the two CRSs are defined exactly the same, but, there's a shift in coordinates in GDA94 to GDA2020 of around 1.5 m to the north-east. (There's a grid shift file in NTv2 format that will soon be ready that will enable precise transformations, but that's not what this question is about.)

But, if you convert between GDA94 and GDA2020 now, using QGIS, there's no change in coordinates. It essentially just labels it differently.

Should there be a simple 7 parameter transformation implemented in Proj.4 or other open source tools that is the default transformation (albeit, imperfect) between GDA94 and GDA2020?

Or is it simply the case that the tools will always do no change?

How should this be handled?

(And I just want to note again that transforming using a grid is ideal, and that's handled in a few ways including this QGIS plugin.)

Answer 1

If you search the EPSG database for GDA94 CoordinateTransformation, you get:

• Transformation code EPSG:1150 GDA94 to WGS84(1) which has all-zero values
• Transformation code EPSG:8048 GDA94 to GDA2020 (1) with the 7 values given by @user30184

So it is save to take those for GDA2020 to WGS84 (taking care of signs and units!) until the new grid shift is published. That will get a new transformation code number.

Currently there is a Transformation code EPSG:8049 ITRF2014 to GDA2020(1) stating that both are equal for now, with annual increase values. So you could take up with the ITRF time frames as well.

Answer 2

You asked:

Should there be a simple 7 parameter transformation implemented in Proj.4 or other open source tools that is the default transformation (albeit, imperfect) between GDA94 and GDA2020? Or is it simply the case that the tools will always do no change? How should this be handled?

The FAQ at http://www.icsm.gov.au/gda2020/faq.html informs:

The following products will be available:

• 2D transformation and distortion grid files in the widely used Canadian National Transformations version 2 (NTv2) format
• 7 parameter similarity (Helmet) transformation
• A 3D transformation grid file — format yet to be determined.

Values supporting transformation of datasets between GDA2020 and ITRF2014 utilising either a plate motion model or 14 parameter similarity transformation will also be published.

This information will be provided directly to the EPSG Geodetic Parameter Registry which is referred to by spatial software and hardware providers worldwide before incorporating transformation parameters into software and firmware.

Once ICSM have publisded the 7 parameter similarity transformation parameters you can start using them as

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=[new parameters] +units=m +no_defs

I seems that they are already published in http://www.icsm.gov.au/gda2020/InterimReleaseNoteV1.0.pdf.

61.55,-10.87,-40.19,-9.994,-39.4924,-32.7221,-32.8979

You can have a try with these +towgs84 parameters but I am remembering that Proj.4 may want some of the parameters with reversed sign.

Making a Proj.4 ticket when the parameters are officially available may speed up the process with Proj.4 but when the EPSG database is updated and Proj.4 starts to use that new database the change may happen automatically. It depends a bit on how GDA2020 will be implemented in EPSG database and if a new algorithm is needed or if it is just question of adding the towgs84 parameters.

Answer 3

Building on previous answers the proj4 definition looks like this:

+proj=longlat +ellps=GRS80 +towgs84=-0.06155,0.01087,0.04019,-0.0394924,-0.0327221,-0.03289790,0.009994 +no_defs

You can then use this on any of the standard projected grid zones by just adding in the towgs84 parameter. e.g.

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=-0.06155,0.01087,0.04019,-0.0394924,-0.0327221,-0.03289790,0.009994 +units=m +no_defs

To get the right numbers from section 3.1 of the specification you first reverse the sign of the rotation parameters (as discussed in section 2.2.1), but then invert everything because the parameters in the specification are the transform from WGS / GDA94 and we want the transform to WGS for the proj4 definition. So basically everything except the rotations in the specification have their sign reversed.

The only other thing to watch out for is that for proj4 the scale is the last parameter.

Purists will suggest using the NtV2 grid shift approach but these files are very big and I have found that the above gives better than 5cm accuracy using sample data for Victoria. I also wanted a solution that would work with proj4js.

Answer 4

TLDR: They're not the same. The reported equality is the result of approximations and is only true in limited circumstances. GDA94/2020 co-ordinates are defined on different datums and reference frames. The appropriate transformation between them depends on the level of accuracy desired.

The issue here is the assumption in the question that proj.4 correctly reports the two CRS (co-ordinate reference system) as being the same. They're not. The proj.4 strings quoted aren't the CRS definitions. They're generated from the CRS definition, and the proj.4 strings aren't the full picture. The EPSG registry definitions give us the extra information we need to understand what's really going on.

This stems from a world-view that WGS-84 is 'the' global datum and historically proj.4 has used it as a go-between when converting between datums. Thing is, WGS-84 gets redefined every few years (we're at G1762 now, aligned to ITRF-08) as it's re-aligned with changes in the ITRF reference frame, from which GDA is also derived.

This has lead to these shortcuts and assumptions being baked into proj's behaviour, though in recent versions this is starting to change.

Tracking the implications of changes to reference frames, and when they changed wasn't a big deal while consumer GPS was >5m accuracy but times are changing and sub-metre accuracy requires tools properly account for them.

So, to answer the question we need to trace what datum and reference frames GDA94 and GDA2020 CRS are based on and then see what available transformations there are.

• EPSG:7844 GDA2020 2D Geographic CRS (Lat/Lon), from
• EPSG:7843 GDA2020 3D Geographic CRS (L/L/H), from
• EPSG:7842 GDA2020 3D Geocentric (ECEF X/Y/Z), all of which use
• EPSG:1168(datum) - Geocentric datum of Australia, 2020

EPSG:1168 defines it's anchor reference frame:

• Anchor Definition : ITRF2014 at epoch 2020.0
• Realisation Epoch : 2020-01-01

If you do the same for GDA94 you'll see that the reference frame is ITRF92, aligned on 01/01/1994.

If transforming between ITRF02/14 and GDA94/GDA2020 data, the datums are aligned, and the transformation between them is null only on the epoch alignment date. That's essentially what those proj strings are saying. For convenience, we don't generally like having to constantly change the co-ordinates we store, so it's simpler to step change the drift between them every few years and accept a level of error.

For most applications requiring >1m accuracy, that's good enough.

But reality doesn't step change every few years and if we want a more accurate transformation, we need to consider the time-dependent distance drift of the datums before/after their alignment. It's a 4D rather than 3D transformation.

The transformations between GDA2020 and WGS-84 or ITRF2014 are described in:

1. GDA2020 to WGS 84 (G1762) (1) - EPSG:8448
2. ITRF2014 to GDA2020 (1) - EPSG:8049

If transforming between GDA94 and GDA2020, things are simpler as we only need to know the difference between the reference frames. Sort of. There's more than one, and the correct one to use depends on when, how and where the data was referenced to GDA94. It's an attempt to shake out errors due to less refined methods being used in the 90's.

These are:

• Conformal - Coordinate Frame rotation (1) - EPSG:8048
• Localised distortion (2) - EPSG:8447
• Conformal - NTv2 Grid transformation (3) - EPSG:8446

To understand under what circumstances these should be used, read the GDA2020 technical manual