Google projection ("EPSG:900913" is a weird spherical "Mercator1SP" projection using sphere radius equals to the WGS 84 semi-major axis length, but with "sphere to ellipsoid" conversion disabled.
In other words, it is very similar to "EPSG:3395" with the flattening factor 298.257223563 replaced by 0 (a sentinal value for infinity) in the WKT. However we can not declare the Google projection just that way, because it has one weird behavior: when transforming from Google projection to any other CRS, for example WGS 84, the "sphere to ellipsoid" conversion should not be applied. So we need a way to disable this conversion using standard (if possible) WKT syntax. The proposed syntax is:
This WKT is almost identical to the standard "WGS 84 / World Mercator" WKT, except that the "semi_major" and "semi_minor" parameters are explicitly defined. Usually those parameters should not be provided because they are inferred from the SPHEROID element. If they are provided anyway, current GeoTools implementation checks if the values are identical to the ones inferred from the spheroid. I don't remember what is the current behavior if they differ - throwing an exception or just logging a warning. This need to be checked.
The proposed fix is:
- Allows the values of PARAMETER["semi_major", ...] and PARAMETER["semi_minor", ...] to differ from the values inferred from the SPHEROID element. Maybe we should log a warning for any CRS other than the Google one since such mismatch is usually an error - this need to be determined.
- Make sure that GeoTools uses PARAMETER["semi_major", ...] and PARAMETER["semi_minor", ...] for map projections. I believe that this is already the case. If GeoTools checks the consistency with SPHEROID, replace the exception by a warning, with no warning at least in the Google case.
- Make sure that GeoTools uses SPHEROID for datum shifts. I believe that this is already the case.
- Make sure that WKT formatting includes the PARAMETER["semi_major", ...] and PARAMETER["semi_minor", ...] elements if they differ from the values inferred from the SPHEROID element.
That way, GeoTools would not apply any datum shift between Google projection and WGS 84 because the datum is already declared as WGS 84, but would still uses the spherical equations for the projection because of the PARAMETER["semi_minor", 6378137.0] element, which differs from what would have been inferred from SPHEROID. No WKT extension is required. The only thing we need to do is to make sure that GeoTools accepts a PARAMETER / SPHEROID mismatch and use the right elements for the right operation (PARAMETER for map projection, SPHEROID for datum shift).