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

• Subject: Re: Fwd: Re: [netCDFJava #XIR-445342]: Problem with netCDF-Java CoordinateAxis returning wrong values
• Date: Wed, 03 Jul 2013 14:30:45 -0600

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