Subscribe to this thread
Home - General / All posts - On NTv2 and conversion paths
tjhb

8,950 post(s)
#28-Nov-19 00:39

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 officially-supported methods for transformation between the two systems: one 3-parameter, one 7-parameter, 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 surprised--this 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 path--although 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 3-parameter, two 7-parameter, and one NTv2 using the named grid nzgd2kgrid0005.gsb. The second 7-parameter 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).

tjhb

8,950 post(s)
#28-Nov-19 00:56

A note before going on. It may be that it is only possible to choose a specific transformation (conversion path) when both coordinate systems are defined by an EPSG code. That could be a reason to prefer EPSG definitions over native Manifold coordinate system definitions, for some purposes or even generally.

I don't know if that is true, but so far it seems an obvious conjecture.

Dimitri


5,611 post(s)
#28-Nov-19 06:50

it is only possible to choose a specific transformation (conversion path) when both coordinate systems are defined by an EPSG code

Yes. Transform paths are available when converting between EPSG systems.The transform paths themselves also have an EPSG code. This provides an unambiguous system of specific systems and specific transform paths between them.

tjhb

8,950 post(s)
#28-Nov-19 07:23

Thank Dimitri, that makes sense.

On the other hand:

(1) It is something worth pointing out in the manual (not pointed out in release notes but easily overlooked).

(2) It was different in Manifold 8, where there were no EPSG systems of course, but for built-in systems where an NTv2 transformation was officially recommended, the NTv2 grid was used (as I understood it--I could be wrong). It was quite hard to get Manifold 8 to use a parameter-based transformation in those cases (but possible).

(3) In 9, I'm not certain whether native Manifold systems can be made to use NTv2. (I think it might be possible, by means of a custom base CS. Not sure yet.) But it seems it is not the default.

(4) In the case of native systems, it seems we can't tell whether the default conversion will use a 3- or 7-parameter transformation. That is important.

(5) Putting 3 and 4 together becomes semi-serious, since they may lead to the inadvertent use of an inappropriate or unexpected transformation. For a long time, ESRI products had a similar problem, just due to bad UI design, which led directly to widespread topology errors, often barely detectable and barely fixable, in some public datasets, at least in this part of the world.

(6) I think it should be not only possible, but also the default, to use NTv2 transformations to and from native Manifold coordinate systems (and perhaps between native and EPSG systems), wherever an NTv2 grid is recommended, as well as between two systems both defined in terms of EPSG codes.

adamw


8,764 post(s)
#28-Nov-19 14:44

Some notes:

(3) - Non-EPSG systems can be made to use NTv2 or NADCON, but only for the conversion to WGS84 and back. We might allow specifying a direct transform between two arbitrary systems in the future, with the match made using coordinate system names (more precisely: initially made using names and then either approved or rejected based on whether the parameter values match those names).

(4) - We are mapping all of 3-parameter / 7-parameter / 10-parameter conversions into the same operation named Molodensky-Badekas. The math is the same, it's just that a 7-parameter conversion does not specify values for some parameters and gets default 0s, same for 3-parameter. You can tell which conversion is going to be applied by looking at which parameters are specified.

(6) - To use a grid, we have to know which coordinate system the grid is transforming into which. There needs to be some roster of systems and conversions between them. Detecting whether a conversion between two systems can use a grid is not simply a question of matching parameters, but rather a question of identification. For example, there might be multiple instances of Transverse Mercator with the exact same parameters of, say, center lon = -120, center lat = 0, NAD27, but converting to lat/lon, WGS84 should use a grid named 'xxx' if the system is named 'yyy' and a grid named 'zzz' if the system is named 'www'. Or at least that's what we are currently doing. There is a common roster of systems and conversions between them already - EPSG, so we are using that. We are not currently using direct conversions between systems defined by Manifold because we don't want to create another parallel roster of systems and conversions - better use EPSG as much as possible. Instead, we define our systems with a bundled conversion to WGS84 and when we have to convert between systems which are using different datums, we are going through WGS84.

adamw


8,764 post(s)
#29-Nov-19 11:03

In addition to the note for (6) above, we are considering a mechanism for plugging in custom grids which would allow grid transforms between arbitrary systems, not necessarily EPSG.

tjhb

8,950 post(s)
#28-Nov-19 01:21

On the (related) question of what default transformation is used when going from NZMG/NZGD49 to NZTM/NZGD2000 or vice versa, we can ask the CoordConverterSteps() function.

First set up the two native projections.

--SQL9

VALUE @nzmg NVARCHAR = CoordSystem(624);

VALUE @nztm NVARCHAR = CoordSystem(228);

Show the steps for the forward conversion

--SQL9

VALUE @conv TABLE = CALL CoordConverterMake(@nztm, @nzmg); -- NZMG to NZTM

TABLE CALL CoordConverterSteps(@conv);

The result table shows

(Auto) Scale / Shift

New Zealand

(Auto) Axes

Molodensky-Badekas

Molodensky-Badekas

(Auto) Axes

(Auto) Scale / Shift

For the reverse conversion

--SQL9

VALUE @conv TABLE = CALL CoordConverterMake(@nzmg, @nztm); -- NZTM to NZMG

TABLE CALL CoordConverterSteps(@conv);

the steps listed above are (exactly) reversed.

