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
