[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[Staging #YUL-837325]: Fwd: NOAAport vendor
- Subject: [Staging #YUL-837325]: Fwd: NOAAport vendor
- Date: Fri, 05 Sep 2014 08:28:25 -0600
Hi Sue,
Just so you know: I drove our exchange regarding "who is our NOAAPort vendor"
into our inquiry tracking system.
re:
> Thanks for the answer.
No worries.
re:
> Here is my issue: We are ingesting NIDS TDWR TZL (long range reflectivity)
> product via LDM.
Just to make sure that I know what the source of the data you are
receiving is I have to ask what upstream your LDM is requesting the
data from?
re:
> In general, we use ucnids to strip headers and execute
> zlib decompression for many NIDS products if necessary before processing
> the data. The zlib decompression sequence is found in the packaged TZL data
> from the LDM; however, it appears that the TZL data are not zlib
> compressed. ucnids only correctly processes the product when a tweak is
> made and decompression is intentionally skipped. We have not had problems
> with other products.
OK, I understand the problem now.
re:
> Is it a bug in the packaging of the data for the LDM
> that the zlib compression sequence is inserted for this TZL product?
If you are receiving the TZL products from the IDD (Internet Data
Distribution system), then the origin of the products is from the
NOAAPort SBN (Satellite Broadcast Network, the system that the NWS
uses to distribute data to WFOs), and the format of the products
is exactly as is broadcast since the LDM never changes the content
of any of the products that it relays.
If I recall correctly, each NEXRAD Level III product (TDWR products
are distributed in the exact same way that NEXRAD products are, and
their formats are very close to being the same as NEXRAD products)
contains information that indicates the format of the product. It
is most likely that the TZL products' headers contain information
that indicates whether they are zlib compressed or not. I say this
with great confidence since the "decoders" that we distribute with
our GEMPAK and McIDAS packages have not experienced any problems
with processing of the TZL products. If they had, we would certainly
have received problem reports from those community members that have
been actively using these packages to look at/analyze these images
for the past several years.
Regardless of my previous comments, I do not rule out the
possibility that one or more stations reporting TZL products are
producing them incorrectly! Are you seeing the unexpected format
for all stations reporting TZL products, or just a subset?
I just did a quick listing of the most recent TZL data from a
McIDAS ADDE server we operate to get the list of stations that
are creating TZL products, and that we are serving:
% imglist.k RTTDWR/TZL ID=LIST
Image file directory listing for:RTTDWR/TZL
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
1 RADAR 5 SEP 14248 14:19:05 ADW 1
2 RADAR 5 SEP 14248 14:19:51 ATL 1
3 RADAR 5 SEP 14248 14:16:04 BNA 1
4 RADAR 5 SEP 14248 14:14:59 BOS 1
5 RADAR 5 SEP 14248 14:12:01 BWI 1
6 RADAR 5 SEP 14248 14:17:19 CLT 1
7 RADAR 5 SEP 14248 14:15:40 CMH 1
8 RADAR 5 SEP 14248 14:15:18 CVG 1
9 RADAR 5 SEP 14248 14:20:32 DAL 1
10 RADAR 5 SEP 14248 14:16:15 DAY 1
11 RADAR 5 SEP 14248 14:19:11 DCA 1
12 RADAR 5 SEP 14248 14:16:10 DEN 1
13 RADAR 5 SEP 14248 14:17:01 DFW 1
14 RADAR 5 SEP 14248 14:19:13 DTW 1
15 RADAR 5 SEP 14248 14:20:45 EWR 1
16 RADAR 5 SEP 14248 14:19:05 FLL 1
17 RADAR 5 SEP 14248 14:14:27 HOU 1
18 RADAR 5 SEP 14248 14:15:33 IAD 1
19 RADAR 5 SEP 14248 14:20:29 IAH 1
20 RADAR 5 SEP 14248 14:16:35 ICH 1
21 RADAR 5 SEP 14248 14:16:47 IDS 1
22 RADAR 5 SEP 14248 14:19:27 JFK 1
23 RADAR 5 SEP 14248 14:15:48 LAS 1
24 RADAR 5 SEP 14248 14:15:11 LVE 1
25 RADAR 5 SEP 14248 14:19:26 MCI 1
26 RADAR 5 SEP 14248 14:18:15 MCO 1
27 RADAR 5 SEP 14248 14:16:32 MDW 1
28 RADAR 5 SEP 14248 14:14:57 MEM 1
29 RADAR 5 SEP 14248 14:14:53 MIA 1
30 RADAR 5 SEP 14248 14:18:22 MKE 1
31 RADAR 5 SEP 14248 14:18:50 MSP 1
32 RADAR 5 SEP 14248 14:15:23 MSY 1
33 RADAR 5 SEP 14248 14:20:35 OKC 1
34 RADAR 5 SEP 14248 14:18:01 ORD 1
35 RADAR 5 SEP 14248 14:17:50 PBI 1
36 RADAR 5 SEP 14248 14:15:53 PHL 1
37 RADAR 5 SEP 14248 14:17:26 PHX 1
38 RADAR 5 SEP 14248 14:14:44 PIT 1
39 RADAR 5 SEP 14248 14:20:37 RDU 1
40 RADAR 5 SEP 14248 14:15:21 SDF 1
41 RADAR 5 SEP 14248 14:20:01 SJU 1
42 RADAR 5 SEP 14248 14:19:10 SLC 1
43 RADAR 5 SEP 14248 14:19:12 STL 1
44 RADAR 5 SEP 14248 14:19:15 TPA 1
45 RADAR 5 SEP 14248 14:20:28 TUL 1
imglist.k: done
A quick review of my notes confirms that there should be 45 stations
reporting TDWR products, so the list above suggests that all of the
products being reported are formatted according to specifications in
the TDWR ICD (Interface Control Document).
Please let us know if there is anything we can do to help you
refine your processing procedures to better process the TDWR
products.
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: YUL-837325
Department: Support Datastream
Priority: Normal
Status: Closed