The partial conclusion is that the conversion between NZMG and NZTM use either a 3-parameter or 7-parameter transformation, not NTv2. That's really helpful to know.

How to tell whether the conversions are 3-parameter or 7-parameter?

tjhb

8,950 post(s)
#28-Nov-19 01:46

Now the same for EPSG to EPSG conversions, using CoordConverterMakePath() in place of CoordConverterMake() to allow specifying a conversion path (and this time doing forward conversions only).

The EPSG projections:

VALUE @nzmg NVARCHAR = CoordSystemEpsg(27200);

VALUE @nztm NVARCHAR = CoordSystemEpsg(2193);

Now each of the three official conversions* in turn, using the EPSG codes found using CoordTransformChoices() (first post).

3-parameter transformation:

VALUE @conv TABLE = CALL CoordConverterMakePath(@nztm, @nzmg, 'EPSG:1566', TRUE); -- 3-parameter

TABLE CALL CoordConverterSteps(@conv);

7-parameter:

VALUE @conv TABLE = CALL CoordConverterMakePath(@nztm, @nzmg, 'EPSG:1701', TRUE); -- 7-parameter

TABLE CALL CoordConverterSteps(@conv);

NTv2 grid:

VALUE @conv TABLE = CALL CoordConverterMakePath(@nztm, @nzmg, 'EPSG:1568', TRUE); -- NTv2

TABLE CALL CoordConverterSteps(@conv);

The results tables for the 3-parameter and 7-parameter transformations here are the same--the same as for the native-to-native forward transformation in the previous post. So again there is no way to tell from the result whether a 3-parameter or 7-parameter transformation is used.

For the NTv2 transformation, we get

(Auto) Scale / Shift

New Zealand

NTv2

Transverse Mercator

(Auto) Scale / Shift

(Auto) Axes Swap


[*I was wrong in my first post in saying that the unexpected fourth NZMG-NZTM conversion was a "miltary only" conversion. That one exists, or did exist, but it is not listed in Manifold. Instead the fourth conversion here is "deprecated"--a fact helpfully mentioned within the [Value] string, but I missed it (and mistook the code).]

tjhb

8,950 post(s)
#28-Nov-19 02:17

Well, I made an embarrassing mistake.

I listed the wrong code throughout for native Manifold NZTM/GD2000 (EPSG:228) is just unprojected NZGD2000, not projected NZTM/NZGD2000 which is EPSG:625). Of all the dumb things to do.

As it happens, it didn't make any difference to the results reported above.

But here is a revised version of the whole workflow given above, mistakes corrected, in case anyone wants to try it out or adapt it to test with their own local projections.

There are line breaks in the attached version.

--SQL9

-- list all 'new zealand' coordinate systems

SELECT *

FROM CALL CoordSystems()

WHERE StringContains(StringToLowerCase([Value]), 'new zealand')

;

VALUE @nzmg_native NVARCHAR = CoordSystem(624);

VALUE @nztm_native NVARCHAR = CoordSystem(625);

VALUE @nzmg_epsg NVARCHAR = CoordSystemEpsg(27200);

VALUE @nztm_epsg NVARCHAR = CoordSystemEpsg(2193);

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

-- list transform choices

-- native to native

TABLE CALL CoordTransformChoices(@nzmg_native, @nztm_native);

    -- empty

-- EPSG to EPSG

TABLE CALL CoordTransformChoices(@nzmg_epsg, @nztm_epsg);

    -- four choices

    -- one deprecated: EPSG:1567 replaced by EPSG:1701

-- native to EPSG

TABLE CALL CoordTransformChoices(@nzmg_native, @nzmg_epsg);

    -- empty

TABLE CALL CoordTransformChoices(@nzmg_native, @nztm_epsg);

    -- empty

-- EPSG to native

TABLE CALL CoordTransformChoices(@nzmg_epsg, @nzmg_native);

    -- empty

TABLE CALL CoordTransformChoices(@nztm_epsg, @nzmg_native);

    -- empty

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

-- list steps

-- native to native

-- forward (NZMG to NZTM)

VALUE @conv TABLE = CALL CoordConverterMake(@nztm_native, @nzmg_native);

TABLE CALL CoordConverterSteps(@conv);

-- reverse (NZTM to NZMG)

VALUE @conv TABLE = CALL CoordConverterMake(@nzmg_native, @nztm_native);

TABLE CALL CoordConverterSteps(@conv);

-- EPSG to EPSG

-- forward only (NZMG to NZTM)

-- 3-parameter (EPSG:1566)

VALUE @conv TABLE = CALL CoordConverterMakePath(@nztm_epsg, @nzmg_epsg, 'EPSG:1566', TRUE);

TABLE CALL CoordConverterSteps(@conv);

-- 7-parameter (EPSG:1701)

VALUE @conv TABLE = CALL CoordConverterMakePath(@nztm_epsg, @nzmg_epsg, 'EPSG:1701', TRUE); 

TABLE CALL CoordConverterSteps(@conv);

-- NTv2 (EPSG:1568)

VALUE @conv TABLE = CALL CoordConverterMakePath(@nztm_epsg, @nzmg_epsg, 'EPSG:1568', TRUE); 

TABLE CALL CoordConverterSteps(@conv);

Attachments:
20191128 Test coordinate conversion paths (working).txt

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