[Support #YZT-862981]: AMV NetCDF files read in with the incorrect time in McV 1.6, but it worked in 1.5. [2405]

> Thanks, Yuan.  I agree that we should discuss this at the teleconference
> next Tuesday.  It looks like this topic has already been added to the
> agenda online.
> 
> - Bob

It should be fixed in the latest commit of ncIdv.jar.

Yuan
> 
> On 9/9/2016 2:13 PM, Unidata IDV Support wrote:
> >>> Hello -
> >>>
> >>> We have a few AMV (Atmospheric Motion Vector) point NetCDF files that 
> >>> worked correctly in McV 1.5 and IDV 5.0, but don't work correctly in 
> >>> versions more recent than those.  See the Request of this inquiry for 
> >>> more information as well as the location of the files.  We have set Tommy 
> >>> J as the POC at SSEC.  I've run this by the NetCDF/java group and they 
> >>> pointed me to you to see if you had any ideas on what might be happening 
> >>> on the IDV side.
> >>>
> >>> Any thoughts?
> >>>
> >>> Thanks -
> >>> Bob Carp
> >>>
> >> Bob,
> >>
> >> Quick answer is that the latest netCDF-Java library has stricter 
> >> requirement of the dataset to be in better CF compliance comparing to the 
> >> earlier version. I will download a sample and find out what need to be 
> >> changed.
> >>
> >>
> >> Yuan
> > Well, I did check the dataset and it is very bad shaped: incorrect unit, 
> > attributes all over the places. We can talk about it in the next telconf.
> >
> >
> > Yuan
> >>> ----==== Inquiry ====----
> >>> 2405
> >>>
> >>> ----==== Summary ====----
> >>> AMV NetCDF files read in with the incorrect time in McV 1.6, but it 
> >>> worked in 1.5.
> >>>
> >>> ----==== Request ====----
> >>> 2016-09-07 - Bob Carp
> >>> There are currently three files in ftp://ftp.ssec.wisc.edu/pub/incoming:
> >>>
> >>> amv.HIMAWARI-8.2015313.0010.ch_14.nc
> >>> amv.Meteosat-10.2015304.1200.ch_14.nc
> >>> amv.MTSAT-2.2014251.1114.ch_14.nc
> >>>
> >>> In the IDV 5.0 and McIDAS-V 1.5, these files can all be read in as a 
> >>> 'netCDF/GEMPAK Point Data files' data type.  When the 'Point Data' field 
> >>> is displayed with the Point Data display type, two things happen:
> >>> 1. The data displays with the correct timestamp
> >>> 2. All of the vectors display in the same timestep
> >>>
> >>> In any IDV/McV versions more recent than the version listed above, two 
> >>> things happen:
> >>> 1. The data displays with the incorrect timestamp (1969-21-31 or 
> >>> 1970-01-01)
> >>> 2. All of the vectors want to display in their own timestep (you can 
> >>> 'fix' this by adjusting the time binning of the data source)
> >>>
> >>> I checked with the NetCDF/java group at Unidata and here was their 
> >>> response:
> >>> As far as I can tell, toolsUI 4.3 vs 4.6 does not treats these files in 
> >>> the same way. I know the IDV team, specifically Julien, has done some 
> >>> work in the IDV to improve the handling of Point Data. It's possible that 
> >>> there is a bug there, or maybe even in the way the PointFeature API from 
> >>> netCDF-Java is being used. It also might be a limitation of the 
> >>> PointFeeature API, which treats point data as a stream. Have you 
> >>> contacted the IDV group to see if they are able to see what is going on 
> >>> with these files?
> >>>
> >>> Any thoughts?  The files mentioned above should remain on ftp for a week 
> >>> (through 9/14).  If anyone needs access to them after that date let me 
> >>> know and I can re-post them.
> >>>
> >>> 2016-08-31 - Bob Carp
> >>> The summary of this inquiry was:
> >>> Meteosat AMV NetCDF file reads in with the incorrect time in McV 1.6, 
> >>> works in 1.5.
> >>>
> >>> I'm changing it to:
> >>> AMV NetCDF files read in with the incorrect time in McV 1.6, but it 
> >>> worked in 1.5.
> >>>
> >>> This is because other AMV files have the same problem, such as Himawari 
> >>> and MTSAT.  For sample data, see /home/mcuser/inquiry-data/2417/*.
> >>>
> >>> 2016-08-13 - Bob Carp
> >>> Load the amv.Meteosat-10.2015304.1200.ch_14.nc file as a NetCDF/GEMPAK 
> >>> Point Data Source.  Through the Properties window of the data source, 
> >>> change the time binning to 1 hour.  This prevents having individual 
> >>> timesteps for each data point.  Note that this is a change from 1.5, 
> >>> where in 1.5 you didn't need to change the time binning for things to 
> >>> display in one tilmestep.  However, each point really does have its own 
> >>> time, so this probably isn't a big deal.
> >>>
> >>> The main problem is that in 1.6 the timestamp (macro and in the Time 
> >>> Animation Widget) reads as 1969-21-31 23:58 (with time binning of 1 hr).  
> >>> In McV 1.5 the timestamp is read as 2015-10-31 12:00:00Z which matches 
> >>> the time in the filename.
> >>>
> >>>
> >>> ################################################################################
> >>>
> >>> http://mcidas.ssec.wisc.edu/inquiry-v/index.php?inquiry=2405
> >>>
> >>>
> >
> > Ticket Details
> > ===================
> > Ticket ID: YZT-862981
> > Department: Support IDV
> > Priority: Normal
> > 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.
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: YZT-862981
Department: Support IDV
Priority: Normal
Status: Closed
===================
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.