[MetaCRS] representation of spherical projections

[Mikael Rittri]

Christopher Schmidt wrote: 

> Loading data from the EPSG database is a tedious and confounding process, ... 

Sure. I am very happy that other people are doing it, so I don't have to try myself!
Thanks again.  

> ... please feel free to offer anymore that you find which are incorrect. 

Well, there is a problem with all projections that use spherical formulas, 
but the problem (I would say bug) seems to be part of the ESPG database.
So it is probably impossible to resolve it before the GIS community has agreed 
on a standard way to describe coord. ref. systems based on spherical projections 
- a way that is better than the EPSG way.  I guess this won't happen soon. 

This problem has been discussed recently on the Proj mailing list, and on 
this list as well (in August 2008).  But it worries me, so I'll try to 
give a summary.

One instance of the problem is the EPSG definition of what I 
think of as "WGS84 / Web Mercator", although the EPSG name is 
"Popular Visualisation CRS / Mercator", EPSG:3785. 

Many (but not all) authorities, on this list and on the Proj list,
would say that the datum of this CRS should be WGS84 and nothing else, 
even though the projection method uses spherical formulas (using the 
equatorial radius of WGS84 as the sphere radius).  

However, EPSG says that the datum is "Popular Visualisation Datum", which
has a spherical reference ellipsoid. What is worse, EPSG gives a 3-parameter 
transformation to WGS84, corresponding to

    TOWGS84[ 0, 0, 0, 0, 0, 0, 0] 

(EPSG coordinate transformation code 15973), which just does not work.
And EPSG knows it does not work, since they say 

    Scope: Web mapping. Accuracy may be no better than 800 metres.
    Remarks: Executes change of sphere/ellipsoid. 

If we must accept that the datum of the CRS has a spherical reference ellipsoid,
then the correct way to convert lon/lat from this "Popular Visualisation Datum" 
to WGS84 is to do nothing at all (use the identity function), which gives
perfect accuracy.  

The transform

    TOWGS84[ 0, 0, 0, 0, 0, 0, 0]

does not express the identity function in this case, because the 
polar radii differ between the spherical datum and WGS84.  

I believe what I say here is accepted in the GIS community 
( http://trac.osgeo.org/proj/wiki/FAQ#ChangingEllipsoidWhycantIconvertfromWGS84toVirtualGlobeMercator ).
Well, some authorities are saying that spherical projections for 
large scale maps are an abomination that should never be used.  
And that is a valid opinion, of course.  But I think no one (except
EPSG) claims that the datum transform from sphere to WGS84 ellipsoid
via TOWGS84[ 0, 0, 0, 0, 0, 0] gives better results than the 
identity function.  

Now, I am not sure what I would like SpatialReference.org to do 
about the problem.  For EPSG:3785, SpatialReference.org does give 
a faithful representation of what's in the EPSG database. It just
doesn't work well in applications.  But I might suggest:

 - Don't reproduce a datum shift TOWGS84[ 0, 0, 0, 0, 0, 0, 0] 
   when EPSG says that the datum is spherical.  Since you don't 
   always give a TOWGS84 clause, this omission should be allowed. 
   I think most applications would be better off without this datum 
   shift. 

 - In the proj4 representation, the datum shift should not be 
      +towgs84=0,0,0,0,0,0,0
   but 
      +nadgrids=@null 
   as in the proj4 FAQ. 

 - A more general solution for WKT would require that the GIS 
   community agrees how WGS84 / Web Mercator should be expressed. 
   Some suggestions were made on this list in August
   ( http://lists.osgeo.org/pipermail/metacrs/2008-August/thread.html ).
   I would personally prefer if the datum were given as WGS84, as
   GeoTools does ( http://lists.osgeo.org/pipermail/metacrs/2008-August/000143.html ). 
   But such a representation would violate the EPSG terms of use, 
   if one claimed that the CRS were the same as EPSG:3785, since 

     "No data that has been modified other than as permitted in 
      these Terms of Use shall be attributed to the EPSG Dataset."
      (http://www.epsg.org/databases/Discv6_18.html paragraph 6.7).

Best regards,

--
Mikael Rittri
Carmenta AB
Box 11354
SE-404 28 Göteborg
Visitors: Sankt Eriksgatan 5
SWEDEN
mikael.rittri at carmenta.com
www.carmenta.com