utm/GRS80 to tmerc/intl conversion poor now, was good in 4.4.9

[janne]

The +towgs84 parameters in the epsg file of version 4.6.1 are incorrect. These are not the TOWGS84 parameters of the current or even the prior versions of the real EPSG database. Additionally the parameters in the Proj4's epsg file are the same.

List of CRSs having wrong parameters: EPSG:2391 EPSG:2392 EPSG:2393 EPSG:2394 EPSG:3385 EPSG:3386

[janne]

By saying that the parameters are the same, I mean that it is enough to just compare the TOWGS84 values of a single CRS.

[ajolma]

Janne,

What would be the correct parameters and where can I see them in the real EPSG database?

[ajolma]

It is not the towgs parameters, but something else. Below the result with 4.4.9 is good (very similar to what conversion program from NLS Finland gives) while the results with 4.6.1 is not good.

[ajolma@vesi-110 ogr]$ cs2cs -? Rel. 4.4.9, 29 Oct 2004 [ajolma@vesi-110 ogr]$ cs2cs +proj=utm +zone=35 +ellps=GRS80 +units=m +no_defs +to +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs 353250 6690840 3353360.61 6693649.65 -24.80 [ajolma@vesi-110 ogr]$ cs2cs -? Rel. 4.6.1, 21 August 2008 [ajolma@vesi-110 ogr]$ cs2cs +proj=utm +zone=35 +ellps=GRS80 +units=m +no_defs +to +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs 353250 6690840 3353183.92 6693674.70 0.00

[warmerdam]

Copying Ari's example in a more readable format:

 [ajolma@vesi-110 ogr]$ cs2cs -?
 Rel. 4.4.9, 29 Oct 2004
 [ajolma@vesi-110 ogr]$ cs2cs +proj=utm +zone=35 +ellps=GRS80 +units=m
 +no_defs +to +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0
 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m
 +no_defs
 353250 6690840
 3353360.61      6693649.65 -24.80
 [ajolma@vesi-110 ogr]$ cs2cs -?
 Rel. 4.6.1, 21 August 2008
 [ajolma@vesi-110 ogr]$ cs2cs +proj=utm +zone=35 +ellps=GRS80 +units=m
 +no_defs +to +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0
 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m
 +no_defs
 353250 6690840
 3353183.92      6693674.70 0.00

Note that the behavior of PROJ.4 changes in 4.6.0 so that no attempt is made to do a datum or ellipsoid transformation if the source and destination coordinate system do not both have datum shift info available. So in the above case 4.4.9 would convert from GRS80 to geocentric, then apply the towgs84 for the second coordinate system (in reverse) and back to intl coordinates. In 4.6.0 no change is applied between the datum/ellipsoids.

If you want the old behavior you need to attach a +towgs84=0,0,0 to the coordinate systems with only an ellipsoid and no other datum shift info.

Please close unless you can confirm there is some other issue in play here.

[ajolma]

[ajolma@vesi-110 ~]$ cs2cs -?
Rel. 4.6.1, 21 August 2008
[ajolma@vesi-110 ~]$ cs2cs +proj=utm +zone=35 +ellps=GRS80 +units=m +no_defs +to +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs
353250 6690840
3353183.92      6693674.70 0.00
[ajolma@vesi-110 ~]$ cs2cs +proj=utm +zone=35 +ellps=GRS80 +units=m +towgs84=0,0,0 +no_defs +to +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=3500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs
353250 6690840
3353360.61      6693649.65 -24.80

oops, maybe we (me and Janne) should RTFM sorry!

[ajolma]

Hmm, one more thought. I stumbled upon this when I was using ogr2ogr and EPSG codes (3067 and 2393) - I believe Janne also used EPSG codes. Is the reason in that case that there's no +towgs84=0,0,0 in 3067 (proj4 epsg file)? (I don't have a clear understanding when pcs.csv of GDAL is used and how)

[ajolma]

Thinking aloud here, sorry. Yes. Adding +towgs84=0,0,0 to epsg 3067 corrects the issue. And I believe that change should be made to the Proj4 source code.

[warmerdam]

Ari,

Is ETRS89 explicitly equivelent to WGS84? Can you provide references?

Our normal practice is to include "shift to wgs84" info for datums if there is one and only one shift offered in the EPSG database. If there are more than one or none we don't do anything with the exception of a few reasonably carefully considered overrides which go into gcs.override.csv in libgeotiff.

The EPSG initialization file explicitly does not have towgs84 parameters for many datum because we don't know the shifts that are appropriate. Providing +towgs84=0,0,0 just fools people into thinking we know what to do when we don't. The current approach is predicated on the principle of doing nothing (datum shift wise) unless we actually know what to do with some authority.

[janne]

Hi,

