I have been exploring the new coordinate system conversion tools and options, using two New Zealand coordinate systems as examples. The New Zealand Map Grid projection (in terms of Geodetic Datum 1949) has long been superceded by the New Zealand Transverse Mercator projection (in terms of New Zealand Geodetic Datum 2000). Naturally, a lot of useful data still exists in NZMG/GD49, so conversion is commonplace. There are three officiallysupported methods for transformation between the two systems: one 3parameter, one 7parameter, and an NTv2 grid (in order of increasing accuracy). NZMG/GD49 and NZTM/NZGD2000 are supported in Manifold 9 both as native Manifold coordinate systems and as their EPSG equivalents. They can be listed (with other New Zealand systems) like this. SQL9 SELECT * FROM CALL CoordSystems() WHERE StringContains(StringToLowerCase([Value]), 'new zealand') ; This shows native Manifold codes, EPSG codes and codes for base coordinate systems and datums (all so far as applicable), with a JSON definition for each system (in the [Value] field). To get the JSON definition for one of the systems, we can use CoordSystem() with a native Manifold code, or CoordSystemEpsg() with an EPSG code. The JSON definitions can then be used in setting table properties (to assign or correct a projection), to create a Converter object (to reproject data), and so on. E.g. either of these expressions will give NZMG/GD49 SQL9 CoordSystem(624) CoordSystemEpsg(27200) while these give NZTM/NZGD2000 SQL9 CoordSystem(228) CoordSystemEpsg(2193) Of course, whether the native Manifold systems and the EPSG versions are equivalent is in a sense empirical, not guaranteed. If there were differences or errors in the definitions, they would not be. Less obviously, the same applies to the available conversion paths between the corresponding pairs. A different range of transformations might be available between native NZMG and native NZTM, between EPSG NZMG and EPSG NZTM, and for the cross conversions between a native system and an EPSG system. I didn't know whether that would be the case so I wanted to test it. We can test the paths available for any pair of systems using CoordTransformChoices(). E.g. for native NZMG to native NZTM: SQL9 TABLE CALL CoordTransformChoices( CoordSystem(624),  native NZMG/GD49 CoordSystem(228)  native NZTM/GD2000 ); I was surprisedthis returns an empty table, apparently zero choices. By comparison with GUI operations (see next post), we can infer that this means there is only one default conversion pathalthough we don't yet know what it is. I will test that later. Now for the EPSG versions: SQL9 TABLE CALL CoordTransformChoices( CoordSystemEpsg(27200),  EPSG NZMG/GD49 CoordSystemEpsg(2193)  EPSG NZTM/GD2000 ); This returns four available conversion paths (one more than I expected): one 3parameter, two 7parameter, and one NTv2 using the named grid nzgd2kgrid0005.gsb. The second 7parameter transformation is one approved for military purposes which I didn't know about; but since each EPSG transformation has its own code, and CoordTransformChoices() returns those codes, it's easy to fill in the gap at www.espg.org. The table also returns the standard accuracy for each transformation choice, and a native Manifold code. (Given these choices, and an EPSG code for each one, we can now create a Converter object to use a specific conversion path by using the CoordConverterMakePath( function.) What do we get for the cross conversions (native to EPSG, EPSG to native)? All four possibilities return empty tables. Again it would be good to check exactly what this means (probably one default transformation, but what?). Now to the GUI (next post).
