Jody wrote: "For things like JODA it will be a balance between an extra dependency (and the code already around to handle time)."
Do you mean the existing JDK code? Cause I didn't see any time specific code in the packages for Geotools. Jody wrote: "I suspect code to validate coordinates already exists." I should have been specific. My code ensures that double values representing latitude values in decimal degrees are between 0.0 and 90.0. It also ensures that double values representing longitude values in decimal degrees are between 0.0 and 180.0 degrees. I can't remember how the code deals with hemispheres (north/south and east/west). Some of this will depend on how the values are handled in the GPX format. Landon On Thu, Mar 5, 2009 at 1:19 PM, Jody Garnett <[email protected]> wrote: > Just a quick round of feed back; a lot of these would be handled on a case > by case basis as you or others identify an area where collaboration is > possible. As an example if you are focused on a low level data access API > you may need to lead by example to show what you are talking about. For > things like JODA it will be a balance between an extra dependency (and the > code already around to handle time). I suspect code to validate coordinates > already exists; you may be able to ask on the devel list and evaulate what > is already present (often the best collaboration comes from combing two sets > of code; and keeping all the test cases). > Jody > > On Fri, Mar 6, 2009 at 8:11 AM, Sunburned Surveyor > <[email protected]> wrote: >> >> I've been thinking a bit about how I will move forward with the >> development of my GPX2 module. I've basically met my own needs with >> the code, but there are some nifty features I would like to add for >> others in the community. >> >> Before I come up with a road plan for this additional work on the >> module, I wanted to ask about how collaboration among modules takes >> place. I suppose this question falls in with my vision of Geotools >> being structured as a core library with loosely knit additional >> modules. What would be the point of pooling code in this way if you >> can't share common interfaces and objects? >> >> What is the best way to determine opportunities to share code between >> my modules and the rest of Geotools. Is there a formal process for >> this? Or do I just post a list of potential opportunities for >> collaboration to the mailing list? >> >> Here are some opportunities for collaboration I think exist with my >> current version of the GPX2 module, or with future work I would like >> to do on the module: >> >> - 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. >> >> - 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? >> >> 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. >> >> 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 > > ------------------------------------------------------------------------------ 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
