|
From: Jeff W. <js...@fa...> - 2010-04-05 14:30:21
|
On 4/5/10 7:25 AM, Will Hewson wrote: > I should perhaps of explained my code (included in top post) a little better, > the values in my attached file aren't on a regular grid to start with, I do > a little bit of juggling as follows to get them into a regular grid: > > I'm firstly setting up my 2D grid of 0.5 degree lat lons, followed by > identically sized grids of zeros for the data bin, and mean divisors: > > x = np.arange(-180, 180, 0.5); y = np.arange(-90, 90, 0.5) > grid_lon, grid_lat = np.meshgrid(x,y) #regularly spaced 2D grid > n_vals = np.zeros((360,720)) #mean divisor > dat = np.zeros((360,720)) #2D grid of zeros > > I'm then taking my input data (e.g. the .plt file attached), and rounding > the lat lons to the nearest 0 or 0.5: > > lon = (np.around(lon*2))/2 #round to nearest .0 or 0.5 > lat = (np.around(lat*2))/2 #round to nearest .0 or 0.5 > > Then for each row in my input file where Z is greater than 0, I'm adding the > n'th Z value to its corresponding position in the dat zeros array, and > keeping a count of how many values are going into each cell in the mean > divisor array: > > j=0 > for i in slcol: > if lon[j]< 0: > grid_lon_ind = 360+(lon[j]*2) > grid_lat_ind = 180+(lat[j]*2) > else: > grid_lon_ind = 360-(lon[j]*2) > grid_lat_ind = 180+(lat[j]*2) > if i> 0: > dat[grid_lat_ind, grid_lon_ind] += i #add i'th value > n_vals[grid_lat_ind, grid_lon_ind] += 1 #increase cell counter by 1 for > each extra value > j+=1 > > Finally the new dat array is divided by the mean divisor array to give me my > mean Z values: > > dat = np.nan_to_num(dat/n_vals) > > I've done it this way as opposed to interpolating *properly* in order to > (for instance) stop the values bleeding away from the edges of the satellite > swath. > > Cheers, > > Will. > Will: I made some slight modifications to your original script and it works fine with the ortho projection using either contourf on the original lat/lon grid or pcolormesh on the interpolated map projection grid. -Jeff > > Jeff Whitaker wrote: > >> On 4/5/10 4:16 AM, Will Hewson wrote: >> >>> Hey Jeff, >>> >>> It's somewhere between the two - the original satellite swath is >>> converted >>> to a regular 0.5 degree grid by truncating, binning, and averaging each >>> point's lons and lats over the top of a 720 x 360 np.zeros array. the >>> plotting still works fine for non ortho/ hemispherical projections, and >>> I've >>> no big problem with using global projections for the time being. Thanks >>> for >>> your help in the meantime anyway. >>> >>> Cheers, >>> >>> >>> Will. >>> >>> >> Will: If it's a regular 0.5 degree lat/lon grid, it should work in >> transform_scalar. However, I don't see how to read the data in your >> test.plt file into a regular 360x720 grid. It seems to only contain the >> points in the swath with nonzero values. >> >> -Jeff >> >>> >>> Jeff Whitaker wrote: >>> >>> >>>> On 4/4/10 11:06 AM, Will Hewson wrote: >>>> >>>> >>>>> Hi again Jeff et al... >>>>> >>>>> I've had a play around with the extra few lines of code - on paper this >>>>> seems like it should solve the problems I'm experiencing. However, an >>>>> error's being thrown up by the transform scalar function, as my lons >>>>> and >>>>> lats won't necessarily be increasing. The data I'm plotting is >>>>> satellite >>>>> data and so at the beginning and end of the orbit file lats go over the >>>>> pole >>>>> from 90 to -90, with a similar problem for the lons - whereby the data >>>>> is >>>>> taken across the satellite track. I've thought about sorting the data >>>>> before >>>>> passing it to transform_scalar but I'm always going to be left with the >>>>> problem in either lats or lons. >>>>> >>>>> I've uploaded the file I'm currently working with this time. It's three >>>>> columns of lons, lats and z values. >>>>> >>>>> Once again, many thanks for your help. >>>>> >>>>> Will. >>>>> >>>>> http://old.nabble.com/file/p28133659/test.plt test.plt >>>>> >>>>> >>>>> >>>> Will: Is it a regular lat/lon grid or a satellite swath? If it's the >>>> latter, you can't use my solution. >>>> >>>> -Jeff >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Mat...@li... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>>> >>>> >>>> >>>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> >> > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |