|
From: Jakob M. <jak...@gm...> - 2011-09-09 10:49:28
|
2011/9/8 Jeff Whitaker <js...@fa...>: > On 9/8/11 1:51 AM, Jakob Malm wrote: >> >> Picking up on an old thread. Hopefully Jeff is still listening in... >> >> On 2010-04-04 23:24, 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 >> >> What if it _is_ a satellite swath? Can I get around the problem of >> off-projection plotting with Basemap.pcolormesh()? >> Example code and plots can be found at >> >> http://pythonbits.blogspot.com/2011/09/i-have-problem-with-basemap-plotting.html >> >> Thanks, >> Jakob Malm >> > > > Jakob: I think that's the price you pay for the speed of pcolormesh (vs > pcolor). It appears to make more assumptions about the structure of your > data. I don't see any way around it. > > -Jeff > Hmm... I believe I have been able to get around it previously, but perhaps I just fell back to using pcolor... Thanks, Jakob |