This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Jim, I see the issue now - thanks for the image. Just as an update, I've found where things appear to be going wrong in the drawing of the colorbar, and I hope to have a fix very soon. Thanks for pointing this out! Sean > Sean: > > See the attached image, which is of mean annual precipitation over > the southwest. It includes contours and color fil. The color fill is > descending. Note how, for example, in arizona, the color fill between > 10 and 15 inches is red, whereas on the color bar, red is between 5 and 10. > > Hopefully this will show you what is going on. The problem arises > if you edit the color table and specify a range that is *descending* > (e.g., 95-0) rather than *ascending* (e.g., 0-95). I'm probably the > only one in the world to think of doing that, but at the time, I didn't > realize you could invert the color table. perhaps others would try it too. > > I hope this helps. > > Jim > > > On 1/27/12 2:07 PM, Unidata IDV Support wrote: > > Greetings Jim! > > > > I've tried to reproduce the situation outlined in you support message, but > > I am just not able to do so.I may have misunderstood, but here is what I > > did. > > > > 1) I isolated two grid points in a model grid (located next to each other). > > Their values are 955.847 hPa and 962.87 hPa. > > > > 2) I set the bounds such that each grid point was contained within one > > increment. The upper bound was set to 962.9 hPa and the lower bound was set > > to 955.8 hPa, and the increment was 0.1 hPa > > > > 3) I changed the color scale and contour information to match the increment > > that contained each point (955.8 - 955.9, 962.8-962.9), and made the range > > such that the two values were on opposite ends of the scale. Also, only the > > first and last increments are set to have color (blue and red) - the middle > > of the range is set to white. > > > > 4) I switched the range from ascending to descending (from 955.8 -> 962.9 > > to 962.9 -> 955.8). Based on your report, I expected to see one of the > > colored contours to turn to white on the figure, since the contours seem to > > shift one increment on the screen (maybe this is where I am going wrong). > > > > From what I saw, everything looks ok - both colors still showed up, and > > nothing changed in the contouring shown on the image. I've attached two > > figures showing what I did. > > > > Perhaps I am misunderstanding the issue? Would you mind sending an example > > (a bundle or some screen shots?). > > > > Thanks! > > > > Sean > > > >>> I recently noticed an issue with the contour color fill legend *in > >>> situations where you specify a range that is descending (i.e., from > >>> 100-0) rather than ascending (i.e., from 0-100). If descending, the > >>> color fill in the figure is off by one increment compared to the > >>> legend. This is most easily seen if you select a color table with a > >>> small number of increments. > >>> > >>> A work around is to simply invert the color table so that you can use an > >>> ascending range, but it would be good to have this fixed so that nobody > >>> makes an unanticipated mistake. > >>> > >>> Thanks, > >>> > >>> Jim > >>> > >>> > >> Jim, > >> It does sound like a bug. > >> Thanks for information, we will fix this problem after the AMS. > >> > >> Yuan > > > > Ticket Details > > =================== > > Ticket ID: ZRQ-267528 > > Department: Support IDV > > Priority: Normal > > Status: Open > > > Ticket Details =================== Ticket ID: ZRQ-267528 Department: Support IDV Priority: Normal Status: Open