Re: gsn_add_polyline not working in 6.2.0

Hi Dave-

I understand why the change was necessary. Adding an extra point was
an easy enough fix in my case.

Don

On 4/15/14 6:00 PM, David Brown wrote:
> Hi Don,
> Actually this was an intentional change that is intended to be permanent. I'm sorry that I forgot about it; it should (and will) be listed under backwards-incompatible changes in
> the release notes. Plus it needs to be documented more fully.
>
> This change had to be made in order to eliminate ambiguity about which direction to take between 2 points on the globe. Now the rule is simple: always take the shortest path.
> If the distance is exactly 180 degrees in longitude, then go in the direction of the lowest longitude value to the highest where longitude can vary from -540 to + 540.
> Unfortunately, this means that the simple specification of a polyline with constant latitude and 0 - 360 longitude produces a 0-length line. Hopefully, adding some extra points to ensure that
> the shortest path is un-ambiguous should not be a major chore in general.
>
> Before this change, situations were arising where it was not possible (for me at least) to figure out programmatically which direction a line should take. Now it is much easier. For users as well.
> For instance, the case that arose with your colleague Cathy Smith of drawing trajectories that cross the prime meridian should now be much easier to code -- and I am pretty sure the existing more
> complicated code will continue to work as well.
>
> Apologies for not making a more prominent statement about this issue along with the release.
> -dave
>
> On Apr 15, 2014, at 10:05 AM, Don Murray <don.murray@noaa.gov> wrote:
>
>> Glad it's not me. ;-) Thanks for the workaround, I'll use that until
>> 6.2.1 comes out.
>>
>> Don
>>
>> On 4/15/14 9:56 AM, Mary Haley wrote:
>>> Hi Don,
>>>
>>> I was able to reproduce your problem and have filed a critical ticket on
>>> it (NCL-1943).
>>>
>>> The only work-around I can come up with is to draw the line in two
>>> separate pieces:
>>>
>>> equa1 = gsn_add_polyline(wks,plot,(/-180,0/),(/0,0/),resp)
>>> equa2 = gsn_add_polyline(wks,plot,(/0,180/),(/0,0/),resp)
>>>
>>> We will likely release a V6.2.1 to fix some bugs in V6.2.0, and this
>>> will be high on the list.
>>>
>>> —Mary
>>>
>>> On Apr 15, 2014, at 9:07 AM, Don Murray (NOAA Affiliate)
>>> <don.murray@noaa.gov <mailto:don.murray@noaa.gov>> wrote:
>>>
>>>> Hi-
>>>>
>>>> I have a script that has been running fine under NCL 6.1.2, but now is
>>>> not acting the same under 6.2.0. The part that isn't working is drawing
>>>> a polyline along the equator. The relevant code is:
>>>>
>>>> plot = gsn_csm_contour_map(wks,data,rescf) ; color-filled
>>>> if (.not.isanom) then
>>>> plot1 = gsn_csm_contour(wks,data,rescn) ; contours
>>>> overlay(plot,plot1)
>>>> end if
>>>> dlin = gsn_add_polyline(wks,plot,(/180,180/),(/-90,90/),resp) ; dateline
>>>> equa = gsn_add_polyline(wks,plot,(/0,360/),(/0,0/),resp) ; equator
>>>> draw(plot)
>>>> draw(lbid)
>>>> gsn_text_ndc(wks,"NOAA/ESRL/PSD",0.088,0.190,restx)
>>>> if (isanom) then
>>>> gsn_text_ndc(wks,"Base Period: "+baseDateString,0.52,0.190,restxa)
>>>> end if
>>>> frame(wks)
>>>>
>>>> In this script, a line is drawn at the dateline and the equator:
>>>>
>>>> http://www.esrl.noaa.gov/psd/map/images/sst/sst.20140316.gif
>>>>
>>>> Since upgrading to NCL 6.2.0, the equator line is missing:
>>>>
>>>> http://www.esrl.noaa.gov/psd/map/images/sst/sst.20140323.gif
>>>>
>>>> If I print out the data summary, it looks like:
>>>>
>>>> Variable: data (parameter)
>>>> Type: float
>>>> Total Size: 259200 bytes
>>>> 64800 values
>>>> Number of Dimensions: 2
>>>> Dimensions and sizes:[lat | 180] x [lon | 360]
>>>> Coordinates:
>>>> lat: [89.5..-89.5]
>>>> lon: [0.5..359.5]
>>>> Number Of Attributes: 18
>>>> time :78257
>>>> long_name :Weekly Mean of Sea Surface Temperature
>>>> unpacked_valid_range :( -5, 40 )
>>>> actual_range :( -1.8, 35.63 )
>>>> units :degC
>>>> missing_value_original :32767
>>>> precision :2
>>>> least_significant_digit :2
>>>> var_desc :Sea Surface Temperature
>>>> dataset :NOAA Optimum Interpolation (OI) SST V2
>>>> level_desc :Surface
>>>> statistic :Weekly Mean
>>>> parent_stat :Individual obs
>>>> standard_name :sea_surface_temperature
>>>> _FillValue_original :32767
>>>> _FillValue :32767
>>>> valid_range :( -5, 40 )
>>>> missing_value :32767
>>>>
>>>>
>>>> I tried adjusting the x values to be (/1,359/), but still no line across
>>>> the plot.
>>>>
>>>> Thoughts on what could be going wrong?
>>>>
>>>> Don
>>>> --
>>>> Don Murray
>>>> NOAA/ESRL/PSD and CU-CIRES
>>>> 303-497-3596
>>>> http://www.esrl.noaa.gov/psd/people/don.murray/
>>>> _______________________________________________
>>>> ncl-talk mailing list
>>>> List instructions, subscriber options, unsubscribe:
>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>
>>
>> --
>> Don Murray
>> NOAA/ESRL/PSD and CIRES
>> 303-497-3596
>> http://www.esrl.noaa.gov/psd/people/don.murray/
>> _______________________________________________
>> ncl-talk mailing list
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>

-- 
Don Murray
NOAA/ESRL/PSD and CU-CIRES
303-497-3596
http://www.esrl.noaa.gov/psd/people/don.murray/
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk