Re: [Geotools-devel] The sad state of Oracle CRS parsing

[Martin D. <mar...@ge...>]

Andrea Aime a écrit :
> The issue is, they do
> use projection identifiers that do not conform to the
> EPSG database. For example, 3005, British Columbia equal area,
> has the following projection identifier "British Columbia Albers (EPSG
> OP 19984)" whilst the correct one is "Albers Equal Area".

It took me a while to come back on this issue. I just tried:

java org.geotools.referencing.CRS EPSG:19984

and got

DefiningConversion["British Columbia Albers",
  METHOD["Albers Equal Area", AUTHORITY["EPSG","9822"]],
  PARAMETER["semi_major", �],
  PARAMETER["semi_minor", �],
  PARAMETER["central_meridian", -126.0],
  PARAMETER["latitude_of_origin", 45.0],
  PARAMETER["standard_parallel_1", 50.0],
  PARAMETER["false_easting", 1000000.0],
  PARAMETER["false_northing", 0.0],
  PARAMETER["standard_parallel_2", 58.5],
  AUTHORITY["EPSG","19984"]]


According this WKT, "British Columbia Albers" is the name of the operation
itself, not the name of the operation *method*, which is "Albers Equal Area"...

> The last hope is that 19984 could be used to inspect an EPSG database
> (the hsql one) and come up with the real projection name.
> Martin, is this possible?

This is doable, but introducing a dependencies of WKT parser to the EPSG
database would make the referencing module a little bit more convolved...

We can isolate the EPSG database dependencies in a "OracleMathTransformFactory"
which would wraps the "DefaultMathTransformFactory", inspect the operation name
for a "(EPSG OP XXXX)" label and substitute the name before to delegate to
DefaultMathTransformFactory. One more indirection level in the referencing
module factories!

	Martin