[MetaCRS] Google Spherical Mercator (EPSG:3785)

[Martin Desruisseaux]

Hello Frank

Frank Warmerdam a écrit :
> My understanding is that we really want to treat the lat/long values
> on datum EPSG:6055 as if they were equivelent to lat/long values
> on the WGS84 datum.

Not sure if this is of any help, but there is the way we defined the WKT format 
for the Google projection in GeoTools. We did that before the Google projection 
has been added to the EPSG database, so our approach is slightly different.

We assume that the Google projection "cheats" in that it pretends to be on the 
WGS84 ellipsoid while forcing the mercator projection to spherical formulas. In 
other words, instead than the EPSG way:

     Custom     DATUM["Popular_Visualisation_Datum"]
     Standard   PROJECTION["Mercator_1SP"]

We feel that the following is closer to what Google intends:

     Standard   DATUM["WGS84"]
     Custom     PROJECTION["Mercator_1SP forced to spherical"]

However, instead than defining a new projection ("Mercator_1SP forced to 
spherical"), we took an other approach. The usual way to define a Mercator_1SP 
projection is like below:

     PROJECTION["Mercator_1SP"],
     PARAMETER["central_meridian",0],
     PARAMETER["scale_factor",1],
     PARAMETER["false_easting",0],
     PARAMETER["false_northing",0]

Where the "semi_major" and "semi_minor" parameter values are inferred from the 
ellipsoid.

Instead than the above we added a rule in the GeoTools WKT parser saying that if 
the "semi_major" or "semi_minor" parameters are explicitly defined in a 
PARAMETER[...] element, then they have precedence over the values inferred from 
the ellipsoid.

Given that, the Google projection can be defined as below (trimming the WKT 
elements that are not essential to this discussion):

   PROJCS["Popular Visualisation CRS / Mercator",
     GEOGCS["Popular Visualisation CRS",
         DATUM["WGS84", SPHEROID["WGS84",6378137.0, 298.257223563]]],
     PROJECTION["Mercator_1SP"],
     PARAMETER["semi_major", 6378137],
     PARAMETER["semi_minor", 6378137],
     PARAMETER["central_meridian", 0],
     PARAMETER["scale_factor", 1],
     PARAMETER["false_easting", 0],
     PARAMETER["false_northing", 0]]



> However, the way I apply TOWGS84[] translations is to convert
> the lat/long values to geocentric coordinates on the source spheroid,
> apply the offset, and then transform back to lat/long on the destination
> spheroid. The vast difference between the WGS84 and spherical
> spheroids is resulting in a large latitude shift.

Yes. Same for GeoTools.

Using the approach defined above solve the problem without any change to WKT 
syntax or new WKT keyword, provided that we accept a new rule:

    If PARAMETER["semi_major"] or PARAMETER["semi_minor"] elements are
    explicitly defined in the list of PROJECTION parameters, then they
    have precedence over the values inferred from the ELLIPSOID element.

However this is different than what EPSG does, so we need special handling for 
Google projection when connecting directly to an EPSG database (this special 
case is not yet implemented in GeoTools).

	Martin