It looks like I've opened a can of worms. I was hoping to get input and collect my thoughts before involving Jody, although Martin didn't know this. I'm afraid the thoughts in my previous e-mail might appear unfriendly from a GeoTools perspective.
I want to establish a couple of items that I acknowledge, and then I will try to address some of the coments in the other posts to this thread: [1] I recognize that the GeoTools simple feature code is working, and that it (no doubt) meshes well with the code in GeoTools that allows a client to work with complex features. [2] I recognize that the individual paying for the code get's to determine what that code looks like. I haven't paid for anything and I likely never will, given that this is only a hobby of mine. :] [3] It is obvious that the design of the code in GeoTools was well thought-out. Paul wrote: "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 think this question get's to the heart of the issue for me. The answer to Paul's question is "no". I don't really need a custom implementation of the SimpleFeature interface. I could get by with an existing implementation suitable for extension if it existed. I only tried to implement SimpleFeature as a way to learn about the GeoTools simple feature model. I wanted to see how it worked on the inside, and how far away it was from the OpenJUMP feature model. The important argument is that someone else MAY want to implement the SimpleFeature interface, and from my perspective this is very hard to do. Forget the rest of GeoTools for a minute, and pretend all you want is a simple feature. Something that has a collection of named attributes and a single geometry. Would you implement the SimpleFeatue interface in GeoTools as part of your solution? I don't think it is practical from this perspective. The SimpleFeature interface plays well with the rest of GeoTools, but is totally overkill for someone that doesn't need all that other functionality at the end of the day. I think there is a large pool of potential "foss Java GIS" users that will be looking for a SimpleFeature model that is easy to use and easy to learn. The SimpleFeature code in GeoTools may provide a functioning black box, but I think the learning curve is too steep. This complexity can be a kiss of death for a FOSS project. If this complexity can't be addressed in GeoTools I think we should extract the simple feature code from OpenJUMP and make it available to others in a format that is easy to consume. I'm likely starting to ramble. It's been a killer day at work and I'm not sure I have my mind wrapped all around this issue. I forget that I'm only a very small fish in a really big ocean, and that my voice isn't that important. If the simple feature code in GeoTools is working for others this is great news! In this case I need to just take a chill pill and learn how to be a real programmer. If the GeoTools simple feature code is going to be too complex for 90% of the people out their looking for an open source simple feature library we should do something about it. We might be able to do this "something" inside of GeoTools, with a new module or by modifying an existing module, but if we can't, then we should do something outside of it. Is the GeoTools simple feature model working for everyone? Maybe that is the real question I need to ask. If it is I should just stop whining and deal with the complexity. SS P.S. - My original plan was to provide Paul's DataObjects representing GPX entities, but I thought I could take a crack at SimpleFeature objects. I'll now fall back on this plan, as a DataObject will likely be a good transaction medium between feature models. On Tue, Jun 3, 2008 at 3:56 PM, Edgar Soldin <[EMAIL PROTECTED]> wrote: > what about adopting "compatible" features like the geometries and > methods for now... and leave the rest for later? ... > I'd vote for using (and profit) much+ more (from) geotools code before > there's really a need to adopt their styles .. > > just a quick thought..ede > -- > >> 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 >> > > > -- > public class WhoDidIt{ // A comment. I love comments > private static Person sender; > > public static void main (String[] foo){ > > sender = new Person(); > sender.setName(new String[]{"Edgar", "Soldin"}); > > Address address = new Address(); > address.setStreet("Stadtweg 119"); > address.setZip(39116); > address.setCity("Magdeburg"); > address.setCountry("Germany"); > > sender.setAddress(address); > > sender.setMobilePhone(" +49(0)171-2782880 "); > sender.setWebSiteUrl(" http://www.soldin.de "); > sender.setEmail(" [EMAIL PROTECTED] "); > sender.setPGPPublicKey(" http://www.soldin.de/edgar_soldin.asc "); > sender.setGender(true); > > System.out.println(sender.toString()); > } > } > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
