[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

Hi Tom:

The original data is available if the app wants it from NetcdfFile. Opening as NetcdfDataset means "enhance the dataset". GridDatset assumes its enhanced, which is what the IDV probably uses.

The CoordinateAxis classes enforce the data model that coordinates must be invertible (monotonic if 1d). In this case it just adds +- 360 to remove the seam.

Its possible this method just wont work for this dataset, or that we need to rethink invertibility.

This dataset is particularly ugly, because its using 2D lat/lon near the pole. I would advise them not to do that.

Sean is testing how this works in the IDV. If you have a specific thing thats not working, send it along.

John

On 7/11/2013 11:19 AM, Tom Whittaker wrote: 
Hi John....

I've started to evaluate the changes....and unfortunately, there are
some ripple effects -- some things just are not working.

In thinking about this, shouldn't it be the responsibility of the
drawing routine to sort out the "seams"?  I am concerned (more so
now...) that the netCDF library is changing values handed back to the
caller when none of the metadata says do that.  My gut is telling me
that is not the "right" thing to do...the values in the file (as
modified only by missing code, the
offset and the scaling, if applicable) should be returned to the
caller, not something that "magically" is done.

While it might be a nice "service" to provide for some applications,
perhaps the proper way is to introduce some attribute that says
"please_fix_my_seams"; otherwise leave the values sacrosanct....

What do other people think?

tom

On Wed, Jul 3, 2013 at 3:30 PM, John Caron <address@hidden> wrote:

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):


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


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.