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

  • 1
    Do you think it might be better to hold off until the NTv2 transformation is available, like the transformation from AGD66 to GDA94 (but smaller), if you going to do something do it right or not at all... otherwise you'll end up with redefined coordinates in the wrong spot, not by much but still wrong. Considering GDA2020 isn't a static datum surely there should be a date defined in the CRS as to when the coordinates transformation was applied. Commented Nov 18, 2017 at 4:44
  • Have the Australian authorities provided those parameters? If they have Proj4 project can include them as +towgs84 parameters but parameters must have an official status. Users can naturally use +towgs84 as they wish.
    – user30184
    Commented Nov 18, 2017 at 10:25
  • Hey folks, firstly, the +towgs84 parameters should be 0,0,0,0,0,0,0, from my understanding, because the difference between the two datums is practically nothing. And the NTv2 transformations are very nearly available, and not what I'm asking about. Perhaps you're right, @MichaelStimson, in that doing NO transformation is better than doing an imperfect one.
    – Alex Leith
    Commented Nov 19, 2017 at 0:20

4 Answers 4


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.

  • Aha, thanks @AndreJ, that's the first part of my question. And now, what would it take for this transformation to be used as a default in, say, QGIS?
    – Alex Leith
    Commented Nov 19, 2017 at 21:51
  • You need to put up a custom CRS for every GDA2020 basec CRS. Note that the shift values are in mm, whereas PROJ.4 expects meters. You may edit the srs.db of QGIS as well, without any warranty.
    – AndreJ
    Commented Nov 20, 2017 at 7:13
  • ITRF2014 and GDA2020 will only be momentarily equal on Jan 1, 2020. Just as GDA94 was briefly aligned with ITRF92 in 1994. If you want an accurate transform for any time but the epoch 2020.0 then you need to do a 4D transform that takes into account the time dependent drift parameters. The transform defined in EPSG:8049 is time dependent, and recent versions of pro.4 can take into account the difference between the epoch of datum alignment and when your data was captured.
    – Rob
    Commented May 23, 2019 at 22:41

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.


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.

  • You may have to wait a while until an EPSG database change finds its way into GDAL and PROJ.4. GDAL is currently (2.2.2) based on the EPSG database v9.0 from Dec 2016 trac.osgeo.org/gdal/ticket/6772 and will not be updated until v2.3.0 . PROJ.4 is still older: github.com/OSGeo/proj.4/issues/477 will be in the next release.
    – AndreJ
    Commented Nov 18, 2017 at 18:52
  • Hey @user30184, I don't think the toWGS84 parameter is used for this purpose. The Proj.4 website says that these are parameters to transform coordiantes on one datum into the WGS84 datum, and with the GDA94 and GDA2020 case, the datums are the same as for WGS84 (for all intents and purposes), see: proj.maptools.org/gen_parms.html. What is needed is a way to transform between two geodetic CRSs that are defined with the same reference ellipsoid, I think. And I note that the GDA2020 definitions are in the EPSG registry and in tools like QGIS already, so there's no need to wait.
    – Alex Leith
    Commented Nov 19, 2017 at 0:27
  • Proj.4 is using WGS84 as an interim datum. If you have +wgS84 parameters on one side but not on the other you will get a datum shift. Try with +towgs84 and report your results.
    – user30184
    Commented Nov 19, 2017 at 9:08
  • Hey, I guess what I'm hoping to achieve from this is ensuring that these transform parameters (which, as @AndreJ has pointed out are part of the EPSG database) are used by default in open source tools. I'll do some reading...
    – Alex Leith
    Commented Nov 19, 2017 at 22:08

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.

  • Perfect thank you. I was trying to extract the shift deltas from the grid and use a value in my web map. the problem is im working with an AOI of 2000km2 Eastern NSW where as this adjusts everything within a few cm when compared to the NSW SCIMS data..
    – woodwa
    Commented Feb 18, 2021 at 22:34
  • translations and rotations are not commutative. So you cannot simply flip the signs to make it work. Commented May 18, 2021 at 1:02

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.