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

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

Hi Tom,

I've loaded the file into the IDV using 3.1u1, 4.0u1, and the latest version
from master, and I can't see a difference between any of them. If I view the
file using the South Pole Projection, then it looks great. The DataProbe also
seems to be working the same in all three as well.

You mentioned in another email that the IDV isn't able to set a projection
from the display. The reason is that there isn't any projection information
in the file, likely because lat / lon are the only coordinate variables in
the file.

I guess overall I am confused as to what the issue is. I mean, I see that the
lat / lon returned from the CoordinateAxis is different from those in the file,
but as John said, these are "enhanced" since you are going through 
NetcdfDataset. At any rate, I can't tell if the IDV is having any issues with
this, given that everything seems to behave the same, from a IDV
users perspective, between 3.1u1, 4.0u1, and master.

Could you give us more info on the application in which the values returned 
from CoordinateAxis is messing things up?

Thanks!

Sean

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


Ticket Details
===================
Ticket ID: XIR-445342
Department: Support netCDF Java
Priority: Urgent
Status: Open