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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/discuss > > > !DSPAM:4007,481f601c109671628642973! -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] _______________________________________________ Discuss mailing list [email protected] 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 [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
