Thanks for the email Frank - your comments are spot on. It often seems are run out of time and push something bad out the door - and then spend years sorting out what is right. I kind of wish we would do more gradual changes and set ourselves up to improve over time. It often seems we struggle until we cannot take it anymore, and the people that cannot take it anymore end up forking in order to do something that should be "easy".
There are lots of examples - but this shapefile one is a good start. Open Jump uses some shapefile code, that was forked off JUMP which was forked off an early cut in GeoTools. It would of been more fun if improvements (stability is an improvement) were fed back in. Landon thanks for bringing this conversation to the GeoTools-devel list; I will do my best to answer your questions. And if you have any suggestions on how we can work together better please let me know. If difference in FeatureModel is a trouble for you please let me know; I would like to set things up so you can supply a factory to the shapefile code to produce instances that are exactly to your liking. Cheers, Jody Frank Warmerdam wrote: > Sunburned Surveyor wrote: > >> David (and other OpenJUMP developers), >> >> I should add that the GeoTools folks did quickly respond to my inquiry >> on their mailing list about the Shapefile code. One of their developers >> mentioned that their are no current plans to Feature interface. They >> also seem to be open to the idea of accepting documentation I prepare on >> the use of the Shapefile code. >> >> Perhaps the wise thing would be to develop and use the converter. This >> would allow us to see what changes happen to the GeoToolsfeature model >> API over the course of the next few months and would give us a chance to >> see how OpenJUMPers and the GeoTools folks work together. >> >> I'll wait on some input from the GeoTools developers, if they're >> interested in the conversation. :] >> > > Landon, > > I feel a bit out of place participating in this thread, since I am neither > an OpenJUMP developer, nor a GeoTools developer nor really a user of either. > > However, from the C/C++ open source geospatial community I have frequently > been amazed (in a negative way) at the failure of the OSGIS Java community > to gel around common libraries. > > In the C/C++ world, components like GDAL/OGR, PROJ and GEOS are very widely > used in packages including GRASS, MapServer, MapGuide, OSSIM, OpenEV, and > Thuban. It seems to be accepted that re-inventing file format io, or > projections for each package is silly and a drain of resources from the > specific things that set these applications apart. > > And yet, from my limited view, it seems that code sharing in the OS Java > world is not as ubiquitous. GeoServer and uDig are the obvious major > applications built on GeoTools. But major Java packages such as OpenJUMP, > deegree and gvSig seem to make only modest or no use of GeoTools - essentially > re-inventing all sorts of stuff from scratch. > > Over the years I have kept a bit of an eye on GeoTools and the Java community > at large. I have been both amazed (in a positive way!) and also dismayed at > the enthusiasm for refactoring found in the GeoTools community. I think David > Zwiers is right to raise stability as a concern with regard to GeoTools. The > cardinal rule of GDAL/OGR is "I may get the interface wrong the first time, > but at least I don't change it!". Quite the opposite for GeoTools who seem > keen to revisit core interface design every major rev in the interest of > getting a cleaner or more general design. > > But I think OpenJUMP and other teams interested in GeoTools can absolutely > have a positive effect on the GeoTools team in this regard. I think it is > important that you and others get involved and stress the importance of > stability rather than just giving up and duplicating things. I was keen on > GeoTools being an OSGeo project because I think the Java community needs a > strong library or set of libraries to build on. GeoTools seems the clear and > obvious choice for this role. Now what can we do to help it live up to that > role? > > While I think there would be some benefits to actually changing out the > OpenJUMP feature model for the one in GeoTools, I can understand why that > would be a high risk step. In the meantime I'd like to strongly encourage > you build some sort of adapter so that any geotools feature source can be > used as an OpenJUMP feature source, even if there is a bit of extra > conversion between feature models always going on. And then stop work on > any data access code of your own, and throw in with GeoTools for this > functionality! Get involved, help out, etc. Just using parts of the low > level shapefile code on the other hand is essentially next to no cooperation > at all. > > I don't know what OpenJUMP uses for coordinate system transformations, but > I will stress that GeoTools is quite sophisticated in this realm and this > would be another obvious aspect to take advantage of. > > You mentioned the difference in GUI toolkits between OpenJUMP and > GeoTools (uDig?). I don't think you should focus on sharing GUI > components at this time. This is another whole ball of wax, and I'd > claim that the C/C++ world has shown that a huge amount of sharing > and leverage can be accomplished without sharing GUI components. > > Anyways, this email is really my plea to OpenJUMP and indirectly to other > projects in the FOSS4G community to treat GeoTools as a building block, > to get involved and to provide strong feedback on the importance for > stability if that is important to you. > > The Java world has a quite reasonable desire for "pure java" solutions, > but make that work I think it is important to share labour on a lot of > common low level components. > > Best regards, > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
