[MetaCRS] Introduction

[Justin Deoliveira]

> 
> 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...

I wanted to throw my 2 cents in on this one. First I just want to say 
that Martins maintanence of the geotools referencing module has been 
exceptional, the code is robust and he is very responsive to issues.

But... I have to disagree with the reasons for complexity, and non easy 
maintainance being a non-issue. In some recent experiments i have been 
looking at both the proj and geotools referencing implementations. And I 
must say i have an easier time understanding proj. And this is quite a 
statement coming from a java programmer.

And I think the issues go beyond complexity as well. The referencing 
module brings along a bunch of dependencies. Its split among two modules 
for one (referencing + metadata). It depends on geoapi, and some other 
third party libraries. While these types of dependencies may add some 
good functionality and result in "clean code", they reduce the ability 
of others to embed the geotools referencing module in their application. 
I have talked to a couple of developers who consider adding a dependency 
which results in more then one jar as "not worth it".

Anyways, bottom line is the code works perfectly as a black box. But if 
I were considering writing an application around it I would be very 
weary of adding a dependency in which I could not understand.

This is just my opinion of course, and apologies if its off topic for 
the list.