Thanks Martin, I went ahead and applied your patch in:
On 12/20/12 10:57 PM, "Mattmann, Chris A (388J)" <[email protected]> wrote: >Hey Martin, > >From: Martin Desruisseaux ><[email protected]<mailto:[email protected]>> >Organization: Geomatys >Reply-To: "[email protected]<mailto:[email protected]>" ><[email protected]<mailto:[email protected]>> >Date: Thursday, December 20, 2012 6:48 PM >To: "[email protected]<mailto:[email protected]>" ><[email protected]<mailto:[email protected]>> >Subject: Re: Class overlap: Envelope (or GeographicBoundingBox) vs >LatLonRect > >Hello Chris > >Le 21/12/12 03:29, Mattmann, Chris A (388J) a écrit : > >Yep, I commented back -- I agree with your position. Let's not port those >coordinate transform methods. > >Thanks. I will port the functionality of getNormLon(). I suggest a >"normalize()" method which normalize the coordinate as a whole (longitude >may not be the only cyclic coordinate). > >+1 makes sense to me. > >On a related question about QuadTree, I wonder if the QuadTreeNode class >could be considered as internal mechanic? QuadTreeNode is used publicly >only be QuadTree.getRoot(), itself used only internally be >QuadTreeReader/QuadTreeWriter. Unless they are actually used by other >projects outside SIS, could we turn the following into package-private >elements? > > > * Method QuadTree.getRoot() > * Class QuadTreeNode > > * Class Quadrant > >+1 from me that makes sense. > >The proposed patch is attached to this email. > >I'll file a JIRA and commit it shortly! > >Cheers, >Chris >
