Proj.4/GDAL/QGIS Transformation between CRSs that are defined the same
If you search the EPSG database for GDA94 CoordinateTransformation, you get:
- Transformation code
EPSG:1150GDA94 to WGS84(1) which has all-zero values - Transformation code
EPSG:8048GDA94 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.
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.