I suppose this is a little over due. Jody Garnett and Andrea Aime from GeoTools and Paul Austin and I from the JPP have been talking some and coding a little to solve a challenge we see in the open source Java GIS community. The basic problem is that we find it difficult to share input/output or reader/writer code for common spatial formats among open source Java GIS projects.
One of the main reasons for this challenge is that we lack a common feature model, or way to represent features in Java. It seems like our peers in the C/C++ world don't have this problem, at least not with I/O code, as there are common libraries that provide this functionality. The four of us wanted to see if we could come up with a common feature representation that was simple enough to use easily but flexible enough to support the requirements of the different projects. (For example, some projects allow for features to contain multiple geometry attributes, and some don't. Some require each attribute to have a unique name, some don't. Some projects allow complex attrubutes, or attributes that contain attributes, some don't.) The idea is to have projects eventually work towards implementing I/O code that uses this common feature at its lowest level. For example: Instead of writing a DXF parser that provides OpenJUMP Feature objects, I write a DXF parser that produces DataObjects instead. I then convert these data objects to OpenJUMP feature objects in a layer of functionality that sits "above" the actual parser. This allows other projects to do the same thing, and they get to benefit from my DXF parser with very little effort. We realize this won't happen immediately, or even over the short term. There is a lot of legacy code out there, and it isn't practical to rip the I/O guts out our all our programs. However, it would be possible to work towards this goal over the course of the next few years, by integrating this common feature framework into our programs when the code needs to change for some other reason anyways. We decided to call this common feature a DataObject. A DataObject is simply a collection of attributes representing a feature. The DataObject is very generic, and can represent a spatial or non-spatial feature. We are starting to implement at least one spatial data reader/writer at OpenJUMP that will use DataObjects. I thought this would be a good opportunity to introduce the concept and code to some of the other members of our community. I'm asking that the other projects keep an open mind about this. Please consider if your project coudl use DataObjects at a low level in your I/O code at some point in the future. If you think this is possible please become involved in the development of the code for the DataObject framework. If we can think long-term and get over some of our differences I think this is a great opportunity to share our work and strengthen the overall position of the open source Java community in the GIS arena. Please let me know if you have any questions, comments, or concerns. The source code for the DataObject framework is currenlty being hosted at the SurveyOS SourceForge repository: http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/collaboration/net/surveyos/sourceforge/collaboration/dataObject/ If you want to participate in the development of the DataObject code and have a SourceForge account I can grant you write access to the repository. The Sunburned Surveyor http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/collaboration/net/surveyos/sourceforge/collaboration/dataObject/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
