Sunburned Surveyor wrote: > Jody wrote: "For things like JODA it will be a balance between an > extra dependency (and the code already around to handle time)." > There is some time parsing code that has been pretty heavily tested in order to get us GML support. JODA was presented as an option; but at the time it was pretty new. > Do you mean the existing JDK code? Cause I didn't see any time specific code > in the packages for Geotools. > I went hunting and found XsDateTimeFormat which appears to be under the Apache license. It is in the gt-xsd-core plugin. Jody > 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
