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