Hi Roy, I think Marcos was suggesting stacking all the GRIB records that use the 58-0-2 table into one file and stacking all the GRIB records that use the 58-0-3 table into another file. The two resulting index files would each be self-consistent. Then doing a featureCollection to aggregate those two files might work because, we think, it is the inconsistency in the GRIB information rather than in the resulting netCDF information that causes trouble. We haven't tried it out yet. But that might be a kludgy quick fix to try next. Ethan Roy Mendelssohn wrote: > > Thanks. We don't have any control over what is sent to us by FNMOC, > and I am not particularly proficient in redoing Grib files, nor would > I want to. > > We have written these to netcdf, but were hoping to cut down steps in > our processing. > > -Roy On Feb 22, 2013, at 9:26 AM, "Unidata THREDDS Support" > <address@hidden> wrote: > >> Hi Roy, >> >> it looks like the files are using two different versions of the >> same grib table. In the wgrib output for some files says: ... >> center 58 subcenter 0 process 58 Table 2 scan: WE:SN winds(N/S) >> ... >> >> but for some others: ... center 58 subcenter 0 process 58 Table 3 >> scan: WE:SN winds(N/S) ... >> >> So, when the netcdf-JAVA creates the grib collection finds two >> different variables in the grib records (one per grib table) but >> those variables resolve in the same name and finally fails to >> create the dataset. I don't really know how to fix that but a >> workaround could be create grib files with records containing same >> tables and then aggregate those files. >> >> Cheers! Ticket Details =================== Ticket ID: MRV-895858 Department: Support THREDDS 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.