[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Re: [netCDFJava #XIR-445342]: Problem with netCDF-Java CoordinateAxis returning wrong values



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 to
coordinate 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

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.