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.
Peter, >Date: Thu, 22 Sep 2005 10:33:51 -0600 >From: Anne Wilson <address@hidden> >Organization: UCAR/UOP/UPC >To: Peter Silva <address@hidden>, >To: address@hidden >Subject: Re: NLDM & LDM data types... The above message contained the following: > > This is basically the same size address space as IP addresses. > > Can the CMC have a ´class B´ (say Unidata assigns us the first 16 > > bits, and then we can assign the lower order 16 bits) so that we > > can define arbitrary data types that we feed, and avoid clashes > > with other data providers when the definitions get to Unidata? 64 > > thousand data types would probably be enough for a while... the > > other benefit, is that if anybody gets a feed they don´t understand, > > they will know at least who it came from by the type range. > > > > say we were assigned... CDA1 (Canada #1 :-) for our first 16 bits) then > > we could have: > > > > CDA10000-ffff for weather model outputs > > 2000-fffff for remote sensing. > > 2100-27ff for RADAR > > > > We would use lots of stream types, and require less complicated regular > > expressions :-) > > If 16 K is ever not enough... > > > > Is anything like that planned? While the above idea is intriguing, I'm afraid it's not possible to implement because, in the current version of the LDM protocol, the 32-bit feedtype variable is a bit-mask in which each bit is associated with a primitive feedtype (e.g., IDS, HDS, CONDUIT). > Do recall, however, that now you can use a regular expression on your > upstream host to limit what is pushed. It has been argued that this > obviates the need for more feed types, Version 6.4 supports ALLOW entries like ALLOW NEXRAD2 host\.domain\.com KD KDMX which would allow the LDM on host host.domain.com to receive NEXRAD2 data-products from stations that begin with "KD" but not from station KDMX. The last three fields are extended regular expressions. > although IMO it's a difficult, fairly unfriendly way to further parse > the data. I agree -- although, given the current protocol, it's better than nothing. Regards, Steve Emmerson