NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Steve,At issue is the fake FOS blocks; with NOAAPort, we can fake the FOS catalog number by using the last three digits of the NOAAPort product sequence number. EMWIN, though, doesn't have transport headers from which to grab such a number.
My first iteration for Gilbert used a count based on the find return through the unzipped data . . . but this was found to be unreliable as the find packaged with Solaris returned a different order than the find with Linux.
So, for the meantime, I used Jim Cowie's solution - 999.This makes the EMWIN distributed data, then, different than the NOAAPort data . . . because of the fake FOS header. At least as far as MD5 checksum is considered.
Stonie On Apr 29, 2007, at 4:04 PM, Steve Emmerson wrote:
Gilbert,Since I send out emails with tornado warnings and such, if I had NOAAport and EMWIN turned on, I bet I'd get duplicate emails sent out. Different LDM generated numbers (albeit same time stamp on the WMO header). Otherwise, I'd do it.If the products are first passed through an LDM system, then you shouldn't see duplicate emails because the LDM product-queue will not allow a data-product that has the same MD5 signature as a data- product that is already in the product-queue to be inserted into the queue. Of course, this requires that the data-products have the same MD5 signature and different LDM ingesters don't always compute the MD5signature the same way. Regards, Steve Emmerson
ldm-users archives: