Unidata/thredds — pull request #14 by delta407 (2012-09-03 05:45:28+00:00)
Title: GRIB previously-defined bitmap support

Some GRIB files use bitMapIndicator = 254 -- "predefined bitmap" -- which is unsupported by grib-4.3.13.

The instances I found in the wild (e.g. [this GFS 2.5º GRIB](http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2012090300/gfs.t00z.pgrbf00.2p5deg.grib2)) use this feature on certain U/V wind fields; NetCDF-Java can read the U field just fine, but the V field blows up. Both of these fields are packed into the same GRIB message. It makes sense to me that V would use U's bitmap data, so now `Grib2RecordScanner.nextRepeating()` tests for the case where subsequent records' bitmaps have indicator = 254, and if so, it keeps the previous bitmap instead.

I then discovered that `Grib2RecordScanner` is used to generate indexes, that Grib2Iosp uses these indexes for all read operations, and that the index contains little more than the Grib2Record offset -- which in this situation, contains a bitmap that says "use the previous bitmap". Therefore, I added an optional `bitmapPos` field to the indexed Record structure. It's populated unconditionally when generating indexes, and it's plumbed it through the Grib2Iosp read path all the way back to Grib2Record.

If the bitmap position is not specified in the index -- for example, due to reading an index generated by a previous version -- it falls back to using the inline bitmap and exploding on "previously-defined bitmap" records like it does now. And of course, thanks to Protocol Buffers, adding a field to the record structure doesn't affect old software reading the new indexes.