Thanks for responding Martin. Martin wrote: "Your idea of "a small simple feature library" sounds like exactly what the idea of defining the JUMP Core API was meant to address. Does that sound right?"
I am familar with this. If I remember it correctly there was a jump-api.jar and a jump-workbench.jar. I believe the two jars have now been rolled into one in our build process. It wouldn't be hard to set up a separate little Ant script that could build the API jar. I could probably do in an hour or less. However, I'm talking about more than just a Jar file. I'm talking about actually "marketing" the library. That means packaging it separately with its own Javadoc and documentation. This wouldn't be geared to an OpenJUMP programmer, but a programmer that was interested solely in the library. Ideally this could exist as a GeoTools module. However, there may be concerns from the GeoTools community about polluting their current feature model and/or creating confusion with their current SimpleFeature code. Martin wrote: "Is there any possibility of someone rolling up their sleeves and developing an Adapter API which would map the GeoTools SF model in the JUMP Feature API? Once this was done, perhaps it would then be much easier to call GeoTools code? I realize this is probably a lot of work, and it really needs to be done with great care in design, since Adapter layers can get pretty tricky to code." I'm going to be completely honest here. I think this job will be a real chore. (At least it will be a real chore for anyone coming from the OpenJUMP world.) We are talking about 30 methods and 4 interfaces for a single feature...That seems to be way overkill to me. I've been trying to implement an AbstractSimpleFeature class for two days, and my frustration level has hit a peak. :] Having said that, there are parts of the GeoTools feature model that I would like to integrate into OpenJUMP in a non-invasive way. For example, I really like their PropertyType class and their Filter class, and the way the two classes work together. One example of possible integration is using the these two classes in an OpenJUMP plug-in to provide validation of feature attribute values. I think there are only three (3) practical ways to move forward on this issue: [1] Talk GeoTools into creating a more simple "Simple Feature" model that more closely resembles the one we use in OpenJUMP. They don't have to completely integrate it into the rest of their library, but they could have it as an optional module. This Simple Feature model would need to ditch the additional interfaces and make a clear distinction between the methods that belong to a SimpleFeature and those that belong to a FeatureSchema or FeatureType. [2] Talk GeoTools into having a module that contained the Feature class and related classes from OpenJUMP. This would allow collaborative development of this code and related code under the GeoTools umbrella, in a manner independent of the current GeoAPI/GeoTools feature model. I would champion this effort if it was acceptable. [3] Recognize that this level of cooperation with GeoTools is not possible. Package and promote a simple feature library based on existing OpenJUMP source code, and use parts of the GeoTools code when possible, without breaking OpenJUMP. This would mean competing in some manner with GeoTools as a provider of a the Java GIS community's primary simple feature library. I would rather not see this happen. Of course, I say all of the above admitting that I [1] have a limited knowledge of the GeoTools code base and [2] am not a professional Java programmer. The Sunburned Surveyor P.S. - I will still contunue my effort at participating in GeoTools programming, just not on anything that involves the feature model. :] On Tue, Jun 3, 2008 at 1:31 PM, Martin Davis <[EMAIL PROTECTED]> wrote: > Excellent question, SS. I'm not surprised to see this come up. Greater > integration with GeoTools has often been suggested as the ultimate goal > for future JUMP design, but I've always been concerned that GeoTools > imposes an undesirable level of complexity. It would be nice to find a > good path forward between the Scylla of incompatibility and the > Charybdis of code complexity... (yes, it's Obscure Classical Allusions > day today...) > > A couple of comments: > > 1. Your idea of "a small simple feature library" sounds like exactly > what the idea of defining the JUMP Core API was meant to address. Does > that sound right? (Are you familiar with this idea, or did it not make > it over to OpenJUMP?) > > 2. Is there any possibility of someone rolling up their sleeves and > developing an Adapter API which would map the GeoTools SF model in the > JUMP Feature API? Once this was done, perhaps it would then be much > easier to call GeoTools code? I realize this is probably a lot of work, > and it really needs to be done with great care in design, since Adapter > layers can get pretty tricky to code. > > I'll cc this to Jody, since he's probably best placed to comment on this > from the GT perspective. > > 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 >> >> > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > > ------------------------------------------------------------------------- > 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
