[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NLDM & LDM data types...

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.

  • Subject: Re: NLDM & LDM data types...
  • Date: Thu, 22 Sep 2005 12:31:23 -0600
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