Hi Chris & Adam, Thank you for your replies. I agree it's definitely very beneficial to be able to accept many different CRSs. Proj4J looks interesting. According to the website, the Java version doesn't yet have all of the features of the C/Unix version, but even so it looks like it has a lot of useful features for performing conversions.
I guess the big question I had was - should we retain the raw values supplied to the LatLon constructor, or should we try to convert these into a consistent internal representation? At the moment, the raw values supplied as arguments to the LatLon constructor are retained as the latitude and longitude attributes for the LatLon object. Instead, for example, the LatLon constructor could try to evaluate the latitude and longitude arguments and convert them (e.g. using Proj4J) into a chosen format - e.g. try to convert arguments from any CRS to latitude in the range -90 to 90 and longitude in the range -180 to 180. The reason I ask is because it looks like several methods in sis-core classes assume that latitude is in the range -90 to 90 and longitude is in the range -180 to 180. For example, the getShiftedLat() and getShiftedLon() methods in the LatLon class, the getPointOnGreatCircle() and getHaversineDistance() methods in DistanceUtils and getRectangularRegionApproximation() in LatLonPointRadius. Apologies again if I've misunderstood how these methods work! Ross On 5 July 2012 14:46, Mattmann, Chris A (388J) <[email protected]> wrote: > Hey Adam, > > On Jul 4, 2012, at 3:44 PM, Adam Estrada wrote: > >> Hi Ross, >> >> We need to keep in mind that there are lots and lots of crs's that are not >> represented in decimal degrees. Therefore, it would be beneficial to accept >> any values. Proj4[1] is a projection library that transforms geographic >> coordinates (latt/long) in to cartesian coordinates and visa versa. We >> should look at using that. Its MIT licensed too which I believe is cool. >> Mattmann, what say you? > > +1, I think we should definitely look at Proj4J. > > Scope out my other email too. > > Cheers, > Chris > >> >> >> >> On Jul 4, 2012, at 6:06 PM, Ross Laidlaw wrote: >> >>> Hi everyone, >>> >>> I've been looking into developing some unit tests for the core classes >>> in sis-core. While developing the unit tests, I noticed that the >>> LatLon constructor can accept any valid double values for its latitude >>> and longitude arguments. Is this ok or should there be some >>> constraints, checks or conversions performed on the arguments to the >>> constructor? >>> >>> In the LatLon class there's a 'getNormLon()' method that returns the >>> longitude attribute normalized to a value between -180.0 and 180.0. >>> This implies that it's ok for the constructor to accept longitude >>> arguments outside this range and for the longitude attribute to have a >>> value outside this range. >>> >>> On the other hand, it looks like the getShiftedLat() and >>> getShiftedLon() methods assume that the latitude and longitude >>> attributes for a LatLon object should be within the standard ranges >>> (i.e. between -90.0 and 90.0 for latitude and -180.0 to 180.0 for >>> longitude). >>> >>> So I was thinking - perhaps we could accept any values for the >>> constructor arguments, but then normalize them in the constructor so >>> that the attributes are stored as normalized values. Alternatively, >>> we could update the getShiftedLat() and getShiftedLon() methods to >>> check/normalize the attributes before shifting them. >>> >>> Any thoughts? Apologies if I've completely misunderstood any of these >>> methods! >>> >>> Ross >> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
