[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

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Fwd: Re: [netCDFJava #XIR-445342]: Problem with netCDF-Java CoordinateAxis returning wrong values
  • Date: Thu, 11 Jul 2013 12:32:34 -0600
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