[ncl-talk] Pixel to Lat/Lon
Dennis Shea
shea at ucar.edu
Mon Jul 17 08:46:43 MDT 2017
I guess I did not attach anything to my previous post on this Subject.
=====
top] a plot of the raw data
[middle] plot from the bin_sum [avg] onto the original high res grid
[bottom] using 'poisson_grid_fill' and then using a do loop on [2] to
filter points outside the original swaths.
I do not recommend extrapolation beyond the original region. Extrapolation
is 'always' dangerous unless it is based upon physical principles.
See attached,
====
Please note using the one data file I have ... look at the max/min from the
original data and GBIN
Variable: data
Dimensions and sizes: [2383] x [51] <=== original
units : Watts/m**2
long_name : Flux_Longwave_TOA
_FillValue : 32767
(0) Flux_Longwave_TOA (Watts/m**2) : min=50 max=313.88 <=== original
=====
Variable: GBIN
Dimensions and sizes: [lat | 400] x [lon | 2400] <=== target grid
Coordinates:
lat: [-29.925..29.92501]
lon: [0.075..359.925]
Number Of Attributes: 3
units : Watts/m**2
long_name : BINNED: Flux_Longwave_TOA
_FillValue : 9.96921e+36
(0) BINNED: Flux_Longwave_TOA (Watts/m**2) : min=50 max=313.88 <===
Note
(0) GBIN: nmsg=849042 <=== large number of missing values
(0) -----
Variable: GKNT
Type: integer
Dimensions and sizes: [lat | 400] x [lon | 2400]
Coordinates:
lat: [-29.925..29.92501]
lon: [0.075..359.925]
Number Of Attributes: 2
long_name : BINNED COUNT: Flux_Longwave_TOA
_FillValue : -2147483647 <%28214%29%20748-3647>
(0) BINNED COUNT: Flux_Longwave_TOA : min=1 max=3 <=== Note
On Mon, Jul 17, 2017 at 8:44 AM, Dennis Shea <shea at ucar.edu> wrote:
>
>
> On Sun, Jul 16, 2017 at 10:54 PM, Dennis Shea <shea at ucar.edu> wrote:
>
>> The attached shows
>>
>> [top] a plot of the raw data
>> [middle] plot from the bin_sum [avg] onto the original high res grid
>> [bottom] using 'poisson_grid_fill' and then using a do loop on [2] to
>> filter points outside the original swaths.
>>
>> I do not recommend extrapolation beyond the original region.
>> Extrapolation is 'always' dangerous unless it is based upon physical
>> principles.
>>
>> See attached,
>>
>> ====
>> Please note using the one data file I have ... look at the max/min from
>> the original data and GBIN
>>
>> Variable: data
>> Dimensions and sizes: [2383] x [51] <=== original
>> units : Watts/m**2
>> long_name : Flux_Longwave_TOA
>> _FillValue : 32767
>> (0) Flux_Longwave_TOA (Watts/m**2) : min=50 max=313.88 <===
>> original
>>
>> =====
>> Variable: GBIN
>> Dimensions and sizes: [lat | 400] x [lon | 2400] <=== target grid
>> Coordinates:
>> lat: [-29.925..29.92501]
>> lon: [0.075..359.925]
>> Number Of Attributes: 3
>> units : Watts/m**2
>> long_name : BINNED: Flux_Longwave_TOA
>> _FillValue : 9.96921e+36
>> (0) BINNED: Flux_Longwave_TOA (Watts/m**2) : min=50 max=313.88
>> <=== Note
>> (0) GBIN: nmsg=849042 <=== large number of missing values
>> (0) -----
>>
>> Variable: GKNT
>> Type: integer
>> Dimensions and sizes: [lat | 400] x [lon | 2400]
>> Coordinates:
>> lat: [-29.925..29.92501]
>> lon: [0.075..359.925]
>> Number Of Attributes: 2
>> long_name : BINNED COUNT: Flux_Longwave_TOA
>> _FillValue : -2147483647 <(214)%20748-3647>
>> (0) BINNED COUNT: Flux_Longwave_TOA : min=1 max=3 <=== Note
>>
>> On Sun, Jul 16, 2017 at 12:36 PM, Ipsita Putatunda <
>> ipsita.putatunda at gmail.com> wrote:
>>
>>> Hi all,
>>> Thanks a lot for your help. But I have one more doubt. I ran the script
>>> attached by Dennis (Both without any regridding, and with bin_avg), but the
>>> maximum value of Longwave_Flux_TOA is coming more than 1200 both the cases,
>>> where as the data definition is saying the range of the value is (0 to
>>> 500). Why is it so?
>>>
>>> Thanks,
>>> Ipsita
>>>
>>> On Fri, Jul 14, 2017 at 11:12 PM, Dave Allured - NOAA Affiliate <
>>> dave.allured at noaa.gov> wrote:
>>>
>>>> Ipsita et al,
>>>>
>>>> I think you can plot this swath data directly, without regridding.
>>>> This would require conforming arrays of 2-dimensional latitudes and
>>>> longitudes. But guess what? That's what we figured out two days ago. ;-)
>>>>
>>>> If this works, I think the plot would look better and plot faster.
>>>> Sorry I did not think of this sooner.
>>>>
>>>> --Dave
>>>>
>>>>
>>>> On Fri, Jul 14, 2017 at 7:46 AM, Dennis Shea <shea at ucar.edu> wrote:
>>>>
>>>>> Attached is a script that uses ESMF to regrid. Generating the weights
>>>>> is a bit slow.
>>>>>
>>>>> On Fri, Jul 14, 2017 at 12:59 AM, Ipsita Putatunda <
>>>>> ipsita.putatunda at gmail.com> wrote:
>>>>>
>>>>>> Hi Mary,
>>>>>> If I plot in "RasterFill" mode then only the plot is appearing, not
>>>>>> even I set "AreaFill" or "CellFill".
>>>>>> The plot is appearing something like fractured, not a smoothed one
>>>>>> (even though I put smoothing), I don't know why it is like so.
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Ipsita
>>>>>>
>>>>>> On Fri, Jul 14, 2017 at 11:34 AM, Ipsita Putatunda <
>>>>>> ipsita.putatunda at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Mary,
>>>>>>> I have uploaded my data file with my scripts through ftp.
>>>>>>>
>>>>>>> Ipsita
>>>>>>>
>>>>>>> On Fri, Jul 14, 2017 at 2:51 AM, Dennis Shea <shea at ucar.edu> wrote:
>>>>>>>
>>>>>>>> IMHO: The script is working correctly. However, there is a mismatch
>>>>>>>> between the
>>>>>>>> the user's VERY high resolution (0.15 degrees) 'target grid' and
>>>>>>>> the resolution of the swath data points.
>>>>>>>>
>>>>>>>> re:
>>>>>>>>
>>>>>>>> nlat=1200
>>>>>>>> nlon=2400
>>>>>>>>
>>>>>>>> defines a grid with spacing 0.15 degrees. VERY high resolution
>>>>>>>>
>>>>>>>> ====
>>>>>>>>
>>>>>>>> I have no idea what the rationale for the '400' used for GBIN and
>>>>>>>> GKNTwas based upon.
>>>>>>>>
>>>>>>>> GBIN = new ( (/400,nlon/), float )
>>>>>>>> GKNT = new ( (/400,nlon/), integer )
>>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> The binning algorithm looks at each swath lat/lon location. It
>>>>>>>> finds the target grid box that 'surrounds' the current swath lat/lon
>>>>>>>> location.
>>>>>>>>
>>>>>>>> If there are target grid boxes which do not surround the swath grid
>>>>>>>> poins, then they are returned as missing (_FillValue). Hence, the
>>>>>>>> 'fractured' look of the plot.
>>>>>>>>
>>>>>>>> D
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jul 13, 2017 at 2:52 PM, Mary Haley <haley at ucar.edu> wrote:
>>>>>>>>
>>>>>>>>> Hi Ipsita,
>>>>>>>>>
>>>>>>>>> I'm not sure what you mean by " even though the plot is not
>>>>>>>>> coming with a clear contours. "
>>>>>>>>>
>>>>>>>>> The plot you included doesn't look particularly wrong, so can you
>>>>>>>>> explain what you were expecting?
>>>>>>>>>
>>>>>>>>> The script you attached does not include any plotting code, so I
>>>>>>>>> can't help you much there.
>>>>>>>>>
>>>>>>>>> Can you be more specific about the problem? Also, it would really
>>>>>>>>> help if you can provide the data and the plotting script in the usual way
>>>>>>>>> (ftp).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> --Mary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jul 13, 2017 at 7:04 AM, Ipsita Putatunda <
>>>>>>>>> ipsita.putatunda at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Thank you Dave for your suggestions. I tried to plot the data,
>>>>>>>>>> but it is coming only if I plot setting resource "RasterFill", and even
>>>>>>>>>> though the plot is not coming with a clear contours. Don't know where I am
>>>>>>>>>> making mistake. I tried to regrid the data using "triple2grid" but then all
>>>>>>>>>> the values are coming undefined. I am attaching herewith my script and the
>>>>>>>>>> figure I have got after plotting. Any help will be appreciated.
>>>>>>>>>> Thanks in advance.
>>>>>>>>>>
>>>>>>>>>> Ipsita
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 13, 2017 at 4:19 AM, Dave Allured - NOAA Affiliate <
>>>>>>>>>> dave.allured at noaa.gov> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ipsita,
>>>>>>>>>>>
>>>>>>>>>>> This HDF5 file has coordinate arrays Colatitude and Longitude.
>>>>>>>>>>> The units of each are degrees, not pixels. However, please notice two
>>>>>>>>>>> anomalies:
>>>>>>>>>>>
>>>>>>>>>>> 1. The coordinates are packed with an unusual scale/offset
>>>>>>>>>>> packing scheme. The packing parameters are in attributes Scale_Factor and
>>>>>>>>>>> Add_Offset, which are not CF standard attributes. However, the intent is
>>>>>>>>>>> fairly clear. To unpack each coordinate value, just multiply by the
>>>>>>>>>>> Scale_Factor.
>>>>>>>>>>>
>>>>>>>>>>> The Add_Offset's are zero in this case, and can therefore be
>>>>>>>>>>> ignored. That is good, so that we do not have to worry about whether the
>>>>>>>>>>> offset would be applied before or after the scale factor.
>>>>>>>>>>>
>>>>>>>>>>> This will produce colatitudes in the normal range 60 to 120
>>>>>>>>>>> degrees, and longitudes in the normal range 0 to 360 degrees.
>>>>>>>>>>>
>>>>>>>>>>> 2. I assume that the colatitudes conform to the current
>>>>>>>>>>> definition on Wikipedia. You might confirm this with the data provider, if
>>>>>>>>>>> you wish. This definition is the number of degrees southward from the
>>>>>>>>>>> north pole. The colatitude values unpacked are in the range 60 to 120
>>>>>>>>>>> degrees, which translate to 30 north to 30 south in normal latitude units.
>>>>>>>>>>>
>>>>>>>>>>> --Dave
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 12, 2017 at 12:08 AM, Ipsita Putatunda <
>>>>>>>>>>> ipsita.putatunda at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> The Latitude (here Colatitude) and Longitude data are in pixels
>>>>>>>>>>>> which is -30 to 30 degree and 0 to 360 degree. Please find the file I am
>>>>>>>>>>>> attaching herewith.
>>>>>>>>>>>>
>>>>>>>>>>>> Ipsita
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jul 11, 2017 at 10:30 PM, Dave Allured - NOAA Affiliate
>>>>>>>>>>>> <dave.allured at noaa.gov> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ipsita,
>>>>>>>>>>>>>
>>>>>>>>>>>>> How is your input data georeferenced? Does the input file
>>>>>>>>>>>>> include coordinate variables? That is the most common way to get lats and
>>>>>>>>>>>>> lons for individual pixels.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Dave
>>>>>>>>>>>>> (Please reply to the mailing list.)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jul 11, 2017 at 12:22 AM, Ipsita Putatunda <
>>>>>>>>>>>>> ipsita.putatunda at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dear NCL users,
>>>>>>>>>>>>>> I need help in converting pixels to Lat/Lon grid. Is there
>>>>>>>>>>>>>> any function or way in ncl for doing this operation? Please suggest.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>>>> Ipsita
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> ncl-talk mailing list
>>>>>>>>>> ncl-talk at ucar.edu
>>>>>>>>>> List instructions, subscriber options, unsubscribe:
>>>>>>>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ncl-talk mailing list
>>>>>>>>> ncl-talk at ucar.edu
>>>>>>>>> List instructions, subscriber options, unsubscribe:
>>>>>>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ncl-talk mailing list
>>>>> ncl-talk at ucar.edu
>>>>> List instructions, subscriber options, unsubscribe:
>>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20170717/a24cc6d5/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MT.SCR.ncl_binpois
Type: application/octet-stream
Size: 8211 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20170717/a24cc6d5/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SAPHIR_TOA_BINAVG_POIS.png
Type: image/png
Size: 237787 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20170717/a24cc6d5/attachment-0001.png
More information about the ncl-talk
mailing list