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