Re: [OSGeo-Discuss] Research For Shared Java CRS Library
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
Re: [OSGeo-Discuss] Research For Shared Java CRS Library
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
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 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
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
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
