Hey Martin, Did I miss the 0.3 VOTE? It's possible since I've been so behind in email but I didn't see a VOTE thread, RESULT thread, etc.
I'll reply to the point sin detail below in a bit. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Tuesday, July 30, 2013 11:00 AM To: Apache SIS <[email protected]> Subject: Replaced LatLon and LatLonRect >Hello all > >Starting SIS 0.4 work, I removed LatLon and LatLonRect as per [1] and >[2]. Those classes were deprecated in SIS 0.3 (not yet released). Those >classes are replaced by DirectPosition2D and Envelope2D, which more >closely follow ISO/OGC objects. > >The LatLonRect.getJavaRectangles() method has been ported to >Envelope2D.toRectangles() [3]. Some differences in the Envelope2D method >compared to the LatLonRect one are: > > * Returns an empty array if the envelope is empty. > * Do not shift the coordinates by +90°N and +180°E. If such shift is > desired, it will be the work of coordinate transformation services. > * The longitude axis and the 180° limit is fetched by inspection of > the associated Coordinate Reference System (CRS) object, rather than > being hard-coded. Longitude is not necessarily the first or second > axis, since it depends on the CRS definition. We may have no > longitude at all (e.g. projected coordinates). Limit may be 200 > grads instead than 180°. The wraparound axis may be something else > than longitude (e.g. time axis in climatology). > * A multi-dimensional variant (> 2D) of this method is provided in > GeneralEnvelope.toSimpleEnvelopes(). > > >The LatLon.getNormLon() method has been refactored as >GeneralDirectPosition.normalize(). The main difference is that the new >method normalizes the ordinate values in-place instead than returning >normalized longitude, because we don't know in advance which axis will >be normalized (we may have no longitude at all, etc.). > >While the above has been tested locally on my machine, it may take a few >weeks before it works as described on trunk because it requires an >implementation of GeographicCRS, which has not yet been ported to SIS. >I'm starting this port this week. > >One remaining class to refactor is LatLonPointRadius. This class >contains the following methods: > > * getCircularRegionApproximation > * getRectangularRegionApproximation > > >I guess that those methods should be moved elsewhere, in some >computational classes. However I don't know yet where to put them. One >possible candidate would be org.apache.sis.distance.DistanceUtils, but >this is not really distance computation... However it may be a temporary >position since I would like to propose modification to DistanceUtils >later too (something along the line of the "geodetic calculator" >provided in the geotk). > >Does anyone would like to share comments, though or concerns? > > Martin > > > >[1] http://issues.apache.org/jira/browse/SIS-68 >[2] http://issues.apache.org/jira/browse/SIS-69 >[3] >http://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/geometry >/Envelope2D.html#toRectangles%28%29 >
