[OSGeo-Discuss] Research For Shared Java CRS Library

[Justin Deoliveira]

Pretty much all client code of the referencing/crs subsystem in GeoTools 
goes through GeoAPI. When the switch occurred a few years back the 
maintainers were aggressive about removing direct references to the 
GeoTools implementation classes.

Also, both GeoServer and uDig make extensive use of these interfaces as 
well.

-Justin

Landon Blake wrote:
> 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: discuss-bounces at lists.osgeo.org
> [mailto:discuss-bounces at lists.osgeo.org] 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. 
>>
>>
>>
> ------------------------------------------------------------------------
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
>>
>>
>> !DSPAM:4007,481f601c109671628642973!
> 
> 


-- 
Justin Deoliveira
The Open Planning Project
jdeolive at openplans.org