The first versions of Metcast relied on NODDS' request.mfr file. The reason was compatibility with JMV/ISIS: JMV's product selection module creates a request.mfr, which could be processed by an ISIS database. Metcast merely took upon delivering this request.mfr to the database, and the database's reply, packed.dat, back to JMV. To handle real-time synoptic observations and real-time satellite data, however, request.mfr had to be extended. The Metcast server had to process these extensions separately, rather than relaying them to ISIS.
The new version of Metcast would do away with request.mfr for good. This is long overdue: request.mfr was never intended to be used for requesting anything but low-resolution grids. Requesting of other types of data had to be hacked-on. For example, the mandatory grid resolution field is an important parameter indeed for a grid product, but it has no meaning for a synoptic observation request. Thus request.mfr has evolved over the years into a hodge-podge of dissimilar features (some of them obsolete and no longer used), which is difficult to process for both a computer and a human. Since we are not bound with compatibility any more, there is no sense to keep the corpse of request.mfr unburied.
Examples below compare MBL requests with the those in the NODDS request language
request.mfr style)
BIG area CURRENTDTG JMV 1.8.Xa 1 973EC11XXX MZZ 70.000N 025.000W 000 025 041 05.0 005.0OM
A new-style request
(BIGAREA (bounding-box 70.0N 25.00W -50 175) (products (METAR)))
request.mfr style)
NORF CURRENTDTG JMV 1.7.0f 19961025 1 96CC011NOG A01 45.000N 099.000W 024 023 026 01.0 001.0OM
A new-style request
(NORF (bounding-box 45.0N 99.0W 23N 74.0W) (products (pressure (layer surface) (tau 24) (resolution 1.0)))
request.mfr style)
npa CURRENTDTG JMV 2.0b 16 976AC11NOG A01 60.000N 178.500W 000 021 033 01.5 001.5OM 976AC11NOG A01 60.000N 178.500W 012 021 033 01.5 001.5OM 976AC11NOG A01 60.000N 178.500W 024 021 033 01.5 001.5OM 976AC11NMC A01W60.000N 178.500W 000 021 033 01.5 001.5OM 976AC11NMC A01W60.000N 178.500W 012 021 033 01.5 001.5OM 976AC11NMC A01W60.000N 178.500W 024 021 033 01.5 001.5OM 976AC11NOG A07 60.000N 178.500W 000 021 033 01.5 001.5OM 976AC11NOG A07 60.000N 178.500W 012 021 033 01.5 001.5OM 976AC11NOG A07 60.000N 178.500W 024 021 033 01.5 001.5OM 976AC11NOG F00 60.000N 180.000W 000 016 026 02.0 002.0OM 976AC11NOG F00 60.000N 180.000W 012 016 026 02.0 002.0OM 976AC11NOG F00 60.000N 180.000W 024 016 026 02.0 002.0OM 976AC11NOG F8B 60.000N 180.000W 000 016 026 02.0 002.0OM 976AC11NOG F8B 60.000N 180.000W 012 016 026 02.0 002.0OM 976AC11NOG F8B 60.000N 180.000W 024 016 026 02.0 002.0OM 976AC11ATN CR3 000 3000 -17900 6000 -13100
A new-style request
(npa (bounding-box 60.0N 179W 30.0N 131W) (resolution 1.5) (products (pressure (layer surface) (tau 0 12 24)) (pressure (layer surface) (tau 0 12 24)(model NMC)) (temperature (layer surface) (tau 0 12 24)) (geo-height (layer isobar 500)(tau 0 12 24) (resolution 2.0)) (vorticity (layer isobar 500))(tau 0 12 24)(resolution 2.0)) (3D-temperature) ))
Using a pre-defined dictionary, the request could be formulated as
(npa (bounding-box 60.0N 179W 30.0N 131W) (resolution 1.5) (use FNMOC) (products (A01 (tau 0 12 24)) (A01 (tau 0 12 24)(model NMC)) (A07 (tau 0 12 24)) (F00 (tau 0 12 24)(resolution 2.0)) (F8B (tau 0 12 24)(resolution 2.0)) (3D-temperature) ))
or even as
(npa (bounding-box 60.0N 179W 30.0N 131W) (resolution 1.5) (use FNMOC) (tau 0 12 24) (products (A01) (A01 (model NMC)) (A07) (F00 (resolution 2.0)) (F8B (resolution 2.0)) (3D-temperature) ))
If, for example, the F8B product was requested only for tau 0 and 12, this could be expressed as
(npa (bounding-box 60.0N 179W 30.0N 131W) (resolution 1.5) (use FNMOC) (tau 0 12 24) (products (A01) (A01 (model "NMC")) (A07) (F00 (resolution 2.0)) (F8B (tau 0 12)(resolution 2.0)) (3D-temperature) ))
Any Metcast client may inquire a server for a list of products it serves (and which of them are potentially or actually available). The server would return a list, in a format closely patterned after CDF, a Channel Definition Format.
<Channel HREF='http://zowie/cgi-bin/oleg/server'
MIMEType='application/x-grib'>
<Abstract>Geopotential Height....
</Abstract>
<Title VALUE='geopotential-height'/>
.. scheduling information, see CDF for details...
<Publisher id='FNMOC'>Fleet Numerical Oceanography ....</Publisher>
<Item>
<Title VALUE='100 MB, NOGAPS model'/>
<Usage>(layer isobar 100)(model NOGAPS)</Usage>
</Item>
<Item>
<Title VALUE='mean sea level, NOGAPS model'/>
<Usage>(layer mean-sea)(model NOGAPS)</Usage>
</Item>
...
</Channel>
The Abstract field is intended to be user-friendly, to be used by a client to describe a product to a user. The Title and Usage fields tell the client how to request that particular product.
At present, this CDF file for GRIB products is not built automatically. I have built it by hand. I tried to keep to CDF as close it possible; on the other hand, if Microsoft itself -- the submitter of CDF -- can't abide by it, neither should we take the format as written in stone.