<div dir="ltr">Dave B,<div><br></div><div>Thanks for the explanation. It is good to know a fix is in the works. Some time if you have a chance to fix the remaining AreaFill issue, it would be good because my team makes lots of regional plots where the viewport is smaller than that data grid.</div><div><br></div><div>--Dave A.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 31, 2015 at 10:19 AM, David Brown <span dir="ltr"><<a href="mailto:dbrown@ucar.edu" target="_blank">dbrown@ucar.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There was a check-in on 2015-06-24 that addressed this problem with<br>
this explanatory text:<br>
<br>
r16255 | dbrown | 2015-06-24 17:02:16 -0600 (Wed, 24 Jun 2015) | 8 lines<br>
<br>
NCL-2236: partial fix for constant fill with AreaFill mode set<br>
<br>
This works a bit better than the original hack but it is not yet<br>
totally reliable.<br>
It may not work when the data field is bigger than the area displayed within the<br>
viewport (i.e. over a map when the view is limited using map limits<br>
rather than by<br>
sub-setting the data).<br>
<br>
======<br>
<br>
Note that the AreaFill method was not originally designed to work when<br>
there are no isolines within the visible area of the plot. The fix can<br>
still theoretically fail but it should be much better than the<br>
previous situation.<br>
-dave<br>
<br>
<br>
On Thu, Dec 31, 2015 at 9:51 AM, Rick Brownrigg <<a href="mailto:brownrig@ucar.edu">brownrig@ucar.edu</a>> wrote:<br>
> Hi Dave,<br>
><br>
> I get the same blank map running your script using 6.3.0 on yellowstone.<br>
> However, running your script unmodified using a current development snapshot<br>
> of the code, I get a correctly filled, mono-colored map (attached). So the<br>
> issue appears to have cropped up before and has been fixed -- I don't know<br>
> the details.<br>
><br>
> Do you need a binary of the development branch -- its usually quite stable?<br>
><br>
> Rick<br>
><br>
><br>
> On Wed, Dec 30, 2015 at 6:25 PM, Dave Allured - NOAA Affiliate<br>
> <<a href="mailto:dave.allured@noaa.gov">dave.allured@noaa.gov</a>> wrote:<br>
>><br>
>> NCL team,<br>
>><br>
>> I am making ordinary color filled contour maps of gridded data, with fixed<br>
>> contour levels. When all data values lie between two adjacent contour<br>
>> levels, all one color is expected. However, NCL 6.3.0 fails to color fill<br>
>> in these cases. The result is all white maps that interrupt presentation<br>
>> sequences.<br>
>><br>
>> Attached plot #1 shows color fill forced by adding an intermediate contour<br>
>> level. Plot #2 shows the problem, a blank plot when fewer contour levels<br>
>> are selected, and all one color expected.<br>
>><br>
>> Here is the script for plot #2, the non-filled map. Plot #1 results by<br>
>> changing cnLevelSpacingF to 6 instead of 12. The input file is in the third<br>
>> attachment:<br>
>><br>
>> begin<br>
>> f = addfile ("<a href="http://data.no-color.nc" rel="noreferrer" target="_blank">data.no-color.nc</a>", "r")<br>
>> dat = f->dat<br>
>> print ("Data range of full grid = " + min (dat) + ", " + max (dat))<br>
>><br>
>> wks = gsn_open_wks ("x11", "plot.test")<br>
>> res = True<br>
>> res@cnFillOn = True<br>
>> res@cnConstFEnableFill = True<br>
>><br>
>> res@cnLevelSelectionMode = "ManualLevels"<br>
>> res@cnMinLevelValF = 0<br>
>> res@cnMaxLevelValF = 24<br>
>> res@cnLevelSpacingF = 12 ; smaller generates color fill<br>
>><br>
>> res@mpMinLonF = 234 ; any boundary outside data limits<br>
>> res@mpMaxLonF = 260 ; generates color fill<br>
>> res@mpMinLatF = 31<br>
>> res@mpMaxLatF = 50<br>
>><br>
>> res@mpCenterLonF = (res@mpMinLonF + res@mpMaxLonF) / 2.0<br>
>> res@gsnAddCyclic = False<br>
>> res@mpFillOn = False<br>
>> res@mpOutlineBoundarySets = "AllBoundaries"<br>
>><br>
>> plot = gsn_csm_contour_map_ce (wks, dat, res)<br>
>> end<br>
>><br>
>> Please note that two different kinds of changes result in correct color<br>
>> fill, just not all one color which is what I need. You can decrease<br>
>> cnLevelSpacingF to some value such as 6, which generates more than one<br>
>> color. You can also change any of the map border resources (mpMinLonF etc.)<br>
>> to extend outside the data limits, resulting in missing values along the<br>
>> edges showing as blank (white) areas.<br>
>><br>
>> Both of these changes have something in common. They all result in at<br>
>> least one color variation inside the plot frame. The failure occurs when<br>
>> the entire plot frame should be one solid color with no breaks for missing<br>
>> values or contour lines.<br>
>><br>
>> Is this a bug in NCL? Is there an existing solution? Can you please<br>
>> either change NCL to prevent this kind of blanking, or else add a resource<br>
>> similar to cnConstFEnableFill, to allow users to control the blanking in<br>
>> such cases? Thanks for your consideration.<br>
>><br>
>> --Dave<br>
>><br>
>> _______________________________________________<br>
>> ncl-talk mailing list<br>
>> <a href="mailto:ncl-talk@ucar.edu">ncl-talk@ucar.edu</a><br>
>> List instructions, subscriber options, unsubscribe:<br>
>> <a href="http://mailman.ucar.edu/mailman/listinfo/ncl-talk" rel="noreferrer" target="_blank">http://mailman.ucar.edu/mailman/listinfo/ncl-talk</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> ncl-talk mailing list<br>
> <a href="mailto:ncl-talk@ucar.edu">ncl-talk@ucar.edu</a><br>
> List instructions, subscriber options, unsubscribe:<br>
> <a href="http://mailman.ucar.edu/mailman/listinfo/ncl-talk" rel="noreferrer" target="_blank">http://mailman.ucar.edu/mailman/listinfo/ncl-talk</a><br>
><br>
</blockquote></div><br></div></div>