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, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org ------------------------------------------------------------------------- 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
