[MetaCRS] Introduction

[Martin Desruisseaux]

Hi all

I would like put my 2 cents...

Rutger Bezema a écrit :
> The deegree framework already had a spatial reference package written by Martin
> Desruisseaux (now developing for geotools).  Because of the fact that no one was
> maintaining this code, it was very out of date, and didn't fulfill current
> requirements. That is why the PSC of deegree assigned me with the task to
> rewrite the complete package to the current needs of the deegree framework. 

This is true that the package adopted by Degree was not maintained, but this is 
because the development moved to GeoTools. This package got really extensive 
hacking for the last years.

This is a not-well known fact that GeoTools referencing module is independant 
and can be used without the remainding of GeoTools. Degree could have choosen to 
use only this referencing module and would benefit from all the work done during 
the last 4 years.



> These basic design goals were following, the crs package should be
>  -- easy to use,
>  -- easy to maintain,
>  -- fairly easy extendable with regard to user defined projections, transformations and components
>  -- configurable with respect to the definitions of projection and transformation parameters, preferably supporting different formats
>  -- independend of the rest of the deegree framework.

I believe that the GeoTools referencing framework already meet those goals, 
except maybe the "easy to maintain" part (but there is reason for complexity; we 
have done a lot of effort for keeping this module as clear as we can). As you 
point out, proj4 is complex as well. As long as I'm commited to maintain this 
module (and I have done so for more than 5 years), this issue may be slightly 
less sensitive...

In addition of the above points, GeoTools can parse and format WKT and connect 
directly to an EPSG database, which is an important source of CRS as pointed out 
in recent mail discussion. GeoTools is not limited in anyway to those sources; 
it has a sophesticated mechanism built on top of standard Java service API for 
plugins arbirtrary source of CRS.

If nevertheless peoples feel the need for creating a new referencing framework, 
then I would like to push for implementing GeoAPI interfaces. You don't need to 
implement all of them, you can focus only on the ones you care about. Because 
they are only interfaces, the cost is not very high. The are derived from ISO 
19111 and OGC specification, implemented in GeoTools and partially implemented 
in JScience, so there is already at least 2 projects implementing them (I 
believe that gvSig implement them as well, so we get 3 projects). If Degree 
choose to implement them as well, it would give yet more choice to users so they 
can switch between different implementations without rewriting their code:

     http://geoapi.sourceforge.net/snapshot/javadoc/index.html

So I could understand that some peoples don't like GeoTools implementation for 
whatever reasons, but I would like to understand what is wrong with GeoAPI for 
having Degree ignoring it? Its purpose is exactly what this mailing tries to 
achieve, but on an API side rather than test and data side: sharing. JDBC is an 
example of successful story of common API designed by interfaces...

	Martin