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.
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.
Bill Hibbard wrote:
But one useful piece of information is "(516,0)". Note that 516 is about half of LengthX = 1033, so the offending grid box is at the haflway point along X. In fact, the offending grid box from X=516 to X=517 exactly straddles 1033/2. If X is your azimuth coordinate, is there an error in computing angles halfway around the circle? One possibility is that angles increase from X=0 to X=516, then there is a decrease from X=516 to X=517, then they increase again. Something like that. Or if X is your radius coordinate, is there a similar error in computing radius halfway out, at X=516?
Hi Bill,Yes, in my original terrain file, the domain is a LinearLatLon set with X -> Lon, and Y -> Lat. If you put the radar at the center of that domain, and my X (Lon) increases for X = 0->1033, then my azimuth will decrease to 0 (at the midpoint of X [516]) and then increase.
Perhaps Don's suggestion of using a CachingCoordinateSystem to wrap my Radar2DCS is the best way to go, as opposed to changing my data?
Thanks for the help! -kevin. -- +------------------------------------------------------------+ Kevin L. Manross [KD5MYD] <>< (405)-366-0557 CIMMS Research Associate kevin.manross@xxxxxxxx [NSSL-WRDD/SWATN] http://www.cimms.ou.edu/~kmanross "My opinions are my own and not representative of CIMMS, NSSL, NOAA or any affiliates" +------------------------------------------------------------+
visad archives: