20020620: Duke Power's offer to create backup NEXRCOMP imagery

>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200206210329.g5L3T2a26558 IDD

Gilbert and Mike,

>Did you get an answer from the UPC on this?

We have not answered Mike yet.  I will respond here.

>> Hi,
>> 
>> A while ago, I emailed Steve about trying to setup a gdradr processes on
>> this end that would create the sort of files you have
>> below and make them available to the IDD community. But at the time I
>> didn't have much success because
>> the output GEMPAK files were so large making it difficult to distribute via
>> the IDD.
>> 
>> We have in place 2 full-time NOAAPORT systems (PDI and Unisys), and would
>> be willing to offer the same deal again if there
>> was interest, now that it appears the GINI files are of manageable size.
>> This would give the community a backup source of
>> the national GINI images below you all are creating. We have an existing
>> LDM feed arrangement with Gilbert at NIU to pass data
>> through our firewall, if he would be willing to receive our GINI products
>> for distribution to Unidata.  I just installed 6 new dual athlon
>> rack servers with GEMPAK, so I have plenty of capacity to generate the
>> products and possibly others, like a national VIL product
>> for example.
>> 
>> All I would need are the scripts you use to create these images, and
>> possibly a little bit of help setting them up.
>> Let me know if that's something you all are interested in.
>> 
>> Thanks,
>> 
>> Mike Dross
>> Meteorologist
>> Duke Energy

We appreciate Mike's offer to create the composite radar imagery as a
backup to the ones we are sending in the IDD FNEXRAD feed and/or to
create additional products that we are not currently generating.  The
problem with trying to create products that could be substituted for
the existing ones and making them available to IDD users is that it
would be next to impossible to create product that are exactly
identical to the ones now being generated, and that is a requirement so
that duplicate products could be rejected by a site that has already
received a first copy.  The LDM calculates an MD5 checksum for each
product it sends, and _any_ change in a duplicate product would result
in a different MD5 checksum than the original.  The result of this
would be that a site, typically a top level relay, that has a feed of
the same IDD datastream (e.g., FNEXRAD) from more than one machine
might find itself accepting two copies of each product.  Given that the
decoded size of the 1 km N0R composite after decoding is 14 MB, a site
could get itself into a heap of trouble in no time flat.  This is the
main reason that we are not generating the composites on different
machines that we have control of.

Now, as to creating other composites that we are not generating, this
is an attractive idea, but we are not ready to dive into this right
now.

Finally, Chiz (Steve Chiswell, our GEMPAK guru) told me that the
directions on how to create the composites is available in the
Unidata GEMPAK web site.  This must be the case since Robert Mullenax
of Universial Weather read through the documentation and is now
producing composites for Univ Wx's own use.

Got to run...

Tom

>From address@hidden Wed Jun 26 20:22:04 2002
>Subject: Re: 20020620: Duke Power's offer to create backup NEXRCOMP imagery

Tom,

Thanks for the explanation.
Hope all is well on your end.

Take care,
Mike