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

[McIDAS #ZSL-626225]: Dual Pol dataset access problem



Hi Barry,

Sorry for the silence yesterday; I have been taking Thursdays off to go
skiing :-)

I think I know what is going on wrt the strange IMGLIST listings for
NEXRAD Level III Dual Pol products... for some reason, the PUPs are
sending out semi-blank products.  I ran into this early on in development
for Dual Pol serving, and I actually hardwired a check to return blank
info when the product contains a complete header but no data.

The problem in creating a list of the stations reporting is as follows
(a MUCH abbreviated description of the process and likely not completely
correct because I haven't matched my concept against the code yet (I
came up with this view while skiing :)):

- the code generates a list of files that match the dataset definition
  for the product the user wants to see (using 'glob' and the
  regular expression specified in RESOLV.SRV)

- the list of files is sorted by day/time so that the most recent file
  can be picked off of the front/top of the list

  To do this, each file must be cracked to determine its date/time and
  NEXRAD station ID

  Comment: The code does _not_ assume that the ID included in the LDM/IDD
  Product ID is correct.

  If the ID found in the product does not
  match the ID specified in the request, the product is ignored.
  What does not happen, however, (I think; I have to check this)
  is using the next most recent product in the list as the most
  current.  This is likely where the problem is occurring.

Given the logic currently in place (and which has worked for Level
III products since the beginning of support), the list of files
generated when one asks for ID=LIST could be complete, but when
one goes to display the most recent image, there is nothing to
display.  The current logic likely allows for other unplanned/
undesirable scenarios.

The challenge is how to generate a list of elements of a dataset
when some of the possible elements are 100% viable (meaning
that they have full and correct headers AND data) and others
are not (the typical scenario is when there is a viable header
and no data).

My position on this is that the real problem is that non-viable
products are being issued by a PUP when they should not be.  I
will be reporting this to the NEXRAD folks to see if they can
fix the situation.

Comment:

- it is very interesting that the problem at-hand has not been
  seen (or has not been seen enough for all of the users to
  notice) before now

  Again, the code that generates lists of dataset elements is
  the same for all Level III products.  The observation that
  the only problem is for some Dual Pol products seems to indicate
  that the code that produces the Dual Pol Level III products
  and then injects them into the IDD (at the PUP) is flawed.

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: ZSL-626225
Department: Support McIDAS
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.