Subscribe to this thread
Home - General / All posts - GDA2020 xml datum file for Manifold 8
philw
101 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.

adamw


9,447 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:

Attachments:
gda94to2020.png

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

steveFitz

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

philw,

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?

adamw


9,447 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.

Attachments:
custom-datum.xml

steveFitz

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

mikedufty

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

mikedufty

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

Dimitri


6,280 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.

tjhb

9,476 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?

(1)

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

(2)

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

mikedufty

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

Attachments:
GDA2020M9.mxb

steveFitz

264 post(s)
#06-Aug-20 10:07

I reprojected your 'Watershed_Areas_Upstream Import94' layer to GDA2020 MGA 50 using M9 and it seemed to work fine (see attached).

Did you choose a projection method in the Reproject dialog?

See http://www.georeference.org/forum/t152083.5#152121 for an account of my initial confusion.

Attachments:
GDA2020M9_2.map

mikedufty

868 post(s)
#10-Aug-20 04:21

Thanks, that seems to explain my issues.

I'll have to look into whether it helps with Manifold 8.

Suspect this may be what finally pushes us from M8 to QGIS.

steveFitz

264 post(s)
#10-Aug-20 22:44

Try this in a text file in your Config folder in M8. I think the name of the text file becomes the Projections folder name in the Assign Projection dialog in M8. It won't allow you to do transformations, just assign. I still use M9 or QGIS to reproject to or from GDA2020.

You will need to change the relevant info in the xml for your particular projection.

Mine is tacked onto a set of custom projections for particular clients so I've removed those and put xml tags top and bottom. Hopefully I haven't broken it.

<xml>

 <preset>

 <name>GDA2020 MGA55 EPSG:7855</name>

 <category>CuSToM</category>

 <datum>Australian Geodetic 2020 (Australia)</datum>

 <system>Transverse Mercator</system>

 <unit>Meter</unit>

 <majorAxis>6378137</majorAxis>

 <eccentricity>0.08181919104281579</eccentricity>

 <centerX>0.0</centerX>

 <centerY>0.0</centerY>

 <centerZ>0.0</centerZ>

 <scaleX>0.9996</scaleX>

 <localScaleX>1</localScaleX>

 <scaleY>0.9996</scaleY>

 <localScaleY>1</localScaleY>

 <falseEasting>500000.0</falseEasting>

 <localOffsetX>0.0</localOffsetX>

 <falseNorthing>10000000.0</falseNorthing>

 <localOffsetY>0.0</localOffsetY>

 <centerLat>0.0</centerLat>

 <centerLon>147</centerLon>

 </preset>

 <ellipsoid>

 <name>Australian Geodetic 2020 Ellipsoid</name>

 <majorAxis>6378137</majorAxis>

 <eccentricity>0.08181919104281579</eccentricity>

 </ellipsoid>

 <datum>

 <name>Australian Geodetic 2020 (Australia)</name>

 <ellipsoid>Australian Geodetic 2020 Ellipsoid</ellipsoid>

 </datum>

</xml>

mikedufty

868 post(s)
#12-Aug-20 08:02

That looks similar to what I have, based on adamw's attachment above, except we don't do much east of zone 52, so I've only done 50,51 and 52. Still need to get my head around using it. We have enough trouble with people getting projections wrong without having exceptions that don't transform.

code

<ellipsoid>

    <name>Australian Geocentric 2020 Ellipsoid</name>

    <majorAxis>6378137</majorAxis>

    <eccentricity>0.08181919104281579</eccentricity>

  </ellipsoid>

  <datum>

    <name>Australian Geocentric 2020 (GDA2020)</name>

    <ellipsoid>Australian Geocentric 2020 Ellipsoid</ellipsoid>

  </datum>

<preset>

        <name>MGA2020(50)</name>

        <category>Australia Standard (MBS)</category>

        <system>Transverse Mercator</system>

        <datum>Australian Geocentric 2020 (GDA2020)</datum>

        <falseEasting>500000.00</falseEasting>

        <falseNorthing>10000000.00</falseNorthing>

        <scaleX>0.9996</scaleX>

        <scaleY>0.9996</scaleY>

        <centerLat>0.00</centerLat>

        <centerLon>117.00</centerLon>

</preset>

<preset>

        <name>MGA2020(51)</name>

        <category>Australia Standard (MBS)</category>

        <system>Transverse Mercator</system>

        <datum>Australian Geocentric 2020 (GDA2020)</datum>

        <falseEasting>500000.00</falseEasting>

        <falseNorthing>10000000.00</falseNorthing>

        <scaleX>0.9996</scaleX>

        <scaleY>0.9996</scaleY>

        <centerLat>0.00</centerLat>

        <centerLon>123.00</centerLon>

</preset>

<preset>

        <name>MGA2020(52)</name>

        <category>Australia Standard (MBS)</category>

        <system>Transverse Mercator</system>

        <datum>Australian Geocentric 2020 (GDA2020)</datum>

        <falseEasting>500000.00</falseEasting>

        <falseNorthing>10000000.00</falseNorthing>

        <scaleX>0.9996</scaleX>

        <scaleY>0.9996</scaleY>

        <centerLat>0.00</centerLat>

        <centerLon>129.00</centerLon>

