ETRS89-based CRSs missing datum definition?

[proj4-bot]

Reported by msieczka on 14 Aug 2008 11:46 UTC
PROJ 4.6.0 does not apply a datum shift reprojecting between a CRS which has an implicit datum definition (e.g. Pulkovo 1942/58-based EPSG 4179, for which GDAL uses towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84) and an ETRS89-based CRS, e.g. EPSG 2180, that has no implicit towgs84 or datum.

The above results in reprojection errors of dozens of meters and makes using EPSG codes for ETRS89-based CRS unreliable. Should PROJ.4 and GDAL enforce towgs84=0,0,0 for all ETRS89 CRSs that have no implicit datum definition otherwise?

There are 58 CRSs in PROJ.4 4.6 epsg file that are based on ETRS89 datum (including e.g. pan-European LCC EPSG 3034 or LAEA EPSG 3035). Using any of their EPSG codes leads to huge reprojection errors.

Example:

The source EPSG 4179 is Pulkovo 1942(58) based, target EPSG 2180 is ETRS89 based. Since no explicit towgs84 is specified for EPSG 2180 but there is for EPSG 4179, GDAL fails to perform the datum shift and returns a wrong result:

$ echo "16E 52N 64" | gdaltransform -s_srs EPSG:4179 -t_srs EPSG:2180
294132.884446735 463557.976146893 64

The correct reprojection is possible if the EPSG 2180 definition is given in proj4 format plus +towgs84=0,0,0:

$ echo "16E 52N 64" | gdaltransform -s_srs EPSG:4179 -t_srs "+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +towgs84=0,0,0"
294006.094422874 463523.916413687 103.090447655879

For instance, GRASS always forces towgs84=0,0,0 for EPSG 2180 and does the reprojection right. I'm not 100% sure if towgs84=0,0,0 is the correct, ultimate solution, but there is something to it.

Migrated-From: https://trac.osgeo.org/proj/ticket/11

[proj4-bot]

Comment by warmerdam on 14 Aug 2008 14:03 UTC
I'd like some supporting documentation indicating that ETRS89 is essentially equivelent to WGS84.

[proj4-bot]

Modified by neteler on 15 Aug 2008 13:39 UTC

[proj4-bot]

Comment by martinoty on 15 Aug 2008 17:26 UTC
In my opinion, the problem is not related to Proj.4 but to EPSG's definitions. It's up to EPSG to put corrected definitions in its database with towgs84=0,0,0.

I think it would not be a good idea making "exceptions" in proj.4 code in order to cope with problems in CRS definitions.

[proj4-bot]

Comment by warmerdam on 22 Aug 2008 15:06 UTC
In fact, if an exception is made I believe it would be done as part of the gcs.override.csv file in libgeotiff. This is used when building the GDAL gcs.csv file from the EPSG definitions and from which the PROJ.4 definitions are eventually derived.

So we already do have a "practice" for overriding EPSG - often used to select one preferred datum shift from several options. But I hate to extend this without some clear indication it is a good idea.

I haven't actually reviewed the EPSG database - does it not have any transformations from ETRS89 to WGS84?

[proj4-bot]

Comment by warmerdam on 22 Aug 2008 15:32 UTC
Testing email notification enablement...

[proj4-bot]

Comment by msieczka on 22 Aug 2008 18:26 UTC
Replying to warmerdam:

I'd like some supporting documentation indicating that ETRS89 is essentially equivelent to WGS84.

I have an indirect clue. At CRS-EU website one can find transfomartion paramaters for local datum to ETRS89. Now, EPSG dataset uses exactly the same parameters for local datum to WGS84 transformation. In my naiveness, it indicates that WGS84<->ETRS89 = 0,0,0,0,0,0,0.

[1]http://crs.bkg.bund.de/crs-eu/

[proj4-bot]

Comment by msieczka on 1 Sep 2008 11:31 UTC
Document [tries to directly answer the question "What is the difference between WGS84 and ETRS89?".

Doc 2 is a longer discussion about "Global and European Reference Systems: Theory and Practice".

Doc [has a nice chapter "The relationship between ETRS89 and WGS84".

They say there is a shift of about 1-2.5 cm between WGS84 and ETRS89 a year. For now, the overall drift between WGS84 and ETRS89 is about 50 cm - and this is the transformation error if we assume them equivalents. On the other hand, if we don't assume them as such, the error is dozens of meters.

Technically neither is good. But 0,5 m is less bad than an error hundreds times bigger. Moreover, let's not forget that any 7 parameter datum transformation that GDAL and dependent software widely use, involves an error of circa 1m (e.g. a transformation from Potsdam or Pulkovo to WGS84). Last but no least, let's keep in my mind that until PROJ.4 4.6.0 (see 4 for an extract of related cahnges in that release) the transformation between WGS84 and ETRS89 technically was 0,0,0,0,0,0,0 and nobody complained (AFAIK).

Sumarizing, I think we can assume towgs84=0,0,0,0,0,0,0 for ETRS89, because:

1. This will reduce the datum shift error from dozens of meters to less than 1.
2. Such an accuracy is consistent with any other towgs84 which PROJ.4 and GDAL have been supporting for years.
3. Until December 2007, the equivalency of ETRS89 and WGS84 was a fact in PROJ.4, and that worked.

[1]http://www.ordnancesurvey.co.uk/oswebsite/gps/osnetfreeservices/about/faqs_osnet.html#1

[2]http://www.gps.oma.be/gb/refsys_gb_ok_css.htm

[3]http://www.ogp.org.uk/pubs/373-10.pdf

[4]related PROJ.4 4.6.0 changes:

 o MAJOR: Rework pj_transform() to avoid applying ellipsoid to ellipsoid transformations as a
   datum shift when no datum info is available.

 o Avoid applying "change of ellipsoid" during datum shifting based on
   ellipsoids getting changed to spheres for spherical projections.

[proj4-bot]

Comment by ajolma on 30 Dec 2008 10:23 UTC
I'm also interested in this issue. See http://n2.nabble.com/Shift-to-WGS84-on-two-coordinate-systems.-tt2065133.html and the links to the two tickets in that mail.

I suggest adding two lines to gcs_override.csv, which is a part of libgeotiff: http://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv

4123,KKJ,6123,Kartastokoordinaattijrjestelm 1966,6123,9122,7022,8901,1,0,9606,-96.0617,-82.4278,-121.7435,4.80107,0.34543,-1.37646,1.4964
4258,ETRS89,6258,European Terrestrial Reference System 1989,6258,9122,7019,8901,1,0,9603,0,0,0,0,0,0,0,0

[proj4-bot]

Comment by borysiasty on 16 Dec 2009 16:39 UTC
This is probably the best place to note that I've just fixed it temporarily and internally in QuantumGIS (r12490 / ver>=1.4) by adding the towgs84=0,0,0,0,0,0,0 to its database (sqlite file srs.db) for crses 2176-2180.

However it's not a real solution as the layer projection definition still has to contain the towgs84 patameter. I.e. layers produced by ogr2ogr or shapefiles from ArcGis are invalid until you add that parameter manually.

[proj4-bot]

Comment by warmerdam on 27 Feb 2010 21:42 UTC
As part of a recent upgrade to libgeotiff, the 0,0,0 towgs84 values are now selected for ETRS89. This will make it into PROJ.4 next time the epsg database is regenerated. I'll leave this ticket open pending that update.

[proj4-bot]

Comment by warmerdam on 1 Mar 2010 01:38 UTC
epsg init file upgraded (d3753ed1 (SVN rev1824)).