BLIPMAP FAQ

BLIPMAP FREQUENTLY ASKED QUESTIONS (with answers)

Sorted by date (not by category) so you can quickly see any additions since your last visit here. If I update any previous FAQ answers I will highlight that update in red.
Warning: A definite testiness appears in these answers if the idea of having to do additional work comes up - Dr.Jack is burnt out!


May 9, 2005: Are you interested in receiving occasional reports of the accuracy of BLIPMAP forecasts?: DrJack sez: From individual flights, no. Any single flight and any day's forecast are both subject to so many fluctuations that trying to evaluate them would not be worthwhile, especially since truly evaluating them often requires some familiarity with local topography and local weather knowledge, which I do not have. And besides I don't have the time to try to evaluate single reports from all over the US! However, I am interested in any seasonal summary which evaluates how you feel the BLIPMAP predictions did in comparison to actual conditions, since over a season much of the "noise" should average out and leave more "signal" to be evaluated. This should be done by a post to the Blipmap Forum so that other pilots will also benefit.


April 6, 2004: I see you've described in the July 23, 2003 FAQ how BLIPMAPs can be displayed in a format of my choosing by creating a local HTML page and viewing that instead of the website pages. But that describes only a single static page - can the javascript viewer also be run locally so I can alter it to suit my needs?: DrJack sez: Yes, you can create your own local javascript viewer and alter its image size, default settings, etc. However, this does take a bit more work than setting up a static HTML page. There are instructions for creating a "local" viewer in the viewer file itself - look for the "TO USE THIS VIEWER ON A LOCAL PC" section.


April 5, 2004: When trying to look at yesterday's NAM blipmaps, I found that the "previous day" link displayed a map with today's date! What is happening?: DrJack sez: This is evidence that the processing program has not run normally! At the program's daily startup, it must "age" all the existing forecast files such that existing "current day" forecasts become "previous day" forecasts - new "current day" files will then be written as the processing proceeds. And for the NAM model additional forecast days are also aged, e.g. "current+1" forecasts become "current" forecasts, etc (though all but the "previous day" files will get overwritten as the processing proceeds and newer forecasts are produced). However, on occasion "stuff happens" and the program can get started twice in a single day - at the second start the aging will overwrite what should be a "previous day" file with a "current day" file and this is what occurred in the case you describe. If there happened to be multiple starts then the "previous day" file could even have a date which is ahead of the true current day!. Of course, this is another reason why the date at the top of a forecast should always be checked! With time the I expect to find and eliminate more bugs and the number of such occurrences will diminish. BTW, often (actually too often) I have to manually stop a job when I see it is malfunctioning - I then try to fix the problem and re-start the job as quickly as I can so that the processing can continue for that day; but I avoid the aging problems described above by using a special command which omits the aging, since it has already been done for the day.


March 26, 2004: On other weather sites I have seen "streamline" depictions where lines are drawn parallel to the wind. When the lines come together, is that the same as "convergence"?: DrJack sez: What you are looking at is termed confluence and is not the same as convergence. Convergence does tend to occur where there is confluence, but they are really different animals. In fact, it is possible to have a confluent flow which has no convergence at all and thus no vertical motion! When one sees streamlines coming together one imagines the air will be "squeezed" together and forced upward due to the need for mass conservation - and that will indeed tend to occur. But the wind also tends to speed up in such a region and that by itself tends to satisfy mass continuity and thus reduce the amount of upward motion. It is possible for the speed up to exactly compensate for the confluence and so there need be no vertical motion at all (and no convergence). And in certain cases there can be downward motion in a confluent region - for example, when air must flow through a narrow gap in a ridgeline. Still, it is more common to have some upward motion (and thus convergence) in a confluence, but its strength depends upon how strongly the atmosphere resists vertical motion at that location, which varies with temperature structure, etc. and so can only be truly determined from the full equations of motion (though there are some programs which use simple mass-conserving schemes to approximate wind flow). So while a streamline presentation is useful, the magnitude of convergence can only really be determined from the "convergence" BLIPMAP (BL max up/down motion).
A streamline presentation is good for for showing wind direction but not for wind speed. My "ideal" wind presentation would be one that overlays colored windspeed regions on top of streamlines. I'd like to have a BLIPMAP depicting that but at present my plotting routine input is convoluted (it is based on the program I used for my research work) and can only display a single variable - so to implement my ideal I would need to do major work on the plotting routine and that's not going to happen for awhile. If/when I do get a streamline presentation into BLIPMAPs, you will likely find it interesting to compare that to the convergence prediction.


March 1, 2004: I am partially color-blind and am unable to distinguish between some tints. Do you have any suggestions which could help me ?: DrJack sez: The alternative BLIP data display programs allow users to alter the colors used to display BLIPMAP parameters, which should be useful to you. And the BMapper program desribed there also displays the parameters as text (numbers) so no color-discerning ability is required. Another option is to use the "miniBLIPSPOT" popup in the viewer, which displays values at a given location in text. Also see the FAQ of Aug 18, 2002 for additional discussion of color tints.


Feb 12, 2004: I'm having a problem getting the current map when I click on a "Latest" links page. However, the the javascript viewer does give me the latest map. What's going on ?: DrJack sez: This is very likely a cache problem, i.e some cache is supplying its saved (and now outdated) version of the webpage you requested instead of the current on-line version. There are two possible cache sources: your browser has an internal cache and some Internet providers (notably AOL) use servers with their own caches. Some solutions are:
(1) Empty your browser's internal cache (the specific procedure depends upon which browser you use)
(2) Close and re-open your browser (which destroys your browser cache)
(3) AOL browsers have user options which control the AOL caching behavior


Jan 6, 2004: I know that the NAM model forecasts out to a longer time than the RAP and that the RAP is updated more frequently, but what differences exist in the models themselves? Which should give the better forecasts?: DrJack sez: They are very similar in that they both solve the fundamental meteorological equations as described in the How Does a Meteorological Model Work ? webpage, but in detail their differences abound (these differences are what meteorologists study and argue and write papers about!). I have developed a separate webpage at to discuss those differences, the NAM vs RAP comparison webpage.


Sept 23, 2003: I find that the soundings on the FSL sounding forecast webpage often do not agree with the BLIPSPOT data. I thought that BLIPSPOTs were based on the FSL RAP forecasts?: DrJack sez: Both the BLIPs and the FSL sounding webpage do use data from the same model, but BLIPs will often differ from the data plotted/output by the FSL sounding webpage because that data has been degraded in two ways. First, the FSL webpage soundings are only available for a 40km-spaced subsample of the full 20km-resolution grid - so there is a 75% probability that any profile viewed is not at the exact location used by a BLIPSPOT (or a grid point used for the BLIPMAP contours). For example, when trying to view the sounding corresponding to the Hendersonville NC BLIPSPOT, using the link on the BLIPSPOT page, you will see that the line immediately above the plot reads "15.2nm/50° from 35.432,-82.419", where the last lat/long is that of the actual 20km grid point used for the BLIPSPOT. Where there is significant terrain or meteorological variation between grid points this can produce plotted soundings which significantly differ from the actual forecast soundings at the 20km grid point. In contrast, the BLIP program uses the exact "native-grid" forecasts at each 20km gridpoint. (BTW I only recently found about these factors - previously I had been assuming that the FSL sounding webpage used the actual model forecasts at each 20km grid point and would thus agree with the BLIPSPOTs.)


July 23, 2003: One usability enhancement for me would be to cluster several related BLIPMAPs on one page in a multi-image view, for instance, Thermal Strength, Thermal Height, and B/S Ratio.: DrJack sez: You can create a multi-image HTML page yourself on your local PC to display whatever set of images you wish, such as different times or models side-by-side, and view that using your browser! And you can alter it to suit your needs by changing the forecast parameter, forecast time, image size, etc. While this does take some knowledge of HTML markup tags, those are pretty simple and in fact can often be understood simply by looking at an example and "monkey-see, monkey-do"ing.
For example, I have created a multi-image sample html page (which displays three rows of images with two images on each row). You can use that example as a basis for creating your local page by downloading that file (using your browser tools) to your local computer. If you have a valid registration cookie that page should work as it stands - but it also includes a provision for cookie-less access, which you can enable by using a text editor to edit its internal YOURID and YOURPW to be your ID and PW (duh). To view that page you use its local URL address or create a bookmark containing it - for example, for a Windows-system the needed URL will look something like
file://C:\mylocalpath/sample.multiimage.html
and for a Unix-system it will look something like
file:///home/mylocalpath/sample.multiimage.html
(note use of "file" at the beginning instead of "http"!). To then alter the choice of images you must text edit the forecast URL addresses in that file to point to the model, region, time, and parameters you are interested in. To determine the address needed for different parameters, note the browser URL address when viewing that parameter's BLIPMAP on the DrJack website. Simple modifications such as fewer/more images are easily made. Also note that example provides both a "simple" example of side-by-side maps and a "complex" example using html tables - the advantage of the latter is that the maps will be side-by-side regardless of the width of the browser page, whereas the former requires that the browser page be wide enough to accommodate both maps.
Another example, which illustrates the use of altered image width and height specifcations to shrink the image size, is the local webpage created by Todd Herzog. Note that this example does not include any userid or password information in the file - so for it to work you will need to have a valid registration cookie on your computer.
Creating and using a local file allows you to be as creative as you want. To create more elaborate pages some basic knowledge of HTML formatting is required - Dave Raggett's Basic HTML webpage gives some fundamentals and his Advanced HTML webpage gives information on using "tables" if you wish to force images to be side-by-side. Finally, general information on the different HTML commands, illustrating the many things that can be altered using html markups, are given on the Bare Bones Guide to HTML webpage


June 23, 2003: Yesterday the SFC LCL map had no "5" on it's color scale, jumping from "4" to "6".: DrJack sez: This is not really an "error", but can occur when spacing between colors is not an exact integer value (which only occurs for certain parameters, namely those which can vary widely and so do not have a fixed contour increment but instead one which varies depending on the min/max data values on the actual plot). What is happening is that "rounded" integer values are being printed, not the exact values, so on occasion there will be either duplicate printed numbers (e.g. the actual sequence "0.2 0.8 1.4 2.0" will be printed as "0 1 1 2") or with apparent "skips" as in your case. The reason for integer printing is that sometimes large values have to be printed and they would overlap if an additional two characters (the decimal place and the following number) were also printed. Since relative values are what is of primary import, not absolute values, and since any prediction is only approximate, I consider this an annoyance not a true "problem". And even though I personally find this irritating when I see it occurring, so far I have not been able to motivate myself to fix it since doing so properly, by making the program smarter given the variety of contour spacings it has to treat, would take a significant amount of work (Also see the FAQ for Apr 29, which explains a lot of the existing program deficiencies these days.)


June 16, 2003: Can you include a map with the trigger temperature across the region?: DrJack sez: I'd best start off by pointing out that there is no such thing as "the" trigger temperature. A "trigger temperature" is a concept used in "Thermal Index" (TI) forecasting to indicate the surface temperature when the top of the convection is expected to reach a certain height, so its numerical value depends upon both (1) how the "top" of the convection is defined and (2) the specific height chosen for that top. I have seen various assumptions for both (1) and (2) from different sources and the choices made determines the value that is predicted. For example, the NWS uses a "trigger temperature" which assumes that (1) the top of the convection occurs at the TI=0 height and (2) the convection height varies with surface elevation, being 3000 ft for surfaces below 2000 ftMSL and 4000 ft for higher ones. Alternatively, Kevin Ford has felt that TI=0 (which in BLIP parlance equals the BL top) occurs above the height that thermals can reach so his trigger temperature is based on the top of the usable convection occurring at TI =-3 degC; and he does not try to choose a single "convection height", but instead computes a trigger temperature for different heights in 500 ft increments. The main point I am making is that if someone tells you that the "trigger temperature" is X degrees, you should at least know the specific height that convection is then supposed to reach to know the practical importance of that trigger temperature.
I wanted to first go through the above because many people have a hazy notion of what a "trigger temperature" is supposed to be - they mainly know that something magically good is supposed to happen when the surface temperature reaches that value and so eagerly wait for it to occur before launching.
The point I now need to make is that the trigger temperature is expected to occur at a single time, and is not expected to vary during the day. And thus trigger temperature is a different animal from the BLIPMAP parameters, which are assumed to be atmospheric variables which will vary at each time of the day, with BLIPMAP indicating what they are at each time. So the "trigger temperature" concept per se really doesn't fit into the BLIPMAP processing scheme.
But information akin to the trigger temperature can be obtained if you have a BLIPSPOT at your location, since it provides both the predicted surface temperature and thermalling height (either Hcrit or BLtop, as appropriate) at a series of times. You can decide on a thermalling height to use as your criterion, and then estimate the time that will be reached by interpolating between the provided times. Or you can use the surface temperature information as a "how goes it", seeing whether the forecast is tracking with actual values and mentally adjusting the predictions if they are not.


