This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: "Mark J. Laufersweiler" <address@hidden> >Organization: OU >Keywords: 200505190416.j4J4GsP3013540 IDD Hi Jared, It has come to our attention that the machine magic.ocs.ou.edu is feeding an IDD relay machine at OU, stokes.metr.ou.edu (stokes is maintained by Mark Lauferswiler <address@hidden>). stokes.metr.ou.edu is requesting all data from the IDS|DDPLUS|PPS and HDS feedtypes from magic.ocs.ou.edu using the following request lines: (from ~ldm/etc/ldmd.conf on stokes.metr.ou.edu) # local requests request IDS|DDPLUS|PPS ".*" magic.ocs.ou.edu ALTERNATE request HDS ".*" magic.ocs.ou.edu ALTERNATE The problem is that the products that stokes.metr.ou.edu is getting with these requests are labled using the compound feed type WMO. Tagging products with WMO makes requests for IDS, DDS, PPS, HDS and DDPLUS all match those products. Each simple feedtype is represented by a single bit in a 32-bit word; compound feed types (DDPLUS in this case) contain all bits from the feedtypes it represents. WMO is a compound feed type that represents the union of IDS, DDS, PPS, and HDS; DDPLUS is a compound feed type that represents DDS and PPS. IDS|DDPLUS|PPS and HDS products being ingested from magic.ocs.ou.edu on stokes and labeled as WMO are effectively "advertising" themselves to be IDS, DDS, PPS, and HDS products all at the same time. Given this, any machines requesting any of the IDS, DDS, PPS, HDS, DDPLUS or WMO feeds from stokes will receive all products labled as WMO that are originating from magic.ocs.ou.edu. This is a very bad situation for the IDD! We strongly recommend that products _never_ be labled using a compound feed type. Also it is very likely that the process you have that is inserting the products into your LDM queue is not calculating MD5 checksums (the unique signature for IDD products) in the same was as the "official" machines populating IDD datastreams. This is also a bad situation when the mislabeled products have the chance of getting relayed in the IDD. We would greatly appreciate if you would change your labeling of products from WMO to appropriate, simple IDD feedtypes as soon as possible. If this is not possible, we will need to ask Mark to either stop ingesting data from magic.ocs.ou.edu or to stop feeding downstream IDD nodes. We do not like either of these two options, however. Thanks in advance for help us out of the situation we are faced with! Cheers, Tom Yoksas Mark Lauferswiler wrote: >Magic is the Oklahoma Climate Survey ldm that is fed off their >NOAAPort. I have CC'd my contact for their server, Jared Bostic. > >You can check the ldmd.conf for Stokes at >http://stokes.metr.ou.edu/etc to see how I request the feed. > >As I understand it, magic is my alternate feed for all but NIDS, >where it is the primary. > >Any questions regarding their setup are best directed to Jared. > >mjl > > >On Wed, 18 May 2005, Tom Yoksas wrote: > >> >From: Jeff Weber <address@hidden> >> >Organization: OU >> >Keywords: 200505182256.j4IMuTTm007093 >> >> Hi Mark, >> >> Just to augment Jeff's note. On April 29, stokes started receiving >> a significantly increased volume of data tagged as WMO. Please >> see: >> >> http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc1?WMO+stokes.metr. > ou.edu+-b%2086400 >> >> Stokes is getting this data from magic.ocs.ou.edu. >> >> Is magic.ocs.ou.edu a NOAAPORT ingest box (if yes, whose)? If yes, it >> is labeling data using the WMO feedtype "incorrectly". I say >> incorrectly since stokes is receiving the data and then relaying it to >> several downstreams in the IDD: >> >> twister.sbs.ohio-state.edu >> bergeron.rnet.missouri.edu >> tornado.geos.ulm.edu >> >> Can you help us find out who manages magic.ocs.ou.edu; to verify >> that they started inserting 'WMO'-tagged data at the end of April; >> that you are requesting it; and that it is leaking out into the IDD? >> >> Thanks in advance... >> >> Cheers, >> >> Tom >> >> Jeff Weber wrote: >> >> >Are you guys doing anythinhg unique with the WMO feed from stokes..? >> > >> >Note: >> > >> >http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?WMO+stokes.metr. > ou. >> > edu >> > >> > >> >vs >> > >> >http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?WMO+chisel.rap.u > car >> > .edu >> > >> > >> >Your volume is MUCH larger... >> > >> >Curious, >> > >> >Jeff >> >--------------------------------------------------------------------- >> >Jeff Weber address@hidden : >> >Unidata Program Center PH:303-497-8676 : >> >University Corp for Atmospheric Research 3300 Mitchell Ln : >> >http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000 : >> >--------------------------------------------------------------------- >> Cheers, >> >> Tom > >-- >-------------------------------------------------------------------- > Dr. Mark J. Laufersweiler | > School of Meteorology | Those who give up essential > University of Oklahoma | liberties for temporary safety > address@hidden | deserve neither liberty nor safety. > (405) 325-6032 | - Benjamin Franklin > (405) 325-7689 (fax) | > -- 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.