Subscribe to this thread
Home - General / All posts - NTv2 Change Projection Germany
BerndD

162 post(s)
#14-Jul-17 01:16

I am currently testing transforming German GK3 data to ETRS89 using change projection with a NTv2 file.

In the attached project there is a drawing named "GK3" with a point projected in GK3.

In the comment "Example Coordinates based on BETA2007" you can find the corresponding values projected in ETRS89. This is official verification data and should be the expected result.

According to the helpfile topic "Custom Datum Grids for NTv2" I created an xml file "BETA2007.xml" and copied it into the Manifold subfolder %Manifold%\Grids

I also copied the NTv2 binary gridfile "BETA2007.gsb" in the same folder.

For reference I copied all used projection files and the xml file "BETA2007.xml" as comments in the Manifold 8 project attached to this post.

When performing change projection to "ETRS89_UTM_zone_32N" the result is off within a few meters.

I might have overlooked a small detail or have a brain freeze and could use some help.

Any ideas or suggestions?

PS: I am assuming that Manifold GIS is not using any build in NTV2 files already and that this kind of transformation still needs to be performed according to the helpfile.

Attachments:
Beschreibung der Transformation_ DE_DHDN (BeTA, 2007) nach ETRS89.pdf
BETA2007.gsb
Custom Datum Grids for NTv2.pdf
NTv2.map


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

tjhb
10,094 post(s)
#14-Jul-17 02:09

Bernd,