May 2, 2003: I flew on day X but was not able to save the BLIPMAPs for that day - are there archived plots I can access?: DrJack sez: I presently archive the "final" BLIPMAP produced for each day and time and parameter, but in the form of a "data" file containing the numerical values at each grid point, not as a BLIPMAP image. This is done because (1) the storage space needed is one-tenth that which saving images would require (with so many plots being produced every day that is a concern), and (2) saving the numbers allows possible later re-analyses of that day, which could not be done from images. A downside is that providing an "old" BLIPMAP then requires a re-plotting of that data. I have had requests from individuals that I provide them with "old" BLIPMAPs - but since the archived files reside on the processing machine, not my personal computer, such would involve first accessing the data and downloading it to my machine, then running a plotting program, and finally sending the result along. This would involve a considerable amount of time, which I am not willing to spend (though I will do it if I have a personal interest in that day or if a large group of people would benefit). There have been suggestions that it would be "nice" to have a webpage that a user could use to display "old" BLIPMAPs and I agree, so I have listed that on my To-Do List as something that "should" be done. But that is a very low priority for me since it would essentially be just for other people's benefit, not mine. The "To-Do" List notes that for that item I am seeking a volunteer to take care of its HTML aspects, which involves creating the HTML page needed for user selection of the day/time/parameter desired (form request) and for a framed display of the subsequent image (similar to the present javascript viewer, though this would be much simpler). Many others are capable of creating such a page, it is not something only I can do, so my thinking is that the "archival plot" feature will have to wait until that volunteer steps forward (whereupon I would provide the plotting program &etc used by that webpage, since only I can do that). But so far no volunteer has appeared. So at present I can only say that users are responsible for saving any desired BLIPMAP images prior to the time that they are "aged" from the "previous day" plot link.


Apr 29, 2003: Why don't you do X to improve the BLIPMAP forecasts?: DrJack sez: (This is re-written from a reply to a post on the DrJack Forum, as I thought it would be of general interest) The above is a generic request typifying many I have received over the past months. Over-simplifying, many boil down to "why don't you spend time doing X so that using the BLIPMAPs will be easier and I will have to do less work". At present I am having to spend more time that I want just to keep the present forecasts going, so I am not very receptive to such requests, though they are understandable and sometimes suggest improvements which I myself would like to have made. For the same reason the BLIP forecasts are now largely frozen with respect to development of the computer program itself, with my time instead being spent building needed infrastructure such as better descriptions, a forum where questions can be asked, etc. At present I am making only those program changes which I feel are very important, such as a correction to a program error. Simply providing the forecasts in a more convenient manner does not fall into that category. Indeed the list of things that I feel could be "improved" is horrendously long. Thoughts and conceptualizations and wishes are all easy - I do much of that myself. But I also know how much work would be required to actually implement those thoughts (far, far more than most people realize). At present, even though I am doing less work than I did over the last year I still feel burnt out and over-worked, and my enjoyment of life will be improved if I do less BLIP work not more.


