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