My mistake of saying that the TOWGS84-parameters were wrong. The parameters just changed to the newer ones at the same time as the upgrade to 4.6.0 occurred and the parameters were not exactly the EPSG-parameters. So I thought they were implemented incorrectly. Instead, they were directly copied from the JHS153, which defines them, and they were correct. I told about this to Ari, but before I found out the exact reason, which you already told here, Ari got the same errors as we did.

About the equivalence of the WGS84 and ETRS89. To be short no, they are not the same. However, the Sub-Commission for Europe (EUREF) under Commission X on Global and Regional Geodetic Networks recommended in 1990 that "the system to be adopted by EUREF will be coincident with ITRS at the Epoch 1989.0 and fixed to the stable part of the Eurasian Plate and will be known as ETRS89." (EUREF, 1991). The Sub-Commission also accepted that the system coincides with the WGS84 at the one meter level. Later on NIMA (2000) defined that WGS84 can be considered the same as ETRF89. So there is no better realization of the WGS84 in Europe then the ETRS89 (or actually the realizations of the ETRS89).

About the usage of a datum shift only if a single one is defined in the EPSG-db, I've got to ask what is done in the scenario of having for instance two non-deprecated transformations, from which the other overrides the other?

References: EUREF, 1992a. Report on the Symposium of the IAG Sub-commission for the European Reference Frame (EUREF) held in Florence, May 28 – 31, 1990. Veröffentlichungen der Bayerischen Kommission für die Internationale Erdmessung, Heft Nr. 52, 1992.

EUREF, 1992b. Report on the Symposium of the IAG Sub-commission for the European Reference Frame (EUREF) held in Bern, March 4-6, 1992. Veröffentlichungen der Bayerischen Kommission für die Internationale Erdmessung, Heft Nr. 52, 1992.

NIMA, 2000. World Geodetic System 1984. Its Definition and Relationships to Local Geodetic Systems. Third edition. National Imagery and Mapping Agency.

[ajolma]

Janne,

This is already discussed on  http://trac.osgeo.org/gdal/ticket/2639 and I'm going to bring it up on geotiff email list. Geotiff is the original source for coordinate system data for GDAL.

I've also read that ETRS89 and WGS84 are not the same, maybe not even comparable things, but as far as I understand, they can be considered for all practical purposes (Proj.4) the same - the error from treating them the same is less than one meter.

From JHS 153 I read that the best authority is NIMA document TR8530.2.

Ari

[janne]

Ari,

The reference NIMA (2000), which I gave, is the same technical report TR8530.2 :)

About all practical purposes ... yes, when we consider only usage under a transformation precisions less than a meter like in common navigation, else no.

The dilemma is that in GIS the concepts of a coordinate reference system and coordinate reference frame have not been widely used or have been mixed. WGS84 is both a system and set of frames. The latest frame is WGS84(G873), which is given in NIMA(2000). The ETRS89 on the other hand is only a system, therefore you actually can't have any coordinate values in ETRS89. The coordinate values are in some realization of the system. Such realizations are for example the EUREF89, ETRF89, ETRF2000, Swedish SWEREF99 (has own EPSG-codes ;-) ) or the Finnish EUREF-FIN (Many others exist). The ETRF89 is quite often used as a synonym for the ETRS89, even though they differ, like day and night.

The epochs of the realizations differ. For instance the epoch of the EUREF-FIN is 1997.0. This is because the coordinates were reducted to ETRF96, where the epoch is 1997.0. To change the epoch we would need to transform the coordinates to ITRF96, change there the epoch, and then come back to some other ETRFyy corresponding to the epoch of the ITRFyy.

Now to compare the WGS84 with the ETRS89, you have to understand that the ETRS89 is congruent with the ITRS in epoch 1989.0 and the NIMA (2000) states that the WGS84 is congruent with ITRF96 (The year is not mentioned there, but it was at that time the newest realization). Since then the realizations have been drifting apart again. Now the difference is in some decimeters (For a precise transformation to WGS84 we would need like 14 parameters, of which 7 would be time dependant).

Because of the difference between the realizations, it is also wise to have own EPSG-codes for the realizations (as the Swedes have done), but a problem about having own codes becomes relevant when we want to use some common projected CRSs for pan-European mapping, where the 2D geographic CRS is set as “ETRS89”. These projections include for instance the ETRS-LAEA and ETRS-LCC. In such projections the accuracy of a meter is much more than enough and it is irrelevant which realization is used. Currently we have discussed concerning the INSPIRE context that the “ETRS89” codes would be used, instead to the actual codes of the realizations.

Then about the TOWGS84 parameters, which began this whole discussion, used with the projected CRSs. They are actually transformation parameters to the 3D geocentric EUREF-FIN (A realization of the ETRS89), not to WGS84, but because of their precision being less than a meter its irrelevant.

- Janne