[MetaCRS] failed epsg wkt (geotools)

[Martin Desruisseaux]

Mikael Rittri a écrit :
> * EPSG:3388, Pulkovo 1942 / Caspian Sea Mercator
> 
> According to EPSG, the projection method is "Mercator (2SP)", coord op method 9805, 
> with a standard parallel at 42°N.
> But on SpatialReference.org, the projection method in OGC WKT is given as "Mercator_1SP", 
> and the standard parallel is absent from the parameters.

Thanks for the note. Just for record and because Christopher reported testing
GeoTools for an eventual usage in SpatialReference.org, I tested that GeoTools
2.x produces a WKT closer to the expected one, using "Mercator_2SP" projection
and the correct standard parallel value. The output from GeoTools 2 is:

PROJCS["Pulkovo 1942 / Caspian Sea Mercator",
  GEOGCS["Pulkovo 1942",
    DATUM["Pulkovo 1942",
      SPHEROID["Krassowsky 1940", 6378245.0, 298.3, AUTHORITY["EPSG","7024"]],
      TOWGS84[-40.595, -18.55, -69.339, 2.508, -1.832, 2.611, -0.8867324020562674],
      AUTHORITY["EPSG","6284"]],
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
    UNIT["degree", 0.017453292519943295],
    AXIS["Geodetic latitude", NORTH],
    AXIS["Geodetic longitude", EAST],
    AUTHORITY["EPSG","4284"]],
  PROJECTION["Mercator (2SP)", AUTHORITY["EPSG","9805"]],
  PARAMETER["standard_parallel_1", 42.0],
  PARAMETER["latitude_of_origin", 0.0],
  PARAMETER["central_meridian", 51.0],
  PARAMETER["false_easting", 0.0],
  PARAMETER["false_northing", 0.0],
  UNIT["m", 1.0],
  AXIS["Northing", NORTH],
  AXIS["Easting", EAST],
  AUTHORITY["EPSG","3388"]]

I also tested that it reports "Oblique_Mercator" (not "Hotine_Oblique_Mercator")
for the 10 others reported issues.

However issues with GeoTools 2.x (to be adressed in geotidy/geotools 3):

  * Some parameter name in Geotools 2 are inacurate (for example
    LambertAzimuthalEqualArea has a "longitude_of_center" instead
    than the "central_meridian" used in most other projections).
    This is already fixed in geotidy.

  * The TOWGS84 string, will extracted from the EPSG database, are
    not always the most appropriate one when EPSG defines many datum
    shift for the same CRS. This is an issue I plan to fix soon.

	Martin