[Geotools-devel] Suggesting some change on epsg extension and fallback mechanism

[Andrea A. <aa...@op...>]

Hi all,
I'd like to suggest some changes as a result of some issues I'm facing
with Geoserver trunk, were epsg-extensions is used.

The first thing I would like to have, is an AbstractFactoryUsingWKT, to
be placed in referencing, that allows custom extensions without having
to depend on espg-extensions. The rationale is, I don't want 
FactoryUsingWKT and FactoryESRI around. The rationale for this 
requirement is better explained in the next paragraphs, but in general
I may not want to have anything but the hsql epsg provider and a custom
extension.
Ideally, AbstractFactoryUsingWKT would be exactly like FactoryUsingWKT,
with two little changes:
* getDefinitionsURL() would be abstract
* it would make the constructor with priority parameter available to 
subclasses, in order to allow implementing both fallback and overriding
factories.
* the default priority would become a protected member of the class, in
   order to make it visible from extending classes that aren't located in
   the same package
Martin, if you agree, I think I can implement this one without problems.

The second thing is a matter of exception reporting. The current
fallback mechanism seems kinda like a linked list, either a class
is able to generate the specificied CRS, or it throws and exception and 
falls back onto the next factory.
This works fine in general, but sports bad error reporting. Say I have
factories f1, f2 and f3. f2 is the only one containing code EPSG:XX, the
others don't know about it.

Suppose f2 is not able to really decode EPSG:XX because of an 
unsupported projection (this is a real use case, to be discussed in a 
separate mail), if that happens, the user will get an error message
stating that f3 is does not contain code XX, which is not the real issue.

In general, it would be nice if the fallback mechanism could distinguish
between "not found" exceptions and real ones. If the end of the fallback 
chain is reached, it should report the real exception. It could be,
for example, the last real error occurred in the chain. This would go
a long way in helping users solve their WKT definition problems.
At the moment, in Geoserver, when an intermediate factory fails to 
create a CRS, the error messages is:

AVVERTENZA: Issues converting EPSG:XXXX. No code "EPSG:XXX" from 
authority "ESRI" found for object of type "IdentifiedObject". Stack 
trace included at FINER logging level

simply because the ESRI factory is the last in the chain, and the real
error message is lost.

Again, if you give me some little guidance, I think I can work on this too.

Cheers
Andrea