NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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/
netcdf-java
archives: