Hi Tom, I haven't totally tracked it down, but I've found something that does seem to be different between the two. The bounding box that is computed using netCDF-Java is incorrect for the NN file because the longitude spans the +/- 180, whereas this is not an issue with the NF files. It's possible that this is leading to an error later on down the stack, but I haven't made it that far yet. One thing that jumps out is that the longitude width of the bounding box is 349.9, but it is not considered a a global grid (that is, the isGlobalLon() method on the GridCoordSys returns false). I'm wondering if this ends up causing some problem on the IDV side. The variables actually contain a projection called LatitudeLongitude, and that seems ok and is the same as those found in the NF files. Again, still trying to track this down, but I think I might be going in the right direction at this point...so, this is more of an update than a fix, unfortunately. John will be back in the office next week, so I'll speak with him them and see if he has any ideas. Cheers! Sean > Hi John & Sean -- > > Now that the workshops are done, I'm hoping someone has had an > opportunity to investigate why the IDV is not making a coordinate > system when reading this file. The user contacted me again this past > week and is anxious to be able to use the tools for their work...so > any help you can provide would be really appreciated. > > Thanks! > > Best wishes, > > tom > > > On Wed, Jul 17, 2013 at 10:33 AM, Unidata netCDF Java Support > <address@hidden> wrote: > >> Hi John.... > >> > >> Thanks for the explanation. I understand things better now, and I > >> conclude that the "only" issue remaining is that the IDV does not, for > >> the "NN" file, create whatever is required so that the main 2D display > >> can auto-set the projection to cover just the region enclosed by the > >> data. It also does not display correctly in the "world" projection > >> (see attached, using the nightly build). I can remap this into a > >> South Pole conformal and it looks great, though... > > > > We will have to look at the IDV code, probably cant get to it until after > > the workshop. > > > > Long term, im starting to develop a new feature type class for satellite > > data, which could have different behavior than the grids. So if you have > > ideas how things could be handled better, id be interested. > > > >> > >> McV has another (possibly related) issue in that the 2D display used > >> for the scatter plots does not understand longitudes < -180 > >> apparently. We will have to deal with that one, I guess. > > > > If you pass the lon value through a normalizer like > > LatLonPointImpl.lonNormal() you can adjust the range. If you dont need > > connectedness, maybe that is sufficent. > > > > > > > > John > > > > > > Ticket Details > > =================== > > Ticket ID: XIR-445342 > > Department: Support netCDF Java > > Priority: Urgent > > Status: Open > > > > > > -- > 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: Critical 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.