Mar 17, 2003: I am looking for some useful forecasts for wave soaring: DrJack sez: "Real" mt. wave forecasting (by which I mean using the dynamic equations of motion) requires resolving the wave and so resolutions of 1 km or less. There was a dynamic prediction of hydrostatic wave available from NRL-DC at http://uap-www.nrl.navy.mil/dynamics/html/mwfmusa.html but that is no longer operational due to funding problems. {Their resolution really predicted "hydrostatic" wave, not the "non-hydrostatic" mt. waves we fly - yet since their formation requires many of the same conditions as non-hydrostatic mt. waves so these forecasts were still useful.]
There are also "linear" forecasts which can predict non-hydrostatic wave, but do omit some important effects, available for the CA-NV region at http://www.drjack.info/WINDIP/ and for other regions from NRL-MRY at http://www.nrlmry.navy.mil/~doyle/linear_model/linear.html But those are available only for a few very specific areas.
And there are some "turbulence" forecasts. Turbulence often occurs in connection with wave (although the wave itself is non-turbulent), but turbulence is also caused by other phenomena such as jet stream cores so these are not truly a "wave" forecasts. Nevertheless some may find them useful, so links to them are ADDS turbulence forecasts and NCAR RAPS Integrated Turbulence Forecast Algorithm.
Some raob analysis software programs claim to have a "wave prediction" module, but I do not know enough about what they do to evaluate them.
Finally, for some CA-NV locations I am presently producing a daily "upper-wind" forecast, which is simply a compilation of model results available on the web but which does include a simple "empirical" wave predictor based on wind speeds (see http://www.drjack.info/WINDIP/ ). I might extend that to other locations some day but can't get too excited about the idea since the wave formulation has not been proven for non-Sierra mountains and since in any case the mt. wave prediction is crude and omits stability effects which also affect wave formation. The main advantage of what I have done is allowing predictions from multiple models to be compared for forecasts many days ahead of a possible wave event (this also has the educational value of being an eye-opener to those who do not realize how sensitive weather predictions can be to small differences and to those who tend to take results from a single weather prediction model as gospel). In a slightly modified form this forecasting program might also be used to predict ridge soaring conditions, since they primarily depend upon the wind component perpendicular to the ridge.


Mar 13, 2003: I live near a blipmap regional edge - would it be possible to make the blipmap regions larger, with more overlap, so that I would not have to look at two different regions?: DrJack sez: At this point I am pretty much locked into the existing grids in a number of ways. The processing must done separately for each region (doing the entire US all at once would require more memory than is available) and the amount of processing goes up rapidly with increasing size - for example just a 10% in each grid size would increase the required processing by 20%, all of which would be merely duplicated processing. Right now all I can suggest is to put two browser windows side-by-side and view one region in each.
March 1, 2004 Addition: You can also utilize the programs described in the alternative BLIP data display programs since they can allow the user to display an arbitrary region.


Feb 11, 2003: Is there a way to estimate how much BL height difference a change in surface elevation will produce?: DrJack sez: I have a theoretical way of estimating the effect of surface elevation differences, but it is as yet untested. Assuming a mt. peak lies within a BLIPMAP grid point, a simple way of estimating the BL top _increase_ there would be to multiply the difference in altitude between the peak and the model grid elevation in feet by 0.00033 degF/ft and then multiply that by the TI height variability in feet divided by 4 degF. Not exactly the same as would be obtained by a BLIPMAP prediction, but should be in the ballpark.


Feb 2, 2003: How long has it taken to develop these soaring predictions? What's the history?: DrJack sez: My first automated soaring prediction was made back in 2000, when I created a "TIP" (Thermal Index Prediction) which essentially automated use of Kevin Ford's Thermal Index prediction site by automatically obtaining the required maximum temperature from our local NWS website and emailing the resulting predictions to glider pilots flying out of Hollister (CA). However, the Ford site was often down so I later decided to gather the needed radiosonde data myself and do the TI calculation locally. But after gaining access to the soundings, I realized that additional forecasts could be provided from that data, leading to augmented TIPs which were incrementally improved with additional features such as W* forecasts and two day forecasts. However, I was always very aware of the limitations of the TIP since it was based on forecasts for a single location and conditions change rapidly inland from Hollister. So, being unable to fly during 2001, I was motivated to create the BLIPMAPs to provide forecasts over a large region and in graphical format, though it involved considerably more programming than that required for the TIPs and also required developing a website through which they could be accessed. The first BLIPMAP appeared in May 2001 for the CA/NV region and that product was changed and improved during the 2001 soaring season and additional products such as the javascript viewer were also created - so CA/NV users are more aware of the incremental BLIPMAP development than are those in other regions. During this period the TIPs were also maintained and expanded to other locations. The successful adoption of the CA/NV forecasts by soaring pilots there led to expansion to other US regions in March 2002, with some improvements being added during that summer but most work being for ancillary improvements or changes (including movement to a new website and a new processing machine) and not to the BLIPMAP program itself. The amount of my time spent is difficult to assess since it occurred piecemeal in almost daily segments over a very long period and no records were kept, but my best estimate is that the entire TIP development effort totaled about 8 man-months and the BLIPMAP program and website development has certainly taken well over a man-year of effort to date.


Nov 22, 2002: Why don't you plot the wind speed and direction as wind barbs (vectors)? I find those easier to interpret.: DrJack sez: A major reason is that that would mean a lot of additional work and multiple changes to adapt to a completely different presentation, since it requires utilizing two different variables in my plotting software and at present it cannot handle that.
Having said that, I personally rather like the present presentation since I find it readily indicates locations where sharp changes in wind direction can be expected. But I acknowledge that it is a bit of a hassle to have to look at the color map to figure out the direction (and there is the unavoidable gradient at the 360 to 0 wraparound, though I think one quickly becomes accustomed to that). (If I am ever able to modify my software, my first choice of a presentation would be to overlay pseudo-streamlines indicating wind direction and colors indicating windspeed.)
Also, to see wind barb plots for surface winds, you can visit FSL's RAP forecasts - that page provides nationwide plots, but provides links to regional plots.

Sept 15, 2002: Why don't you plot the actual terrain instead of smoothed terrain contours?: DrJack sez: As mentioned in the Description (of course you did read the Description), this is a feature: since the model predictions are based on the smoothed terrain, knowledge of that terrain is necessary for correct interpretation of the predictions. The model cannot forecast conditions which it knows nothing about, so some degree of sophistication is required to recognize that fact and use the model predictions appropriately, not blindly. For instance, the Pine Nuts Mt ridge just east of Minden is regularly used as a first jumping off spot for local pilots. But the smoothed RAP model topography knows nothing about that mt ridge because it is just too narrow, so it essentially produces a "level terrain" prediction there. A pilot flying in that region must expect that the soaring heights achieved over the actual ridge will be much higher than predicted by the model using its smoothed topography.
This question also relates to the "fuzziness" of locations on the plot, as described in the answer to the question immediately below.

Sept 1, 2002: Would it be possible to put cities, highways, or airport IDs on the bitmaps? I spend quite a bit of time putting a layer on them, well maybe not that much as I have figured out the geography pretty well. However, I believe it would increase the usability for neophytes.: DrJack sez: Others have asked a similar question. DrJack has been resisting the idea because (1) they would garbage up the BLIPMAPs and make the colors/contours more difficult to read, (2) it would take a fair amount of work, (3) DrJack does not need them himself, and (4) a certain amount of ambiguity in the geographic location is actually desirable. I should expand on the latter, since in a model with smoothed topography there is a prediction location "fuzziness" introduced by that smoothing which needs to be recognized by pilots are used thinking of a specific lat/long being associated with a real-world surface elevation. Because the atmosphere varies much more rapidly in the vertical than in the horizontal, the model prediction which "best" fits a given real-world location may not necessarily be exactly at the model lat/long identical to the real-world lat/long but rather at some nearby location where the model surface elevation more closely agrees with the surface elevation of the real-world location. This "fuzziness" is negligible for relatively flat regions but can be significant where there is a rapid change in topography height. This "fuzziness" is reduced when topography resolution is increased, as in the NAM model, but will always be there to some extent. Thus one must be a bit cautious when examining weather predictions at some exact lat/long, and this is the reason why smoothed model terrain contours, not real-world terrain contours, are displayed on the BLIPMAPs. (And why my "point" BLIP predictions sometimes utilize a grid point which is not the grid point nearest the actual real-world lat/long of the point of interest.)
However, I have gotten enough requests similar to yours that I have now provided a separate map with airport ID locations displayed on in (not putting such locations on every BLIPMAP, which would make a mess). Noting the locations relative to the plotted terrain contours on that map will allow transposition to the actual forecast BLIPMAPs. Cities and highways cannot be portrayed because the plotting software does not have that capability - but the software can plot text labels so I can plot 3 letter airport IDs. I estimate it will require around 16 hours of work to alter my plotting program, since it is not presently setup to plot labels and it have to be taught to convert lat/long -> model coordinates -> regional plot coordinates. Additional work will be required to decide which airports to include/exclude since not all could be depicted.
UPDATE: Site location identifiers can now be plotted for all regions - see the help page for further information.
March 1, 2004 Addition: You can also utilize one of the alternative BLIP data display programs to overlay BLIP data onto maps such as those produced by SeeYou or Delorme, which do include geographic information such as cities, roads, etc.

July 13, 2007: Why are there lat/lon lines on the "composite" maps but not on the others?: DrJack sez: The "composite" plots use a different plotting package from the non-composite plots - the latter was the original package used but has many limitations including the inability to plot lat/lon lines (and to create composite images!).

Aug 18, 2002: At least on my computer, the colors differentiating the various heights, speeds, etc do not seem distinctive enough. That is, without starting from the sea and moving inland, I cannot be sure whether I am looking at a 15,000 or a 5,000 foot day.: DrJack sez: There is a problem with getting distinguishable tints since the (maximum) number of required tints is 22. In addition there are color display differences between different monitors! (and for that matter people differ in their color discrimination ability - and even color blindness is not consistent) I myself have problems telling two of the green tints apart, especially if the area covered is small. My initial maps only went through the color wheel once and distinguishing between adjacent tints was then often impossible, hence the change to the present two passes through the color wheel - this helps by dividing the colors into "light" and "intense" tint groups. The only suggestions I can give are: (1) recognize that the "light" tints and "intense" tints will be grouped together (e.g. it would be impossible for a BL top of 15,000 ft to be between BL top regions of 4,000 and 6,000 ft) (2) make sure your computer is configured to use the maximum number of colors that its monitor is capable of displaying: "24 bit" color ("true color") is better than "18 bit" which is better than "8 bit" (256 colors), and (3) use a screen magnifier, as mentioned on the index page, to enlarge small areas. But there is always going to be a conflict between the desire to display contour steps small enough to be useful, arguing for more colors, and the desire to have the different colors be distinguishable, arguing for fewer colors.
March 1, 2004 Addition: You can also utilize one of the alternative BLIP data display programs which allows the user to choose for himself the colors used for plotting.
Nov 15, 2005 Addition: As found by Bob Janney, some ISPs offer an "accelerator" feature which works by degrading images to make them smaller. If you choose to utilize that, the tints displayed will be more difficult, especially for larger "accelerations".

June 3, 2002: Do you anticipate one day increasing the present map scale to make determination of values easier at a point?: DrJack sez: The coarseness of the present grid cells would not make that meaningful. For the present 20km grid cells there are 9 pixels per grid cell side (so 81 pixels over the grid cell area), which is adequately resolved by most people's eye. This granularity is masked because the plots are rendered using color contouring but is nonetheless there - the granularity would be more obvious if each grid cell were plotted in a solid color (which I actually did for my very first plots, but it was difficult to distinguish between some hues due to the lack of a definite color progression so the present contouring scheme was adopted instead.) If you really wish, magnification is possible using one of the magnifiers mentioned in the Description. If the finer resolution (12 km) NAM model results were to be displayed then likely the maps would be made larger, with grid cells still covering a 81 pixel area but that would now represent a smaller distance.
March 1, 2004 Addition: The NAM model utilizes a much finer grid, so I have made their BLIPMAP plots larger to allow better screen resolution.

April 24, 2002: Would it possible to use the same colors for the same value everyday? For example, at least here in the NW, there is appears to be no need for Thermal updraft scales besides a 0-10 knot scale. If we see a day with 10 knot indications, we're going!: DrJack sez: I agree that often it would be nice to have the same colors for the same number range for comparison purposes. But this question is not as simple as might first appear, since (1) trying to use such implies that one knows the applicable "universal" min/max limits which apply, which is not true for all of the variables, (2) if one does that using the (say) yearly extremes of min/max then one may need a lot of colors to achieve a reasonable discrimination between values, resulting in having difficulty being unable to distinguish between hues that are very close in color; with an enforced min/max this occurs every day, rather than only occasionally as at present. (3) even if only done on a daily basis, rather than using yearly min/maxs, I would still have to use the same min/max for the entire country, making those regions which don't really need as wide range as other regions suffer since they would have to deal with an unnecessary (for them) closeness of hues. For example. if for all height plots I use the number of hues required out west, then differentiation of heights is going to become more difficult in the east, where fewer hues are used at present. (4) at present the plotting program cannot handle such a case and modification to both the calculation and plotting programs would be required, plus introduction of additional communication between the programs. Still, for many parameters having constant coloring could be done, e.g. for W* since it has the least difficulty with (1)-(3), so I have decided to make that change for certain variables the next time I make major alterations in the calculation and plotting codes, as would occur if I make changes necessary for the NAM-BLIPMAPs.
Update: "Fixed" color plots are now available for all parameters.