You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Ross Laidlaw <rl...@gmail.com> on 2012/07/05 00:06:07 UTC
LatLon constructor and normalized latitude and longitude attributes
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
Re: LatLon constructor and normalized latitude and longitude
attributes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Ross,
On Jul 8, 2012, at 6:39 PM, Ross Laidlaw wrote:
> 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.
+1.
>
> 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?
[...snip...]
I think if that internal consistent representation is a coordinate reference
system (CRS) by default then that makes a ton of sense to me.
Cheers,
Chris
> 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!
Nope you are spot on. We shouldn't assume e.g., WGS84, without explicitly
declaring it and then having the ability to swap it out after that. Do you
have any good ideas of how to organize this? I'm all ears...
Cheers,
Chris
>
>
>
>
>
> On 5 July 2012 14:46, Mattmann, Chris A (388J)
> <ch...@jpl.nasa.gov> 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: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: LatLon constructor and normalized latitude and longitude attributes
Posted by Ross Laidlaw <rl...@gmail.com>.
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)
<ch...@jpl.nasa.gov> 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: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
Re: LatLon constructor and normalized latitude and longitude
attributes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: LatLon constructor and normalized latitude and longitude attributes
Posted by Adam Estrada <es...@gmail.com>.
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
Re: LatLon constructor and normalized latitude and longitude
attributes
Posted by "Ramirez, Paul M (388J)" <pa...@jpl.nasa.gov>.
Hey Guys,
http://trac.osgeo.org/proj4j/
The Java implementation of proj4 licensed as ALv2 but not sure its
completed.
Thanks,
Paul
On 7/11/12 8:10 AM, "Mattmann, Chris A (388J)"
<ch...@jpl.nasa.gov> wrote:
>Hey Ross,
>
>On Jul 8, 2012, at 7:08 PM, Ross Laidlaw wrote:
>
>> Apologies, I just re-read Chris' original reply and realised that
>> Chris already addressed many of the questions I just asked!
>
>Thanks, appreciate it.
>
>>
>> Sounds like a good idea to have different normalization methods that
>> can be associated with different CRSs. Proj4J has some useful stuff,
>> but we could certainly develop our own CRS conversions in SIS instead.
>> As you guys have discussed previously these could become a major
>> component/benefit of SIS. Either way we definitely need the
>> capability to convert coordinates.
>
>+1, I think if we had a CRS tied to a Lat/Lon representation then we could
>easily convert between the 2. As Adam mentioned, if Proj4J is MIT
>licensed,
>there's no reason that we can't leverage it in SIS per this page:
>
>http://www.apache.org/legal/resolved.html#category-a
>
>Cheers,
>Chris
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Chris Mattmann, Ph.D.
>Senior Computer Scientist
>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>Office: 171-266B, Mailstop: 171-246
>Email: chris.a.mattmann@nasa.gov
>WWW: http://sunset.usc.edu/~mattmann/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Adjunct Assistant Professor, Computer Science Department
>University of Southern California, Los Angeles, CA 90089 USA
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
Re: LatLon constructor and normalized latitude and longitude
attributes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Ross,
On Jul 8, 2012, at 7:08 PM, Ross Laidlaw wrote:
> Apologies, I just re-read Chris' original reply and realised that
> Chris already addressed many of the questions I just asked!
Thanks, appreciate it.
>
> Sounds like a good idea to have different normalization methods that
> can be associated with different CRSs. Proj4J has some useful stuff,
> but we could certainly develop our own CRS conversions in SIS instead.
> As you guys have discussed previously these could become a major
> component/benefit of SIS. Either way we definitely need the
> capability to convert coordinates.
+1, I think if we had a CRS tied to a Lat/Lon representation then we could
easily convert between the 2. As Adam mentioned, if Proj4J is MIT licensed,
there's no reason that we can't leverage it in SIS per this page:
http://www.apache.org/legal/resolved.html#category-a
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: LatLon constructor and normalized latitude and longitude attributes
Posted by Ross Laidlaw <rl...@gmail.com>.
Apologies, I just re-read Chris' original reply and realised that
Chris already addressed many of the questions I just asked!
Sounds like a good idea to have different normalization methods that
can be associated with different CRSs. Proj4J has some useful stuff,
but we could certainly develop our own CRS conversions in SIS instead.
As you guys have discussed previously these could become a major
component/benefit of SIS. Either way we definitely need the
capability to convert coordinates.
On 5 July 2012 14:45, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> I think we should accept any values, and give the user the option to
> decide if they want to normalize them. But maybe we should associate
> the normalization methods with particular coordinate reference systems,
> and furthermore, maybe we should just make CRSs official first class
> citizens in future versions of SIS. Thoughts?
>
> Looking at Proj4J will probably help spark some ideas so I'd be curious
> to know your opinions of that.
Re: LatLon constructor and normalized latitude and longitude
attributes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Ross,
On Jul 4, 2012, at 3: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?
I think it's OK IMHO, mainly due to Adam's point about Coordinate Reference
Systems (CRSs).
>
> 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.
Yep it has to do with things like whether or not someone picked e.g.,
a 360 Lat Lon grid, or a 180 Lat Lon grid, or something else.
>
> 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.
I think we should accept any values, and give the user the option to
decide if they want to normalize them. But maybe we should associate
the normalization methods with particular coordinate reference systems,
and furthermore, maybe we should just make CRSs official first class
citizens in future versions of SIS. Thoughts?
Looking at Proj4J will probably help spark some ideas so I'd be curious
to know your opinions of that.
>
> Any thoughts? Apologies if I've completely misunderstood any of these methods!
See above and you are doing great!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++