I want to ask a question about a "strategic" move for OpenJUMP. I thought it best to ask here, before I mention the subject on the java-collaboration mailing list that was just set up at the OSGeo.
Let me give you some background info, and then I will aske my question. A couple of weeks ago I decided that I would try to participate in some programming at GeoTools. My goals with this endeavor were to [1] become more acquainted with the GeoTools programming process and [2] determine what type of collaboration would be possible. I decided to do some work on adding support for GPX files in GeoTools. There was some existing code, but I wanted to allow low-level access to GPX files and also provide simple feature objects from GPX files. I was cruising along fine until it came time to implement to the SimpleFeature interface in GeoTools. This interface is actually from the GeoAPI project but is used by GeoTools. The SimpleFeature interface extends four (4) other GeoAPI interfaces and a total of 30 different methods. In contrast, the JUMP Feature interface defines only 17 methods and extends no other classes or interfaces. After digging into the GeoTools SimpleFeature code for a while, I have realized that they don't really have a "pure" simple feature implementation. Instead they've tried to force fit their complex feature model into a simple feature interface. This is very akward for me. For example, the implementer of SimpleFeature must implement several methods that really seem to belong to SimpleFeatureType, which is similar to JUMP's FeatureSchema. Here is my question: Is it worth trying to address the complexity in the GeoTools SimpleFeature interface and related code, or should I focus my energy on extracting and maintaining a very lightweight library with the simple feature code from JUMP? (This would be a small JAR containing the Feature interface, FeatuerSchema, interface, AbstractFeature class and maybe a couple of other related classes.) This may seem like an unimportant question, but I think it is more important over the long term. Let me briefly explain why: GeoTools has been set up as the "flagship" of open source Java GIS collaboration. I believe it will be the project most people go to when looking for a simple feature implementation to use in their own projects. This isn't a bad thing if GeoTools is willing to address issues of complexity or is willing to include a module with a "pure" simple feature implementation that would be more compatible with OpenJUMP. This would allow us to become a participant in GeoTools development and tap into the outside interest for a simple feature implementation. If this is not possible, I really think it would be prudent of us to maintain a small library that could be used by other parties outside of OpenJUMP for projects that require a simple feature implementation. This would be set up as an alternative to the simple feature implementation in GeoTools. This would be of interest to organizations that need simple features, but that don't need all of OpenJUMP and don't want to deal with the complexity of GeoTools. We could then tap into improvements or utilities that they contribute to JUMP's simple feature model. Do you guys have any thoughts on this? I was really hoping the SimpleFeature code in GeoTools would be workable, but I'm on my third or fourth day of trying to create an abstract class that implements SimpleFeature and its related interfaces. I'f like to hear what programmers from our OpenJUMP community have to say about this before I mention it in a larger, more public, discussion. The Sunburned Surveyor P.S. - I know that I can be an annoying distraction to this community and others, but I will note that at least two (2) of the messages that I sent to the GeoAPI mailing list with questions about the SimpleFeature interface and related code remain unanswered. Jody has been great about explaining things from the GeoTools side, but I wonder if the GeoAPI folks are that interested in explaining design logic and working with our community... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
