[OSGeo-Discuss] Research For Shared Java CRS Library

2008-05-05 Thread 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.___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Research For Shared Java CRS Library

2008-05-05 Thread Justin Deoliveira




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.
Just to chime in about GeoAPI. From someone who has had to implement a 
number of its interfaces here are my thoughts.


1) Its a great way to talk about standards in the context of java interfaces

2) Its not a good way to promote interoperability

Now this is just my opinion of course so take it with a grain of salt. 
But anyone who has looked at the geoapi interfaces can tell you they are 
not simple. Which creates a large entry barrier for someone wanting to 
implement them, which defeats the entire purpose.


I would think by definition a library which is intended to be used as a 
base for other projects needs to be as simple as possible. Look at proj 
for instance, i am by no means an expert on the code base but from what 
I have seen there are no unnecessary abstractions. Which I would think 
is a large part of the reason it has been utilized so effectively by 
most of the other projects in the C and python community.


My 2c.

-Justin



 


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. !DSPAM:4007,481f601c109671628642973!





___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


!DSPAM:4007,481f601c109671628642973!



--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


RE: [OSGeo-Discuss] Research For Shared Java CRS Library

2008-05-05 Thread Landon Blake
Thanks for the input Justin.

I agree simplicity (and the broad adoption that results from simplicity)
is a primary goal. We shouldn't let GeoAPI stand in the way of that.

Does anyone know how much of the existing GeoTools code is actually
based on the CRS interfaces in GeoAPI? Is anyone besides GeoTools using
the GeoAPI interfaces for a CRS library implementation in Java?

Landon

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Deoliveira
Sent: Monday, May 05, 2008 1:20 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Research For Shared Java CRS Library


 
 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.
Just to chime in about GeoAPI. From someone who has had to implement a 
number of its interfaces here are my thoughts.

1) Its a great way to talk about standards in the context of java
interfaces

2) Its not a good way to promote interoperability

Now this is just my opinion of course so take it with a grain of salt. 
But anyone who has looked at the geoapi interfaces can tell you they are

not simple. Which creates a large entry barrier for someone wanting to 
implement them, which defeats the entire purpose.

I would think by definition a library which is intended to be used as a 
base for other projects needs to be as simple as possible. Look at proj 
for instance, i am by no means an expert on the code base but from what 
I have seen there are no unnecessary abstractions. Which I would think 
is a large part of the reason it has been utilized so effectively by 
most of the other projects in the C and python community.

My 2c.

-Justin

 
  
 
 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. !DSPAM:4007,481f601c109671628642973!
 
 


 
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss
 
 
 !DSPAM:4007,481f601c109671628642973!


-- 
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


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.
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Research For Shared Java CRS Library

2008-05-05 Thread Jody Garnett

Landon Blake wrote:


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 that sentence there *is* the definition of the GeoAPI project; 
originally started for Deegree and GeoTools to work together :-) Let's 
have a look and see if it meets those goals...


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.


So would you like us to join the MetaCRS mailing list? And continue the 
discussion there? Or is this a good osgeo-discussions topic?


Cheers,
Jody
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Research For Shared Java CRS Library

2008-05-05 Thread Jody Garnett

Landon Blake wrote:

I agree simplicity (and the broad adoption that results from simplicity)
is a primary goal. We shouldn't let GeoAPI stand in the way of that.
  
Even just taking the abstractions as defined by GeoAPI and turning them 
into classes would remove one level of complexity.


I view GeoAPI as a great way to communicate; especially for people like 
me that do not have access to the original ISO specifications. I also 
find it is easier to pick up a set of Java interfaces than read OGC 
specifications; but your millage may vary...

Does anyone know how much of the existing GeoTools code is actually based on 
the CRS interfaces in GeoAPI?
99% you need a single GeoTools class to get in the game; it is called 
CRS and looks a little like the following:


class CRS {
  CoordianteReferneceSystem decode( String code );
  CoordianteReferenceSystem parseWKT( String wkt );
  CoordinateReferenceSystem lookupIdentifier( CoordianteReferenceSystem 
crs, boolean fullScan );
  MathTransform findMathTransform( CoordinateReferenceSystem source, 
CoordinateReferenceSystem target );

  //  ... other methods I don't personally use
}

There are two other things worth mentioning:
- There is a JTS utility class (called JTS) that will take that 
MathTransform above and use it to hack away at a JTS Geometry.
- If you want to customize your experience you can look up another 
GeoTools class called Hints in order to force XY order and all that 
kind of stuff



Is anyone besides GeoTools using the GeoAPI interfaces for a CRS library 
implementation in Java?
  
I better let Martin answer that one, I cannot remember.  The JScience 
project contains a copy of parts of GeoAPI but mostly they went their 
own way. Deegree 2.x contains a previous version of the GeoTools 
implementation (based on a set of OGC interfaces  rather than the ISO ones).


So yes different projects at different times, the question for me is 
is this it or are the ISO specifications going to change on us? They 
have been pretty good so far; one correction document in 2005 I think; 
but that is probably a discussion for the standards email list.


Jody
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss