ETRS89-based CRSs missing datum definition? about proj

[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)).