Hey Martin, On 12/20/12 2:21 AM, "Martin Desruisseaux" <[email protected]> wrote:
>Hello Chris > >Le 19/12/12 07:40, Mattmann, Chris A (388J) a écrit : >> +1, I filed a JIRA for this, and will try and get to it by the end of >>the >> week: >> >> https://issues.apache.org/jira/browse/SIS-68 > >Thanks, I just posted a comment on it. Basically I propose to separate >"coordinate representation" from "coordinate transformation" tasks. I >think that the getShiftedLat() and getShiftedLon() method belong to the >later category, which I think could be managed from outside of >DirectPosition. Yep, I commented back -- I agree with your position. Let's not port those coordinate transform methods. > >> Replace them and integrate what you're doing (which is actively >> maintained, and supported) into the Quad Tree :) > >Alternatively, they could also be moved for now as package-privated >classes in the QuadTree package. The key point is to avoid duplication >at least in the API, but the implementation under the hood can have more >flexibility. I think it is ok if QuadTree uses internally its own object >specially tuned for its need. I'm a fan of keeping code around that's actively maintained, or just too useful to get rid of. QuadTree falls into the "I think this is too useful to get rid of", but its supporting classes don't. You are taking upon the great/huge effort to get us into a full spatial library and supporting classes -- I'd rather take advantage of the helper classes that you are defining there then. It has the dual benefit of potentially getting you (and others) interested in the QuadTree and then everyone benefits. Yay. :) Cheers, Chris > > Martin >
