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
