[bezema@lat-lon.de: Re: [martin.desruisseaux@geomatys.fr: Re: [MetaCRS] Introduction]]

[Rutger Bezema]

Hi all, 

let me start by saying, that I'm sorry if I've offended anyone with my
introduction mail, it was not my intention.  I was merely trying to signal, that
the deegree project is very willing to participate on the discussion of a common
crs model which could be interesting for a broad variety of users, without going
into the discussion on distinct project policies or philosophies. 

Because I am with the deegree project for only two years, I personally do not
know all considerations on the movement of deegree away from geoapi. What I'm
told, is that much of the PSC decisions were based on a different interest
foundation on both fronts. 

To explain the deegree project's considerations on the rewriting of the api: 

we were faced with different customer requirements to implement specific
projections and some enhancements to the transformations, which is why we've
evalutated different spatial reference frameworks. We even integrated the proj4
library with a jni interface. Sadly we found, that a lot of our customers were
appalled by the idea of a c-library into a java framework, which is why we got
back from this.  It was concluded, that it would be beneficial (for us and other
frameworks as well), to create a new "lightweight" spatial reference library and
formed the design goals, as stated yesterday. 

We are aware of the potential short comings of our implementation in some use
cases, but are convinced that the framework is more than sufficient in most
ones. 

So I would like to state again that it would be nice to combine our resources
and to participate in crs-related discussions, but I must point out that
different projects may have different needs which can hopefully be taken into
account to our mutual benefit.

I hope to have cleared the air a little :-)

with kind regards,
Rutger Bezema



Martin Desruisseaux wrote:
> 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
> 

-- 
l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 +228 184960       fax ++49 +228 1849629
http://www.lat-lon.de        http://www.deegree.org

-------------------------------------------------------
On June 17 is deegree day - Am 17. Juni ist deegree day
              http://deegree.org/deegreeday
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/metacrs/attachments/20080514/9f4dcce0/attachment.bin