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

[LDM #GOE-694008]: Request for temporary IDD for NWA Demo

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: [LDM #GOE-694008]: Request for temporary IDD for NWA Demo
  • Date: Thu, 09 Feb 2012 17:25:08 -0700
Hi Brad,

Sorry to have taken so long to get back to your inquiry into FXUS10
products...

re: same kind of products being classified in two different datastreams
> Thanks ... that's good troubleshooting, I will look to see if we still have
> that older product perhaps in a snapshot copy and email it off, but I don't
> think we will still have it.

I found an example of an FXUS10 product that was put into the HDS datastream
instead of the expected IDS|DDPLUS datastream.  I have attached a product put
in HDS and one from the same day in the previous hour that was put into
IDS|DDPLUS to illustrate the subtle differences in the two products.

Product put into IDS|DDPLUS - FXUS10_KWNH_071522_.20120207
Product put into HDS        - FXUS10_KWNH_071612_.20120207

The difference between that caused the classification as an HDS product is
in the very end of FXUS10_KWNH_071612_.20120207.  The last few lines of 'od -c'
output for the two products illustrates the cause of the different 
classifications:

Classified as IDS|DDPLUS:

od -c FXUS10_KWNH_071522_.20120207 | tail -3

0002120  \n   C   I   S   C   O  \r  \r  \n   $   $  \r  \r  \n  \r  \r
0002140  \n  \r  \r  \n  \r  \r  \n 003
0002150

Classified as HDS:

od -c FXUS10_KWNH_071612_.20120207 | tail -3
0003140  \r  \r  \n   C   I   S   C   O  \r  \r  \n 241  \v   $   $  \r
0003160  \r  \n  \r  \r  \n  \r  \r  \n  \r  \r  \n 003
0003174

The important differences in the two products are the two additional
bytes ('241  \v') after 'C   I   S   C   O  \r  \r  \n'.

These unexpected control characters triggered logic in readnoaaport code
aimed at distinguishing between ASCII text and binary products (the other
control characters in both files are ignored because they are expected).
From my perspective, our code was doing what it should, so this is not
really a bug.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: GOE-694008
Department: Support IDD
Priority: Normal
Status: Closed

Attachment: FXUS10_KWNH_071612_.20120207
Description: Binary data

Attachment: FXUS10_KWNH_071522_.20120207
Description: Binary data