FWIW, ncWMS implements a Longitude class that implements an isBetween()
method:
http://www.resc.rdg.ac.uk/trac/ncWMS/browser/trunk/src/java/uk/ac/rdg/re
sc/ncwms/coords/Longitude.java
This works by taking the start point and calculating the "clockwise
distance" to the end point: this distance is always positive, so the
clockwise distance from 0 to -5 degrees is 355 degrees. Then it
calculates the clockwise distance to the point of interest. The point
of interest is between the start and end points if the clockwise
distance from the start point to the POI is less than the distance from
the start to the end.
This mechanism is insensitive to the conventions used for the longitude
range (i.e. [-180:180] or [0:360]).
So: 180 is between 0 and -5. But 50 is not between 100 and -180.
Don't know if this is helpful!
Jon
From: netcdf-java-bounces@xxxxxxxxxxxxxxxx
[mailto:netcdf-java-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Christian D
Ward-Garrison
Sent: 14 July 2010 15:02
To: netcdf-java@xxxxxxxxxxxxxxxx
Subject: Re: [netcdf-java]
BUG:ucar.unidata.geoloc.LatLonPointImpl.betweenLon()
So, I realized what the problem with LatLonPointImpl.betweenLon() (a
problem that my proposed replacement shares): there's not enough
information to determine which way (east or west) the longitude range
extends. For example, how should
LatLonPointImpl.betweenLon(10, 20, 0);
be interpreted? Does that lon range extend from 20 west to 0 (20
degrees) or from 20 east to 0 (340 degrees)?
As a result, I've eschewed betweenLon altogether and started using
LatLonRect instead:
new LatLonRect(new LatLonPointImpl(0, 20), 0, 340).contains(0, 10); //
false
new LatLonRect(new LatLonPointImpl(0, 20), 0, -20).contains(0, 10); //
true
I think that betweenLon() should be made deprecated, since it'll give
unexpected results for arguments such as:
LatLonPointImpl.betweenLon(45, 0, 360);
which is a Bad Thing, given how common [0, 360] is as a longitude range.
Regards,
Christian Ward-Garrison
-----netcdf-java-bounces@xxxxxxxxxxxxxxxx wrote: -----
To: netcdf-java@xxxxxxxxxxxxxxxx
From: Christian D Ward-Garrison <cwardgar@xxxxxxxx>
Sent by: netcdf-java-bounces@xxxxxxxxxxxxxxxx
Date: 07/13/2010 05:46AM
Subject: [netcdf-java] BUG:
ucar.unidata.geoloc.LatLonPointImpl.betweenLon()
LatLonPointImpl.betweenLon(68, 52, 340) // Returns false but should be
true.
The method fails because it normalizes lonEnd to -20, which is less than
68. I propose this fix:
static public boolean betweenLon(double lon, double lonBeg, double
lonEnd) {
double lonNormal = lonNormal(lon, (lonBeg + lonEnd) / 2);
// Don't assume that lonBeg <= lonEnd.
return Math.min(lonBeg, lonEnd) <= lonNormal && lonNormal <=
Math.max(lonBeg, lonEnd);
}
Regards,
Christian Ward-Garrison
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
