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: [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.
------------------------------------------------------------------------
_______________________________________________
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
