[OSGeo-Discuss] Research For Shared Java CRS Library

[Landon Blake]

A fellow OSGeo member suggested that I move a topic from a private
e-mail discussion to this mailing list. I have been talking with a
couple of the guys from GeoTools, a couple of the guys from deegree, and
a couple of guys from OpenJUMP about a shared Java CRS library. There
are a lot of different opinions on the state of current libraries and on
how to move forward on any shared library. Despite this I think there is
room to share CRS definitions, algorithms and test cases among the
different projects, and at some point in the future (maybe a couple of
years from now), to share code.

 

We would like to continue discussions on the obstacles and issues we
will face in forming and maintaining a shared library (or other shared
resources) over the long run. 

 

I believe at the current time there are two (2) main libraries used for
CRS work in the Java communities. There is the CRS code in GeoTools and
the CRS code in deegree. I think there may also be some personal and
independent CRS libraries maintained by some well-known and active Java
GIS programmers.

 

I have started a wiki page on the OSGeo wiki to discuss collaboration on
a shared Java library for CRS work. On this page I have created a list
of questions about the current implementations of these existing CRS
libraries. I think an important first step in any collaboration is
answering these questions. I have posted a link to the questions for the
deegree CRS code below:

 

http://wiki.osgeo.org/wiki/Java_CRS:_Details_on_Deegree_CRS_Code

 

Over the course of the next couple of weeks I will work on answering
these questions for the deegree and GeoTools CRS code. I'll be reading
over the Javadoc for each library and past e-mail threads to do this.
(I'll also be annoying members of each project's developer mailing
list.) I welcome any assistance with this research.

 

After I have answered these questions for at least the GeoTools and
deegree CRS code I will try to come up with a plan for collaboration.
This plan will start out with modest goals. I'll look first at sharing
CRS definitions, algorithms, and test cases. Then I'll look at sharing
"neutral" utility code. In the final stages of the plan I'll look at
refactoring common classes and/or interfaces from each library into a
shared library, with the ultimate goal on creating one shared, low-level
Java CRS library.

 

I will post this plan here so others can review and comment on it. 

 

I'm not sure where all of this will lead, or if anything will come of
it, but I know we can accomplish a great deal if we can get some of the
sharp minds in the different Java GIS projects working together instead
of independently.

 

I know some of you want to know why we aren't just going to use the
GeoAPI interfaces. I don't know enough about the GeoAPI code to say that
it won't be used. I think that will need to be part of our research
process. It would make sense to use GeoAPI as a home for common
interfaces if this is possible. I don't want to reinvent any existing
technology. 

 

Landon

 

P.S. - I have subscribed to the MetaCRS mailing list. I will post
messages there about any decisions made on sharing
"programming-language-independent" (PLI) resources like CRS definitions
or test cases.

 

 

 



Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20080505/a8bc3528/attachment-0002.html>