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?
A [1] http://trac.osgeo.org/proj/ 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
