>From: alan anderson <address@hidden> >Organization: St. Cloud State >Keywords: 200102202133.f1KLXZL10511 McIDAS NEXRAD display Alan, >Okay, Tom; one last push Ready. >I/we must be close, but I am stalled. I have done the following, all on >waldo, as user mcidas > >1. created, on waldo, /NCDC/RADAR/KMPX/NTP changed ownership to mcidas > (can't see that the KMPX as different from your MPX should matter) The only difference should be in how you setup the configuration file. > moved a couple of files, KMPX2000..... to that location OK. >2. copied NNEXRAD.CFG to NCDCNEXR.CFG and edited last 3 lines. > I think I edited as you directed, but may have misinterpreted > I did look at the examples in the original file. > I tried a couple of different variations, but end results were the same If you put just what I said previously, then the setup will not work since your directory structure is subtly different. If you are putting the Storm Total Precip. products for MPX in /NCDC/RADAR/KMPX/NTP, then the DIRMASK= entry in NCDCNEXR.CFG will need to be: DIRMASK=/NCDC/RADAR/K\ID/\TYPE See below for more... >3. Ran DSSERVE ADD as you instructed in your message of this morning; no > error msg. Did this each time I changed the CFG file in 2. OK. >4. DATALOC shows I have a dataset RTNEXRAD on Local Data, > tried IMGDISP as IMGDISP NCDCNEXR/NTP ID=MPX (also with times) > but no display. I will assume that this is due to the difference in your directory setup and the configuration file DIRMASK= mask. >5. Went back to your email of Friday, and copied DSSERVE.BAT to NCDCNEXR.BAT, > then edited to just a 1 line file reading > > DSSERVE ADD NCDCNEXR/NTP NEXR 1 9999 ..... as listed in >DSSERVE.BAT for the NTP line > > Ran Batch NCDCNEXR.BAT ran ok This should end up being the exact same DSSERVE line as I sent in my previous email. > Ran DATALOC ADD NCDCNEXR waldo.stcloudstate.edu ok The only difference in doing this is that now the requests go through the remote ADDE interface, not the LOCAL-DATA one. For the user 'mcidas' this will be more-or-less identical. >6. Now, I have the same dataset defined in 2 different ways, but IMGDISP >still fails. OK, see below. >7. Also, tried IMGLIST NCDCNEXR/NTP ID=MPX (also tried KMPX and all) but >cannot get it to list the files. > >So, there is a snag someplace. I see where the DSSERVE ADD tells it to >read the CFG file, >where the instructions are found as to where the data set is, and how it is >named, but >can't see where I messed up. >In the .CFG file? I took the liberty of logging on and correcting the DIRMASK entry in your ~mcidas/workdata/NCDCNEXR.CFG file. It now reads: DIRMASK=/NCDC/RADAR/K\ID/\TYPE >In use of IMGDISP ? No, this was correct. >Wrong command for display? Nope. >Can you show me the error of my ways? Hopefully :o) >do I need a REDIRECT entry for this ? No, the DIRMASK= entry tells the server where to find the files; the FILEMASK= entry tells the server how the files are named; and the IPMASK= entry tells the server who is allowed access to the data. These are now all setup correctly. Since I could not get a listing of the files you put in /NCDC/RADAR/MPX/NTP, I decided to invoke IMGDISP with server tracing turned on: <on waldo as 'mcidas'> cd workdata rm -f ~mcidas/mcidas/data/trce imglist.k NCDCNEXR/NTP ID=MPX TRACE=1 This tells the server to log information in the file ~mcidas/mcidas/data/trce. The contents of the trce file shows: cat ~/mcidas/data/trce Image file directory listing for:NCDCNEXR/NTP imglist.k: There are no images that meet the selection criteria imglist.k: done /home/mcidas/workdata% cat ~/mcidas/data/trce ADIRSERV 1:NCDCNEXR NTP 0 0 AUX=YES TRACE=1 ID=MPX BAND=ALL X ADIRSERV 1:MASK is ADIRSERV 1:NCDCNEXR NTP 0 0 AUX=YES TRACE=1 ID=MPX BAND=ALL X "NCDCNEXR.CFG nexradir: |NCDCNEXR NTP 0 0 AUX=YES TRACE=1 ID=MPX BAND=ALL X "NCDCNEXR.CFG| nexradir:: starting up nexradir:: dataset descriptor: NTP nexradir:: configuration file name: NCDCNEXR.CFG GetConfigInfo:: INFO= specified nexradir:: data directory: /NCDC/RADAR/K\ID/\TYPE nexradir:: file name mask: K\ID*.* nexradir:: info file name: nexradir:: allowed IP mask: * AllowedAccess:: IP mask does not restrict access nexradir:: bpos = 0 epos = 0 nexradir:: btim = -1 etim = -1 nexradir:: bday = -1 eday = -1 nexradir:: bss = -1 ess = -1 nexradir:: cblock = nexradir:: cid = MPX /NCDC/RADAR/K\ID/NTP/K\ID*.* /NCDC/RADAR/KMPX/NTP/K\ID*.* /NCDC/RADAR/KMPX/NTP/KMPX*.* GetFileList:: file directory matching mask: /NCDC/RADAR/KMPX/NTP/KMPX*.* GetFileList:: matching pattern list length: 2 GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1017_00.580 GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1121_00.580 ReadNexrInfo:: file: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1017_00.580 ReadNexrInfo:: 512 bytes to read from NEXRAD file ReadNexrInfo:: 0 header bytes in file type 0 request ID: MPX image ID: ÿ ReadNexrInfo:: file: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1121_00.580 ReadNexrInfo:: 512 bytes to read from NEXRAD file ReadNexrInfo:: 0 header bytes in file type 0 request ID: MPX image ID: ÿ SelectNexrImages:: relative file positions There are no images that meet the selection criteria So, the things we can learn from this listing are the following: 1) the configuration file is setup to correctly locate and name the data files. We know this because the files are found (reference the lines that look like: GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1017_00.580 GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1121_00.580 These are the two files that you put in the /NCDC/RADAR/KMPX/NTP directory. So far so good. 2) The server tries to determine exactly what kind of a NIDS file this is: ReadNexrInfo:: 0 header bytes in file type 0 This is saying that the file is _not_ a zlib-compressed NEXRAD Level III image product. Rather, its header makes it look like it _might_ be a WSI NIDS product. Since the last observation did not make sense to me, I FTPed one of the files back here to Unidata and took a close look at it. The end of an output for KMPX20000416_1017_00.580 LWU LIST KMPX20000416_1017_00.580 (You could do this on waldo also.) shows what is going on: 3450. 538981424 808333360 HEX: 20203430 302E3030 ASCII: 40 0.00 3452. 541936928 538976288 HEX: 204D4D20 20202020 ASCII: MM 3454. 538968144 1296649760 HEX: 20200050 4D494E20 ASCII: P MIN 3456. 1213353049 541540679 HEX: 48524C59 20474147 ASCII: HRLY GAG 3458. 1159745362 542261572 HEX: 45204F52 20524144 ASCII: E OR RAD 3460. 1095901249 1128486221 HEX: 41522041 4343554D ASCII: AR A CCUM 3462. 773869125 1162102084 HEX: 2E204E45 45444544 ASCII: . NE EDED 3464. 541478738 541215041 HEX: 20464F52 20424941 ASCII: FOR BIA 3466. 1394623297 1279481164 HEX: 53204341 4C43554C ASCII: S CA LCUL 3468. 1096042831 1311649326 HEX: 4154494F 4E2E2E2E ASCII: ATIO N... 3470. 538976288 538980398 HEX: 20202020 2020302E ASCII: 0. 3472. 909123661 1293951008 HEX: 3630204D 4D202020 ASCII: 60 M M 3474. 538976288 -32640 HEX: 20202020 FFFF8080 ASCII: This file is not a NEXRAD image file at all! Instead, it appears to be the digital precipitation array product. Since this product is not an image, I never tried to support it with my ADDE NEXRAD image server. So, the question now is whether or not the student grabbed the incorrect data file, or whether the student actually wants the digital precip. array for his/her work? Tom
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.