Landon, Is there a need to implement your own subclass of SimpleFeature or would using the DefaultFeature implementation work. I'm guessing there is a need as you want something which is both a JUMP Feature and a GeoTools feature.
I'm still working away at my DataObject framework. The DataObject interfaceI'm happy with and most of the DataObjectMetaData, except the stuff to deal with inheritance (which most models won't use) and default values. There is also some extra work for extended properties on attribution and on the meta data. This will allow people to add extended metadata without subclassing. Have a look and see if this will work for what you are trying to do. http://rsiaf.googlecode.com/svn/rs-gis-core/trunk/src/main/java/com/revolsys/gis/data/model/ There is an adapter for Jump Features as well. http://rsiaf.googlecode.com/svn/rs-jump-core/trunk/src/main/java/com/revolsys/jump/model/ Once I'm happy with it, I'd consider donating it to a non com.revolsys OS project for further maintenance Paul Sunburned Surveyor wrote: > 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 > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
