[MetaCRS] Re: representation of spherical projections

[Melita Kennedy]

> On Wed, 17 Dec 2008 13:38:59 +0100, Mikael Rittri wrote:
>
> 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).

Mikael,

EPSG has allocated change request 2008.114 about the problem with the
"Popular Visualisation Datum" / WGS84 operation (transformation). At a
minimum, there should a new operation with a different operation
method that does not change the latitude values. I don't know when
that might be though.

Melita