Hi Landon, I more or less agree with Jody, I think these things are handled best on a case by case basis. Some comments inline.
Sunburned Surveyor wrote: > - Code in my module that is used to validate latitude/longitude > values. This could be moved to a utility package so it could be used > by other client code also working with latitude/longitude values. > > - I could replace the use of doubles in my code to represent > latititude/longitude values with one of the coordinate classes from > GeoTools/GeoAPI. > > - I'm accessing data from an XML file. I'd like to rip the use of JDOM > out of my module and replace it with Sun's StAX (XML Pull Parsing) > implementation. Is there a way to decide on a common library used for > XML pull-parsing? This would increase consistency among modules and > would allow us to share utility code written to make use of the > library easier. One thing I have been wanting to do with the xml-xsd module is port the streaming part of it to a pull parser, but have yet to do so. So agreeing on a common pull parser would be good. There is already a pull parser in use in the wfs data store module. I believe it uses stax as well. > > - I'm using classes from Joda to deal with the temporal aspects of GPX > entities. Could we make this a common library used to represent > temporal objects in Geotools? > > - I'd like to write an object that represents GPX files and presents > an API for obtaining information about these files and their contents. > Is there an existing API in Geotools that I can use to do this? Are you talking about a single object to represent an entire file? Or an entire object model to represent the gpx format/protocol. > > I may have asked some of these questions already. Please be patient > with me if I am overlooking something obvious. I am making this effort > so my future work on the GPX2 module fits well with the rest of the > Geotools ecology. > No problem. I think it is great that you are willing to take the time to collaborate and "do things right", instead of just going off and coding like mad in isolation :) -Justin > Thanks for the continued assistance. > > Landon > > P.S. - I'm trying to stay as far away from the Geotools/GeoAPI feature > model as I can. This means that most of my modules (and opportunities > for collaboration) will be with lower level code. :] > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