</preset>

code

adamw


9,447 post(s)
#12-Aug-20 13:07

One thing to keep in mind regarding 9 is that the adjustment that produces the difference of 1.8 meters is not the default one, it has to be selected in the Reproject Component dialog manually.

If you want to keep some components in GDA94 and others in GDA2020, showing them together in a map will reproject them using the default projection method and the difference will not appear.

However, there is a way to use the non-default projection method even during dynamic reprojection on the map: use a query and link a drawing off that query. The attached MAP file shows how - the 'Watershed... Import94' is in GDA94 (gray), the 'Watershed... Import94 Reprojected' is the same drawing reprojected to GDA2020 using NTv2, with the desired 1.8 meter difference (purple), and 'Query' is the original drawing being reprojected to GDA2020 using NTv2 on the fly (green). After you open the project, right-click Location and invoke View - this will open the map which contains all three drawings and zoom in close enough to see the difference in coordinates. The drawing reprojected statically and the drawing reprojected dynamically are both semitransparent, if you click them on and off, you will see that they coincide and both differ from the original. The dynamic drawing requires having GRIDS.DAT with the definition of the NTv2 projection method used (this is why, by the way, the default reprojection method is different - the user might not have that file available).

The text of the query:

--SQL

--

-- $manifold$

 

VALUE @source NVARCHAR = 'EPSG:28350'-- GDA94 / MGA 50

VALUE @target NVARCHAR = 'EPSG:7850';  -- GDA2020 / MGA 50

VALUE @conv TABLE = CALL CoordConverterMakePath(

  @target, @source, 'EPSG:8446'FALSE

); -- NTv2: gda94_gda2020_conformal.gsb

 

TABLE CALL TableCacheIndexGeoms((

  SELECT

    [mfd_id][Value][Coord],

    CoordConvert(@conv, [Geom]AS [Geom] -- convert coordinates

  FROM [Watershed_Areas_Upstream Import94]

), TRUE); -- allow writes

I also set the coordinate system of Query Drawing after creating it to 'EPSG:7850'.

Hope this helps a little.

Attachments:
GDA2020M9-mod.mxb

lionel

670 post(s)
#24-Aug-20 23:28

don't read a lot this thread/post but find difficult ( i have low gis level understanding ) in the past ( don't try today) to understand how projection work after read the manifold documentation

1) what mean "' Assign initial coordinate System " and "repair initial coordinate" and " reproject component " ( no item word "change projection" is use in menu )

2) where is store the projection and which projection is take in account regard to context ( active *)

3) if when use one of the 3 cases in 1) if geom data value storage change and/or only projection definition storage .I understand that dynamic projection could occur in realtime so there is a reference projection should exist in some context . i see that map projection during initialisation can be set to already use projection available in manifold project file *.map

I need testing using object map( M with projA) with and 2 drawings (A with projA B with projB) .... ( learn by test rather than read the doc)

- to see if info-> coordinate show in all case value in native projection storage ?

-how copy "info ->value-> geom Column-> <geom,area> value cell" work beetween 2 drawing that use different projection ! so copy a geom in table A of drawing A and update(not create) a geom in B table of drawing B

regard's


union

Dimitri


6,280 post(s)
#25-Aug-20 09:03

1) what mean "' Assign initial coordinate System " and "repair initial coordinate" and " reproject component " ( no item word "change projection" is use in menu )

See the Projections topic. I recommend reading the topics listed here.

2) where is store the projection and which projection is take in account regard to context ( active *)

The projection is reported in the Info pane. If a map is the active component, the Info pane will report the projection used by the map and also by whatever is the currently active layer in that map.

A map window can use whatever projection you tell it to use. If the window contains layers that use different projections, those layers will be reprojected on the fly for display purposes into the projection used by the map.

There are numerous examples of all the above in the various Examples. Work through some of the example topics in the Introductory Examples section and you'll see what I mean.

adamw


9,447 post(s)
#25-Aug-20 09:04

Very shortly:

In Manifold, all spatial data has a projection associated with it. If spatial data is imported from a file that didn't have any projection info, it gets a flag meaning that the projection was not there and gets the default projection - orthographic in 8, web Mercator in 9.

Assign Initial Coordinate System and Repair Initial Coordinate System keep the spatial data unchanged and only change the associated projection. If there is a flag that the projection was not there during the import, the UI shows Assign, otherwise it shows Repair. After you perform Assign or Repair, the spatial data moves with respect to other components because you specify that it should be in a different place.

Change Coordinate System assumes that the projection associated with the spatial data is correct and projects the data to a different projection, changing both the data and the associated projection. After you perform Change, the spatial data does not move with respect to other components (save for computation errors).

Copying and pasting a geometry value between two fields in different coordinate systems will not re-project it. If you want to re-project it, use Change Coordinate System - or, in the future, the Copy transform (it currently does not re-project geometry values when copying data between different fields, but we will make it do this so that it works similarly to other transforms which are projection-aware - copying raster data will not perform the re-projection for obvious reasons).

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