(1) Since NTv2 grid transformations are for one datum to another, I believe you should only specify the source and target datums, without specifying any projections. (In a sense it doesn't matter what the projections are--these are handled separately.)

So (but see point 2):

<xml>

<transform>

<source>Deutsche Hauptdreiecksnetz</source>

<target>ETRS89</target>

</transform>

</xml>

(2) While Manifold has the Deutsche Hauptdreiecksnetz datum built in (under that name), ETRS89 is not built in to Manifold 8 (AFAIK). So to use the above XML for the datum-datum grid transformation, you'd also need to define ETRS89 as a custom datum.

Tim

tjhb
10,094 post(s)
#14-Jul-17 02:26

(3) As I understand it, in Manifold ETRS89 should be treated as a direct implementation of GRS1980. So the xml file defining a custom datum for ETRS89 should be simply

<xml>

    <datum>

        <name>ETRS89</name>

        <ellipsoid>GRS 1980</ellipsoid>

    </datum>

</xml>

tjhb
10,094 post(s)
#14-Jul-17 02:35

Duh... I completely missed the importance of comments ETRS89_UTM_zone_32N and Gauss-Kruger Zone 3 (DHDN) in your attached .map file. So you have defined these projection-datum combinations explcitly, but only as combinations.

I still think that the point about NTv2 transforming from datum to datum is correct though, so perhaps custom projection(s) and datum(s) must be defined separately, and only the datums named in the xml for the grid transformation.

I will test what happens for your test point if that is done.

(By the way, yes Manifold 8 does implement some built-in NTv2 datum grid transformations.)

tjhb
10,094 post(s)
#14-Jul-17 09:30

The result I got on that basis for the single test point you chose is:

[source] GK3 DHDN: (3399371.190396, 5930724.531323)

[target] UTM32N ETR89: (399341.983313831, 5928794.17271822)

Whereas the target coordinates for that point should apparently have been: (399340.601862, 5928794.177992)

I notice that the target coordinates, and also the coefficients in the .gsa version of the official grid file (not sure about precision in the .gsb version) are uniformly expressed to 6 decimal places. By contrast Manifold will always use full FP64 precision for coordinate transformations. I don't know if this is enough to account for the minor differences above.

Perhaps it is worth testing the full set of GK3 source points (from the official CSV file) since that is easy to do, then assessing the numerical differences as a whole.

(I don't think there's a way to make Manifold 8 use single precision for coordinate transformations.)

adamw


10,447 post(s)
#14-Jul-17 11:15

As Tim says, the BETA2007.XML file has to specify datums, not coordinate systems to convert between.

I went a simpler route then Tim did and used the following BETA2007.XML:

<xml>

  <transform>

    <source>Deutsche Hauptdreiecksnetz</source>

    <target>Geodetic Reference 1980</target>

  </transform>

</xml>

...then projected to the coordinate system defined in the ETRS89_UTM_zone_32N comments component.

The results were the same as Tim's.

To recap, the results are:

Original: 3399371.190396, 5930724.531323

Desired: 399340.601862, 5928794.177992

Converted with NTv2: 399341.983313831 (+1.38), 5928794.17271822 (-0.005)

Converted without NTv2: 399339.281716573 (-1.32), 5928789.38923464 (-4.79)

As you can see, using the grid definitely improves the accuracy. That said, the overshoot of 1.38 is worth looking into on our end. We will do this for Radian (and will allow wiring custom coordinate transforms there as well).

BerndD

162 post(s)
#15-Jul-17 13:48

Adam/Tim,

Thank you so much for your help. I got it running now.

Adam, in regards of accuracy I would appreciate if you guys could take a look into it.

We will need to transform the data of all our clients of the state of Baden-Württemberg anytime soon.

Once they issue the final and official NTv2 file for that state (sometime this fall) we need to be able to act upon. Having the ability for custom coordinate transformations in Radian would probably help enormously in terms of speed, especially for raster based data.

I will provide another example for testing in a couple of days with data from the state of Thüringen.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

BerndD

162 post(s)
#24-Jul-17 15:25

Here is another example using the official NTv2 grid provided bz the German state of Thüringen.

The accuracy is much better, given the fact that this is a more precise grid on the state level.

However, the result is not exactly what is expected.

Some research on this on the Manifold side would be greatly appreciated.

Source:

https://sapos.thueringen.de/Lsyst.php

1 4443210.123 5654321.456 123.456 Beispielpunkt

Expected result:

1 32653532.066 5654469.714 123.456 Beispielpunkt

Result with Manifold NTv2 transformation:

1 653532.048690728 5654469.71558519

Difference

0.017309272 -0,001585519

Result without using the gsb grid file:

1 653533.845239369 5654468.11504068

Attachments:
NTv2gridTH.gsb
NTv2gridTH.xml
ntv2_thueringen.map


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

adamw


10,447 post(s)
#27-Jul-17 07:51

We found the reason for the discrepancy. It was an inaccuracy in our code.

After the fix, the resulting coordinates are:

653532.06578346 (-0.000217), 5654469.71492794 (0.000928)

The above is ignoring the difference of 32000000 in X, which is obviously just a different false easting.

We will deliver the fix in Radian. We are not currently planning to issue updates to Manifold 8, but if we end up doing that, the fix will be there as well.

Thanks a lot for the files!

adamw


10,447 post(s)
#27-Jul-17 07:57

...and the result after the fix for the first grid + pair of coordinates:

399340.601858176 (-0.00000382), 5928794.17839725 (0.000405)

BerndD

162 post(s)
#28-Jul-17 18:01

Thanks, Adam for looking into it.

That is great news.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

BerndD

162 post(s)
#07-Jan-18 23:14

Just wondering how ntv2 grids do work in Manifold 9.

I found this in the user manual, but nothing else on whether a specific grid is built in already or how to add an additional grid:

"Manifold includes all grids that are openly published now and also those which at some time in the past were published without restrictions. All grids within Manifold that once were openly published but which now can be only obtained with restrictions were obtained from sources which obtained those grids legally at a time when no restrictions applied. The resulting collection of grids in Manifold is as of this writing much larger than the built-in collection of grids in any other general-purpose GIS or DBMS package."

Specifically I would like to use the ntv2 grid (BWTA2017) for the German sate of Baden-Württemberg that was issued recently.

The source of the grid can be found at the link below.

https://www.lgl-bw.de/lgl-internet/opencms/de/05_Geoinformation/Liegenschaftskataster/ETRS89-UTM/

Any help on how to use that grid in Manifold 9 is greatly appreciated.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

Dimitri


7,413 post(s)
#08-Jan-18 06:27

Specifically I would like to use the ntv2 grid (BWTA2017) for the German sate of Baden-Württemberg that was issued recently.

When was it issued? Is is openly published without restrictions on use? Can you post it here in a zip file so that anybody can use it however they want?

BerndD

162 post(s)
#08-Jan-18 14:49

The ntv2 grid (BWTA2017) for the German sate of Baden-Württemberg was issued in December 2017.

The file is too big to upload it on the this forum (I tried several times).

I will send it to tech@manifold.net instead.

If you want to download it, please use the link below and scroll all the way to the bottom to where it says DOWNOLAD.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

Dimitri


7,413 post(s)
#09-Jan-18 05:10

The key question remains: Is is openly published without any restrictions of any kind on who may use it or how they may use it?

It never fails to amaze me how sometimes one must emphasize over and over what the word "any" means, but regrettably that is a consequence of how laws work. It is not my doing, so anybody reading this should not blame the messenger. :-)

So, when I ask "Are there any restrictions on use?" and somebody replies, "Oh, no... no restrictions at all! It is open... " it is often the case that there are indeed restrictions. So, sometimes when I follow and I ask more questions like...

"No restrictions, you say? So... I can take this thing and start reselling it as my product under a different name... is that correct?"

"Oh, no, you can't do that. You have to register at the web site to get it, and part of that registration requires you to agree to a contract. You must give credit to the originator, you cannot change the name of it, and you cannot use it for anything that involves money or profit, like in a business, and you cannot pass it on to any third party, and you must (etc, etc.) .... do those count as restrictions?"

So, forgive me for being persistent about this, but whether or not something has restrictions of any kind is a very big deal, at least for law-abiding enterprises.

BerndD

162 post(s)
#09-Jan-18 15:15

I will double check with the GIS department of that state.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

adamw


10,447 post(s)
#08-Jan-18 07:15

We need to fill in a couple of items in the UI to indicate and control whether or not a particular conversion is using a grid, and if so which one. This is coming.

BerndD

162 post(s)
#08-Jan-18 21:33

Great, that would help a lot.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

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