>From: "Paul L. Sirvatka" <address@hidden> >Organization: College of DuPage >Keywords: 200102162013.f1GKD9L01250 McIDAS-X SFCCON GRDDISP Paul, >I hope skiing was good and that you are intact today! Skiing was fantastic, and I am still in one piece, so it was a good day :-) >I am getting the data thing! At least a good deal of it. Therefore many >things are good. Excellent. My view of setting up ADDE datasets is that once you do a couple, the process makes a lot of sense and is easy to do. >2 quick things... > >How do you change the dash length? RAOBCON is more of a dot than a dash >comapred to SFCCON. Hmm... Since I never notice things like this, I decided to do a series of RAOBCON and SFCCON plots: SF 1 RAOBCON Z 500 NACONF 12 DASH=ALL SF 2 SFCCON PRE NACONF 12 DASH=ALL SF 3 RAOBCON Z 500 CO DASH=ALL PRO=CONF SF 4 SFCCON T CO 12 DASH=ALL PRO=CONF As can be seen by the series of GIF (tm) images, all of the dash lengths were the same: http://www.unidata.ucar.edu/staff/tom/gifs/raobcon1.gif ... sfccon1.gif ... raobcon2.gif ... sfccon2.gif I don't doubt that the dash patterns can be the same, however, since their form is governed by the global dash pattern settings that are controlled by the GD command: GD -- Sets graphics display parameters GD INI GD width dlength gcolor glength Parameters: INI | initializes the graphics parameters to their logon values width | graphics line width in pixels; range 1-64 (def=last value set; at logon it is set to 1) dlength | pixel length of dashes in lines; range 0-64 (def=last value set; at logon it is set to 10) gcolor | graphics color level of gaps in dashed lines (def=last value set; at logon it is set to 255, transparent) glength | pixel length of gaps in dashed lines; range 0-64 (def=last value set; at logon it is set to 10) Remark: Enter GD with no parameters to list the current graphics settings. Example: GD 3 5 3 5 Sets the line width to 3 pixels; sets the length of dashes and gaps in the dashed lines to 5 pixels; sets the color of the gaps to color level 3. ---------- I have always argued that setting the dash line pattern globally is _bad_. It should be settable on an application-by-application basis. The problem with setting it globally is that the pattern set by a GD invocation remains in effect until one resets the pattern with another GD invocation. This will have unintended effects, for example, after setting the line width to more than one and then drawing something that should have a line width of 1. >Also... > >I have some problems plotting out 6min profilers. I think the data is >there...it plots out the ID's, but when I do a timeplot, it *usually* >cannot find any data, although it did for one of them. Hmm... I am wondering if this is the same sort of problem that someone reported some time ago. I found that there is a bug in the profiler decoder, proftomd, that incorrectly sets the number of stations that have been decoded in an MD file. As I recall, if one tries to plot wind profiler data for certain stations, they would never plot while other stations always plot. As I recall, the stations that had problems in the plot were those in IL. The reason for this is that they are at the end of the list of stations that are decoded. So, the fix would be to upgrade your profiler decoder to one with the corrected code. I do not have a new ldm-mcidas decoder release with this in it (it is just me, and I am totally swamped), but I can get you going if this is your problem. Please let me know. >Is there something I do not know about setting up the plots? I doubt it. >I will be more specific if need be. No, I think that you are running into the same problem. Did whoever installed the ldm-mcidas set of decoders on your machine build them from scratch, or did s/he install them from binaries? If s/he built them from source, I can stick the corrected proftomd.c source file out in the pub/ldm-mcidas directory for you to grab. The decoder would have to be rebuilt and reinstalled. If the installation there was from binaries, then I can stick an new proftomd binary for Linux 2.2.x kernels out in the pub/binary/linux_2.2.x-i686 directory. Please let me know which way to go. >Thanks! Later... 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.
