Subscribe to this thread
Home - General / All posts - GDA2020 xml datum file for Manifold 8
100 post(s)
#20-Feb-20 08:07

Has anyone managed to put together an xml datum file for the new Australian GDA2020 datum? If not I'll have a go at it.


9,299 post(s)
#25-Feb-20 07:32

I searched for the definition of the datum out of interest, found a manual (heh):

GDA2020 and GDA94 Technical Manuals

...and it seems like an interesting case.

The datum definition in Manifold (either 8 or 9) should be:

semi-major axis = 6378137 (m), inverse flattening = 298.257222101

...or, in Manifold-speak:

semi-major axis = 6378137, eccentricity = 0.08181919104281579

In fact, the datum is in EPSG and that's how it is defined in 9, see EPSG codes 7842, 7843, 7844 (all three describe the same thing from different points of view).

That said, the manual defines transforms from GDA94 to GDA2020, and while 8 won't see them, 9 will, since they are also in EPSG and we support pretty much all of it, integrating updates into the product as they appear.

See the image:


100 post(s)
#27-Feb-20 07:56

Thanks for looking into that Adam. I had also found the manual but was trying to avoid the pain (i.e. read being lazy ) of getting the M8 xml datum file to work by seeing if anyone else had done it already. I have put together some custom datum files for M8 in the past (for some country specific projections/datums that various international project were using). I just remember it being a bit hit and miss to get them working and correct.


239 post(s)
#20-Mar-20 00:34


Did you manage to get a custom xml together for GDA2020?

I'm trying to put together the GDA2020 MGA94 projections but have no idea what goes in each <preset> field for M8 custom xml systems.

I did a search to see if I could find a standard xml format that is similar or the same as M8 but I can't find anything like it.

Any ideas anyone?


9,299 post(s)
#20-Mar-20 06:53

The process of creating a custom datum is explained in the manual. You will need a custom ellipsoid and a custom datum building on that ellipsoid. The numbers are in my post - plain major axis + eccentricity (or inverse flattening).

See attached example - it adds a new entry named 'Australian Geodetic 2020 (Australia)' into the datum list.

If you need custom transforms from this datum to other datums, the best option is to use 9 which has them built-in, or you can download grid files and define custom transforms in 8.



239 post(s)
#20-Mar-20 11:27

Thanks Adam.

I'll have better look at it this time.

Sorry about requiring spoon feeding!

I'd be happy with doing transforms in 9

if needed as long as I can still import into 8 where I'm more comfortable.


861 post(s)
#28-Jul-20 09:05

Will this actually work?

I've tried using Adam's custom datum file, and things seem to appear in the same place with that assigned as with GDA94 (not attempting to transform the data, just assigning the different datum).

My understanding is they should be out by around 2m in Western Australia.

It seems a bit too simple, I suspect I am missing a step somewhere.


861 post(s)
#28-Jul-20 10:51

Same thing in Manifold 9 actually, if I use repair initial coordinates system from GDA94 to GDA2020, nothing moves.

Same thing in QGIS results in the 1.8 m move as expected.

Am I missing something?


6,104 post(s)
#28-Jul-20 11:36

Am I missing something?

Hard to tell without knowing every detail of your starting data and what you are doing, step by step. Post a sample of your data and a detailed description of your workflow.

Also, if you start with data in GDA94, why are you using "repair" to say it is something different? Seems like if you want to reproject you'd use Reproject.


9,320 post(s)
#28-Jul-20 21:26

I think you should expect to see a shift (between 1.5 and 1.8m NNE) in some circumstances but not all.

The question is, a shift with respect to what?


Take the case of a single component, viewed in its own window. If you change the coordinate system (using Repair), what changes? The numbers don't change, only their interpretation. There is no reason for the data to move visibly on the screen, since within its own coordinate system, the data is still in "the same place".

On the other hand, there should be a small change in the position reported in the status bar (lower right), if this is set to show Latitude / Longitude. (In practice you might need to refresh the winodw for this change to be seen--I don't know--and if so then that might make it difficult to check.)


If the component is shown in a map, preferably along with other data, then changing the projection of the component (again with Repair) should show a shift in the data, since now its position is relative to something else. (Again, in practice, it might be necessary to force a refresh of the map window for this to be seen.)


861 post(s)
#30-Jul-20 03:49

In the M9 example I have loaded a shape file in GDA94 MGA zone 50 EPSG 283500

M9 has correctly assigned this CRS from a prj file.

Initially I copied the drawing, and repaired projection to GDA2020/MGA zone 50 EPSG 7850

I put both drawings in a map and they overlaid perfectly.

Going to reproduce this I realised that the copy and paste of the drawing made a new drawing from the same table so thought that might have been my issue.

I have now tried re-importing from shape file for the comparison, however and have the same result.

I know it doesn't make sense to repair the initial projection incorrectly, however it seems like a useful way to check the conversions are working. I don't think I have any data supplied in GDA2020, but we are about to be asked to provide data in this format.

I've attached the test file. Same dataset imported 3 times.

One as imported GDA94

One 'repaired' to GDA2020

One reprojected to GDA2020

The 'repaired' one should be about 1.8m out from the others in the map, due to having the wrong CRS assigned, but it is not.


Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.