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.
On Apr 29, 2007, at 4:04 PM, Steve Emmerson wrote:
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
Of course, this requires that the data-products have the same MD5
signature and different LDM ingesters don't always compute the MD5
signature the same way.