On 7/3/2013 8:47 AM, Tom Whittaker wrote:
Hi John...
Thank you -- it is looking a whole lot better! You are right, though,
about row 6614. The original (file) values of lon and lat (columns
370:375) are:
{-159.2804, -161.53036, -167.258, 156.55109, 47.010693, 35.255604}
{-89.68158, -89.77692, -89.87283, -89.961716, -89.91907, -89.82005}
So the point in question is very near the pole, and the main problem I
see with the new algorithm is that the newly assigned value of
-203.4489 fall outside of the specified "valid_range"....so
technically it should be "invalid", right?
what we are doing is converting from lat/lon with valid range +- 180 tocoordinate values which "removes the seam" from the coordinates (by adding +- 360) , so that the drawing routines dont have to worry about the coordinates jumping. so the valid_range of the original coords doesnt matter here.
in fact the problem is that the longitude on row 6614 jumps 110 degrees, when i had a max jump of 100 degrees. i have adjusted the algorithm again, now that row has (just the last 40 values):
-156.464600, -156.831787, -157.338333, -158.082108, -159.280396, -161.530365, -167.257996, -203.448914, -312.989307, -324.744396, -328.141495, -329.743172, -330.673994, -331.282251, -331.710836, -332.029137, -332.274900, -332.470413, -332.629690, -332.761972, -332.873610, -332.969107, -333.051744, -333.123976, -333.187664, -333.244253, -333.294884, -333.340460, -333.381716, -333.419249, -333.453552, -333.485035, -333.514042, -333.540865, -333.565750, -333.588909, -333.610525, -333.630756, -333.649740, -333.667601, -333.684439, -333.700354, -333.715427,
this looks much better in toolsui (see attached screen dump). we will get a new ncIdv out next week and see how it looks in the idv, and you can let me know what you think.
And when the IDV software tries to define the domain of the data, the "minimum" longitude will end up being -203. I'm not sure of the ramifications of this, but would you consider testing the computed value and if it is outside the specified "valid_range" then either discard the computed value or make the value "missing"? You know I appreciate your time & energy (and patience) on this one. I think it's very important to get these guys at NASA Langley on-board. tom On Tue, Jul 2, 2013 at 4:58 PM, John Caron <address@hidden> wrote:Hi Tom: my new algorithm now does this with the troubling rows:.....this last one may be a problem -167.257996, -203.448914, 47.010693 ?? anyway, the whole point is to deal with the longitude seam, to prevent the grid points from apparently overlapping due to the modulo 360 thing. this particular case is pushing the limits of that logic. Im not really sure if this grid conforms to the CDM requirement for coordinates. ill have to write some test code to analyze it. this fix will be in 4.3.18 by next week. John-- Tom Whittaker University of Wisconsin-Madison Space Science & Engineering Center (SSEC) Cooperative Institute for Meteorological Satellite Studies (CIMSS) 1225 W. Dayton Street Madison, WI 53706 USA ph: +1 608 262 2759
Attachment:
coord2Djump.png
Description: PNG image
