You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
1
(13) |
2
(12) |
3
(3) |
4
(13) |
5
(13) |
6
(2) |
7
(5) |
8
(17) |
9
(9) |
10
(10) |
11
(16) |
12
(8) |
13
(10) |
14
(1) |
15
(5) |
16
(5) |
17
(7) |
18
(13) |
19
(9) |
20
|
21
|
22
(2) |
23
(3) |
24
(5) |
25
(5) |
26
(14) |
27
(1) |
28
(2) |
29
(18) |
30
(5) |
31
(22) |
|
|
|
I would like to use a higher resolution coastline than the high resolution coastline optionally provided with (specifically, I would like to use the NOAA/NOS Medium Resolution Coastline). I can see two ways to do this: Option 1) Create a coastline file using the in the NOAA/NOS data in the same format as the data files used by the basemap toolkit. I couldn't find a description of this format, but it appears that it is partially explained by the code snippet: if line.startswith('P'): area = float(linesplit[5]) west,east,south,north = float(linesplit[6]),float(linesplit[7]),float(linesplit[8]),float(linesplit[9]) typ = int(linesplit[3]) So the first line of the existing high resolution coastline is: P 0 169598 1 W 79866900.000 -17.53378 190.35911 -34.83044 77.71958 Which should be interpreted as typ = 1 area = 79866900.000 west = -17.53378 east = 190.35911 south = -34.83044 north = 77.71958 area is used to control whether this segment of coastline is displayed the directions are the bounding box for the coastline segment I am not clear on how typ is used (I see it getting manipulated, but I don't see it ever getting used), or what its acceptable values are. I am also not clear what the first, second and fourth values of the line are (not counting the initial 'P'). Any help with this format would be appreciated. Option 2) Load a coastline by whatever means I choose as a list of lists of touples (or some other format?) and then transform those values using the basemap object. If the coastline were easily expressed as a pair of lists or arrays lon,lat, then I could simply use b=basemap(...) coastx,coasty = b(lcoastlon,coastlat) but the coastline is made up of multiple segments (islands, etc). Is the best way to transform a collection of segments simply to loop over the segments? coast = [ [(x11,y11),... (x1n,y1n)], [(x21,y21),... (x2n,y2n)],... [(xn1,yn1),...(xnn,ynn)] ] newcoast = [] for c in coast: ln,lt = map(list,zip(*c)) x,y = m(ln,lt) newcoast.append(zip(x,y)) Once I have a transformed list of lists of touples, I can replace the basemap objects coastsegs b.coastsegs = newcoast and then draw the coastline using the built-in b.drawcoastlines() Or is there some method that I am missing? -- View this message in context: http://www.nabble.com/coastlines-in-matplotlib.toolkits.basemap-tf4617110.html#a13186210 Sent from the matplotlib - users mailing list archive at Nabble.com.
Do you know if there is a reason why I cannot succeed in generating a pick_event using wxmpl? I know I could use EVT_POINT but I need the picker event to return the event.ind thanks!
Hi, I am trying to install matplotlib 0.90.1. I have python 2.5 on a fresh Mandriva 2007.1 installation. I have installed numpy and scipy - I think these are ok, they both import and the tests were largely successful. I believe I have all the background packages installed - - matplotlib core: zlib, zlib-devel, libpng, libpng-devel, freetype, freetype-devel, freetype-utils - gtk/gtkagg backend: gtk2-devel, gtk+-devel, pygtk2, glib-devel, pygtk2-devel, gnome-libs-devel, pygtk2-libglade - tk backend: tcl, tk, tkinter - wx/wxagg backends - the wxpython rpms from wxpython<http://wxpython.org%3c/a> apart from freetype-utils which I have not been able to find. With mpl I get the following, having set the path like this: In [2]: sys.path Out[2]: ['', '/usr/bin', '/home/emason', '/usr/lib/python2.5/site-packages/numpy/lib', '/usr/lib/python2.5/site-packages/scipy/lib', '/usr/lib/python25.zip', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/usr/lib/python2.5/site-packages/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode', '/usr/lib/python2.5/site-packages/IPython/Extensions', '/home/emason/.ipython'] [for PYTHONPATH in .bashrc I defined the paths to numpy/lib and scipy/lib; I don't know if this is necessary, in any event it made no difference with these not defined] When I then try to build I get: [root@msasa matplotlib-0.90.1]# python setup.py build running build running build_py copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-i686-2.5 /matplotlib/mpl-data running build_ext building 'matplotlib._nc_transforms' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -g -fPIC -Isrc -I. -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/_nc_transforms.cpp -o build/temp.linux-i686-2.5/src/_nc_transforms.o -DNUMERIC=1 -DVERBOSE src/_nc_transforms.cpp:13:40: error: Numeric/arrayobject.h: No such file or directory src/_nc_transforms.cpp: In member function 'Py::Object Bbox::update_numerix_xy(const Py::Tuple&)': src/_nc_transforms.cpp:517: error: 'PyArrayObject' was not declared in this scope src/_nc_transforms.cpp:517: error: 'xyin' was not declared in this scope src/_nc_transforms.cpp:517: error: expected primary-expression before ')' token src/_nc_transforms.cpp:517: error: expected `;' before 'PyArray_FromObject' src/_nc_transforms.cpp: In member function 'Py::Object Bbox::update_numerix(const Py::Tuple&)': src/_nc_transforms.cpp:586: error: 'PyArrayObject' was not declared in this scope [snip] src/_nc_transforms.cpp:1275: error: 'retmask' was not declared in this scope src/_nc_transforms.cpp:1278: error: expected primary-expression before ')' token src/_nc_transforms.cpp:1278: error: expected `;' before 'PyArray_FromDims' src/_nc_transforms.cpp: In function 'void init_nc_transforms()': src/_nc_transforms.cpp:2428: error: 'import_array' was not declared in this scope error: command 'gcc' failed with exit status 1 [root@msasa matplotlib-0.90.1]# It seems to trip up when expecting a file 'arrayobject.h' in the /Numeric directory; indeed that file is not there, though Numeric is on the path. Numeric came as part of the Mandriva install. I'd be grateful for any help with this, thanks in advance, Evan
Pascoe, S (Stephen) wrote: > Thanks Jeff, > > Unfortunately another issue is with plotting the axes tick labels. This > output is for a public service where the users expect to see eastings > and northings displayed from the official UK national grid origin. I > can use standard matplotlib axes to produce eastings/northings but with > your solution the origin would be shown as in the wrong place. > > I can envisage solving this by creating a tick Formatter object that > offsets the axes. Maybe that is my solution but I was hoping for a > simpler way. > > Cheers, > Stephen. > Stephen: Using a TickFormatter is probably the best solution. -Jeff P.S. Could you send me an example when you're done - perhaps to include in the examples directory? > --- > Stephen Pascoe +44 (0)1235 445980 > British Atmospheric Data Centre > Rutherford Appleton Laboratory > > -----Original Message----- > From: Jeff Whitaker [mailto:js...@fa...] > Sent: 12 October 2007 13:11 > To: Pascoe, S (Stephen) > Cc: mat...@li... > Subject: Re: [Matplotlib-users] Basemap with origin within the plot > > Pascoe, S (Stephen) wrote: > >> I am trying to prepare a plot on the UK national grid. This is a >> > transverse mercator projection centred on the UK with a false origin > offset from the projection origin (lat_0, lon_0). > >> The Basemap coordinate system origin (0 Easting and Northing) always >> > seems to be set in the lower-left corner of the plot. The plot I need > includes data either side of the origin so I need the origin within the > plot area. > >> Is there a general way of setting the origin somewhere other than the >> > lower-left corner? > >> I can either get basemap to plot the correct data region, in which >> > case the origin is in the wrong place or I can fool Basemap by adjusting > the axes bounds later. However, if I do this some of the coastline > isn't plotted because Basemap decides it isn't on the map. > >> Cheers, >> Stephen. >> >> >> >> > Stephen: There's no way to change the coordinate system Basemap uses. > To get you data to plot in the correct place, just add an offset > > xoffset, yoffset = map(lon_0, lat_0) > > to the UK national grid coordinates of the data you are plotting. > > HTH, > > -Jeff > > -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449 325 Broadway Boulder, CO, USA 80305-3328
Pascoe, S (Stephen) wrote: > I am trying to prepare a plot on the UK national grid. This is a transverse mercator projection centred on the UK with a false origin offset from the projection origin (lat_0, lon_0). > > The Basemap coordinate system origin (0 Easting and Northing) always seems to be set in the lower-left corner of the plot. The plot I need includes data either side of the origin so I need the origin within the plot area. > > Is there a general way of setting the origin somewhere other than the lower-left corner? > > I can either get basemap to plot the correct data region, in which case the origin is in the wrong place or I can fool Basemap by adjusting the axes bounds later. However, if I do this some of the coastline isn't plotted because Basemap decides it isn't on the map. > > Cheers, > Stephen. > > > Stephen: There's no way to change the coordinate system Basemap uses. To get you data to plot in the correct place, just add an offset xoffset, yoffset = map(lon_0, lat_0) to the UK national grid coordinates of the data you are plotting. HTH, -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449 325 Broadway Boulder, CO, USA 80305-3328
Hi, I have some time series data of server CPU usage (user, system, WIO, free, etc) and would like to plot this as a stacked bar chart, with dates / times on the x axis (as per plot_date for x, y series data). Is this possible? Cheers, James.
On 10/10/2007, Pascoe, S (Stephen) <S.P...@rl...> wrote: > Is there a general way of setting the origin somewhere other than the lower-left corner? I've just had to deal with a similar problem, you need to use the basemap.shiftgrid() method to shift the co-ordinate grid accordingly. Cheers Adam
Hi Joshua, > As you can see from the attached graph, there is a break the in graph > somewhere around 7 AM or so. This is the data I am graphing for that red > line: > > "2007-10-09 00:00:00",0.015 > "2007-10-09 01:00:00",0.015 > "2007-10-09 02:00:00",0.014 > "2007-10-09 03:00:00",0.012 > "2007-10-09 04:00:00",0.008 > "2007-10-09 05:00:00",0.002 > "2007-10-09 06:00:00",-0.006 > <snip> > If I change the -0.006 at 6:00AM to 0.006, it graphs with no break in the > line. Can not comment on Matplotlib, ... but what method are you using the process your input? RegEx or other ?, can it handle negative input? The attached script has missing data points where the data point in None Don't know if that helps Steve
John, I would prefer to be able to use the power and flexibility of datestr2num and the underlying dateutil.parser, rather than writing my own parser. However, looking further at dateutil.parser.parse, it takes an argument tzinfos, which allows timezone names other than the local timezone and UTC/GMT/Z to be understood within parse. I haven't worked out the full range of functionality for the tzinfos argument, but a simple example would be: > tzlibrary = {'EST':-5*60*60,'EDT':-4*60*60,'EST':-6*60*60, > 'CDT':-5*60*60,'PST':-8*60*60,'PDT':-7*60*60} > matplotlib.dates.date2num(dateutil.parser.parse('jan 1, 2007 12:00 > PST',tzinfos=tzlibrary)) 732677.83333333337 > matplotlib.dates.date2num(dateutil.parser.parse('jan 1, 2007 12:00 > PDT',tzinfos=tzlibrary)) 732677.79166666663 > matplotlib.dates.date2num(dateutil.parser.parse('jan 1, 2007 12:00 > EDT',tzinfos=tzlibrary)) 732677.66666666663 Actually, I can just duplicate datestr2num, but pass a tzinfos dictionary as well, e.g.: def datestr2num(d,tzinfos=None): """ Convert a date string to a datenum using dateutil.parser.parse d can be a single string or a sequence of strings """ if is_string_like(d): dt = dateutil.parser.parse(d,tzinfos=tzinfos) return date2num(dt) else: return date2num([dateutil.parser.parse(s,tzinfos=tzinfos) for s in d]) explicitly passing a tzinfos of None does not cause any problems for dateutil.parser.parse. thanks, Charles John Hunter-4 wrote: > > On 10/11/07, Charles Seaton <cs...@st...> wrote: > >> Any suggestions on how to get either matplotlib.dates.datestr2num or >> dateutil.parser.parse to properly handle timezone information in the >> datestring would be greatly appreciated. > > Not sure how to answer this question vis-a-vid dateutil.parser, but > you may want to consider creating your own datestr -> datetime > converter using time.strptime and then allowing mpl to convert to > numbers using date2num. I think you can use the %Z format code for > timezones. > > JDH > > -- View this message in context: http://www.nabble.com/datestr2num%2C-dateutil.parse-and-timezone-problems-tf4609462.html#a13167297 Sent from the matplotlib - users mailing list archive at Nabble.com.
On 11/10/2007, Jeff Whitaker <js...@fa...> wrote: > but I think you want > > values, lon = basemap.shiftgrid(180, values, lon, start=False) Thats it! Thanks a lot! Cheers Adam
Disclaimer: I do know Python, but am not terribly familiar with Matplotlib as I'm taking over the maintenance of our graphing libraries. This post is likely to leave out details that you need to help diagnose the problem, but I didn't think posting all 1500 or so lines of our graphing routines would be that helpful at this point. :) As you can see from the attached graph, there is a break the in graph somewhere around 7 AM or so. This is the data I am graphing for that red line: "2007-10-09 00:00:00",0.015 "2007-10-09 01:00:00",0.015 "2007-10-09 02:00:00",0.014 "2007-10-09 03:00:00",0.012 "2007-10-09 04:00:00",0.008 "2007-10-09 05:00:00",0.002 "2007-10-09 06:00:00",-0.006 "2007-10-09 07:00:00",1.068 "2007-10-09 08:00:00",12.8 "2007-10-09 09:00:00",15.21 "2007-10-09 10:00:00",20.13 "2007-10-09 11:00:00",20.94 "2007-10-09 12:00:00",21.15 "2007-10-09 13:00:00",21.13 "2007-10-09 14:00:00",20.88 "2007-10-09 15:00:00",20.72 "2007-10-09 16:00:00",20.55 "2007-10-09 17:00:00",16.28 "2007-10-09 18:00:00",13.18 "2007-10-09 19:00:00",4.342 "2007-10-09 20:00:00",0.016 "2007-10-09 21:00:00",0.015 "2007-10-09 22:00:00",0.015 "2007-10-09 23:00:00",0.015 If I change the -0.006 at 6:00AM to 0.006, it graphs with no break in the line. This is not a big deal to me, but it is a big deal to the consumer of these graphs. Could this be a bug in matplotlib, or is it more likely a bug in what we're doing with the data (almost nothing) before it gets to the matplotlib graphing routines? Thanks for any insight you can give. j -- Joshua Kugler Lead System Admin -- Senior Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE PO Box 80086 -- Fairbanks, AK 99708 -- Ph: 907-456-5581 Fax: 907-456-3111
Adam Mercer wrote: > On 11/10/2007, Jeff Whitaker <js...@fa...> wrote: > > >> Adam: I assume your data is on a latitude-longitude grid? You've asked >> for a mollweide projection centered on the Greenwich meridian. Your >> data is not centered on Greenwich - but the error message is trying to >> say that you can shift your grid (with the shiftgrid function) so that >> is has the same orientation as the map projection region. This only >> comes into play with global projections that 'wrap-around' at the edges, >> like the mollweide and mercator projections. The orthographic >> projection does not 'wrap around' - hence you don't get the error message. >> > > Looking at the shiftmap function it looks like I should shift the > co-ordinate grid so that my longitude runs from -180 to 180 instead of > 0 to 360, therefore the following shiftgrid call should do this > > values, lon = basemap.shiftgrid(180, values, lon) > > However I still get the same error and the corruption in the resulting > plot. I feel like I'm missing something obvious here but can't find > it. > > Cheers > > Adam > Adam: From the basemap docs; shiftgrid(lon0, datain, lonsin, start=True) shift global lat/lon grid east or west. assumes wraparound (or cyclic point) is included. lon0: starting longitude for shifted grid (ending longitude if start=False). lon0 must be on input grid (within the range of lonsin). datain: original data. lonsin: original longitudes. start[True]: if True, lon0 represents the starting longitude of the new grid. if False, lon0 is the ending longitude. returns dataout,lonsout (data and longitudes on shifted grid). You did values, lon = basemap.shiftgrid(180, values, lon) but I think you want values, lon = basemap.shiftgrid(180, values, lon, start=False) HTH, -Jeff -- 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-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
On 10/11/07, Alexander Schmolck <a.s...@gm...> wrote: > Hi, > > I'm using matplotlib in a C++ app (with a qt4 gui), by embedding python with > boost::python. The C++ app calls Py_Initialize(), init_myplottingmodule(), and > boost::python::import("matplotlib.pylab") once on startup and certain GUI > events then fire up a matplotlib window via calls like this one: > > // simplified version > void plotCurve(){ > clf(); > title("Diagonal line plot"); > double O1[] = {0,1}; > plot(std::vector<double>(O1,O1+2), std::vector<double>(O1,O1+2), "b:"); > show(); Eeeeew, that looks really dangerous. For starters, I would never try to do this using pylab, but rather follow the lead of examples/embedding_in_qt.py. Then you won't be competing for the mainloop.... JDH
On 10/11/07, Charles Seaton <cs...@st...> wrote: > Any suggestions on how to get either matplotlib.dates.datestr2num or > dateutil.parser.parse to properly handle timezone information in the > datestring would be greatly appreciated. Not sure how to answer this question vis-a-vid dateutil.parser, but you may want to consider creating your own datestr -> datetime converter using time.strptime and then allowing mpl to convert to numbers using date2num. I think you can use the %Z format code for timezones. JDH
I am having some problems getting matplotlib.dates.datestr2num to handle timezones in the datestring. >import matplotlib >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 PDT') 732677.83333333337 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 PST') 732677.83333333337 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00-08') 732677.83333333337 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 UTC') 732677.5 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00 EST') 732677.5 >matplotlib.dates.datestr2num('Jan 1, 2007 12:00-07') 732677.79166666663 The problem appears to lie with dateutil, as direct use of the dateutil.parser.parse function shows the same problem: > import dateutil.parser > dateutil.parser.parse('Jan 1, 2007 12:00 EST') datetime.datetime(2007, 1, 1, 12, 0) > dateutil.parser.parse('Jan 1, 2007 12:00 PDT') datetime.datetime(2007, 1, 1, 12, 0, tzinfo=tzlocal()) > dateutil.parser.parse('Jan 1, 2007 12:00 PST') datetime.datetime(2007, 1, 1, 12, 0, tzinfo=tzlocal()) I am using dateutil version 1.2. Any suggestions on how to get either matplotlib.dates.datestr2num or dateutil.parser.parse to properly handle timezone information in the datestring would be greatly appreciated. Charles Seaton OHSU/CMOP -- View this message in context: http://www.nabble.com/datestr2num%2C-dateutil.parse-and-timezone-problems-tf4609462.html#a13162968 Sent from the matplotlib - users mailing list archive at Nabble.com.
Hi Yadin, I am a simple user, but I already faced this problem. The idea I used is to plot the data as an image, with magnitudes being converted in color levels. To do that, you have to define an array (let's say 'Z', Z(x,y) with dims len(X) and len(Y) and fill it with tour magnitudes. Then you have a two dimensional array that you display as an image using : im = pylab.Imshow(Z) Imshow has a lot of options you can use to customize your display, and you can add a colorbar with : pylab.colorbar() I have some examples of such scripts, but commented in French, so perhaps not very useful for you. See the user's guide to begin, p 38 for example. Regards, Alain yadin Bocuma Rivas a écrit : > > I i have tree lists or array of values > list x of 100... values > list y of 100.. values > list mag of 100.. values > list x and y are coordiantes of points > and list Mag is magnitude of something at that point > > how can i plot this quantities using matplotlib, any function please? > > my code starts as.....i need to plot the points vhat can i use? > > from __future__ import division > from matplotlib.patches import Patch > from pylab import * > > def func3(x,y): > return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2) > > > # make these smaller to increase the resolution > dx, dy = 0.5, 0.5 > > X = arange(-3.0, 3.0001, dx) > > Y = arange(-3.0, 3.0001, dy) > > Mag= X**2+Y**2 > > ?????(X, Y, Mag) > colorbar() > axis([-3,3,-3,3]) > savefig('three d plot of points making a surface') > show() > > > ------------------------------------------------------------------------ > > ¡Sé un mejor ambientalista! > Encuentra consejos para cuidar el lugar donde vivimos en: > http://telemundo.yahoo.com/promos/mejorambientalista.html > > > ------------------------------------------------------------------------ > > ¡Sé un mejor besador! > Comparte todo lo que sabes sobre besos en: > http://telemundo.yahoo.com/promos/mejorbesador.html > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
On 11/10/2007, Jeff Whitaker <js...@fa...> wrote: > Adam: I assume your data is on a latitude-longitude grid? You've asked > for a mollweide projection centered on the Greenwich meridian. Your > data is not centered on Greenwich - but the error message is trying to > say that you can shift your grid (with the shiftgrid function) so that > is has the same orientation as the map projection region. This only > comes into play with global projections that 'wrap-around' at the edges, > like the mollweide and mercator projections. The orthographic > projection does not 'wrap around' - hence you don't get the error message. Looking at the shiftmap function it looks like I should shift the co-ordinate grid so that my longitude runs from -180 to 180 instead of 0 to 360, therefore the following shiftgrid call should do this values, lon = basemap.shiftgrid(180, values, lon) However I still get the same error and the corruption in the resulting plot. I feel like I'm missing something obvious here but can't find it. Cheers Adam
On 11/10/2007, Jeff Whitaker <js...@fa...> wrote: > Adam: I assume your data is on a latitude-longitude grid? You've asked > for a mollweide projection centered on the Greenwich meridian. Your > data is not centered on Greenwich - but the error message is trying to > say that you can shift your grid (with the shiftgrid function) so that > is has the same orientation as the map projection region. This only > comes into play with global projections that 'wrap-around' at the edges, > like the mollweide and mercator projections. The orthographic > projection does not 'wrap around' - hence you don't get the error message. Thanks, that makes sense now. Cheers Adam
Adam Mercer wrote: > Hi > > I'm running into a problem using the mollweide projection, with the > following simplified code, my actual code doesn't use random data for > values but this is a clearer example to the problem I'm experiencing: > > lon = numpy.arange(0, 361, 1) > lat = numpy.arange(-90, 91, 1) > x, y = numpy.meshgrid(lon, lat) > values = numpy.random.random((181, 361)) > > map = basemap.Basemap(projection='moll', lon_0=0, resolution='c') > map.drawcoastlines() > map.drawcountries() > map.drawmapboundary() > map.drawmeridians(numpy.arange(0,360,30)) > map.drawparallels(numpy.arange(-90,90,30)) > > X, Y = map(x, y) > > map.contourf(X, Y, values) > > I get the following error: > > WARNING: x coordinate not montonically increasing - contour plot > may not be what you expect. If it looks odd, your can either > adjust the map projection region to be consistent with your data, or > (if your data is on a global lat/lon grid) use the shiftgrid > function to adjust the data to be consistent with the map projection > region (see examples/contour_demo.py). > > And the resulting map is incorrect due to the horizontal trends, see > http://tier2.ihepa.ufl.edu/~ram/files/moll.jpg > > > but if I use the orthographic projection ie: > > map = basemap.Basemap(projection='ortho', lat_0=-20, lon_0=-30, resolution='c') > > Then there are no errors, and the map is displayed as expected, see > http://tier2.ihepa.ufl.edu/~ram/files/ortho.jpg > > I am unsure as to why I am receiving this error for the mollweide > projection, as my coordinate grid is covering the entire surface. I > am clearly doing something wring here but I don't know what - does > anyone know what is causing this issue? > > Cheers > > Adam > Adam: I assume your data is on a latitude-longitude grid? You've asked for a mollweide projection centered on the Greenwich meridian. Your data is not centered on Greenwich - but the error message is trying to say that you can shift your grid (with the shiftgrid function) so that is has the same orientation as the map projection region. This only comes into play with global projections that 'wrap-around' at the edges, like the mollweide and mercator projections. The orthographic projection does not 'wrap around' - hence you don't get the error message. -Jeff -- 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-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
=0AI i have tree lists or array of values=0Alist x of 100... values=0Alist = y of 100.. values=0Alist mag of 100.. values=0Alist x and y are coordiantes= of points =0Aand list Mag is magnitude of something at that point=0A=0Ahow= can i plot this quantities using matplotlib, any function please?=0A=0Amy = code starts as.....i need to plot the points vhat can i use?=0A=0Afrom __fu= ture__ import division=0Afrom matplotlib.patches import Patch=0Afrom pylab = import *=0A=0Adef func3(x,y):=0A return (1- x/2 + x**5 + y**3)*exp(-x**2= -y**2)=0A=0A=0A# make these smaller to increase the resolution=0Adx, dy =3D= 0.5, 0.5=0A=0AX =3D arange(-3.0, 3.0001, dx)=0A=0AY =3D arange(-3.0, 3.000= 1, dy)=0A=0AMag=3D X**2+Y**2=0A=0A?????(X, Y, Mag)=0Acolorbar()=0Aaxis([-3,= 3,-3,3])=0Asavefig('three d plot of points making a surface')=0Ashow()=0A= =0A=0A=0A=0A=0A=0A =0A=A1S=E9 un mejor ambientalista!=0AEncuentra cons= ejos para cuidar el lugar donde vivimos en:=0A=0Ahttp://telemundo.yahoo.com= /promos/mejorambientalista.html=0A=0A=0A=0A=0A=0A ____________________= ________________________________________________________________=0A=A1S=E9 = un mejor fot=F3grafo!=0APerfecciona tu t=E9cnica y encuentra las mejores fo= tos. =0Ahttp://telemundo.yahoo.com/promos/mejorfotogr= afo.html
> > Can this be changed? Is there a better approach I should take in > getting my students started using scipy and pylab together? > Teaching them what is a module and a namespace is a good think, why don't telling them to do : import pylab as pl import numpy as npy for instance so that they have a feeling it's almost like MAtlab, but better structured ? Matthieu
Hi, I'm using matplotlib in a C++ app (with a qt4 gui), by embedding python with boost::python. The C++ app calls Py_Initialize(), init_myplottingmodule(), and boost::python::import("matplotlib.pylab") once on startup and certain GUI events then fire up a matplotlib window via calls like this one: // simplified version void plotCurve(){ clf(); title("Diagonal line plot"); double O1[] = {0,1}; plot(std::vector<double>(O1,O1+2), std::vector<double>(O1,O1+2), "b:"); show(); } Although this does sort of work, it doesn't work quite right. Specifically on clicking on the close button of the window, bad things frequently happen. For example, the first close seems to work, but subsequent attempts to close newly opened plots just zombify the window (it no longer repaints automatically but stays open; replots happen to that same window, i.e. the one that was opened second). Now I'm somewhat aware of all the nastiness of different event loops, the heroic efforts of ipython to make matplotlib work nicely interactively without blocking the REPL, but somehow I would have (naively) thought that all that work was just needed to avoid blocking. For the code above, blocking till the window would be closed is perfectly fine. Indeed that's what happens if I try something equivalent in the plain python shell (outside the C++ app). Any idea about the likely cause of the problem and what might be the simplest way to get it to work as expected (similar symptoms appear w/ matplotlib 0.87.7 and 0.91 under linux and osx)? cheers, 'as
Hi I'm running into a problem using the mollweide projection, with the following simplified code, my actual code doesn't use random data for values but this is a clearer example to the problem I'm experiencing: lon = numpy.arange(0, 361, 1) lat = numpy.arange(-90, 91, 1) x, y = numpy.meshgrid(lon, lat) values = numpy.random.random((181, 361)) map = basemap.Basemap(projection='moll', lon_0=0, resolution='c') map.drawcoastlines() map.drawcountries() map.drawmapboundary() map.drawmeridians(numpy.arange(0,360,30)) map.drawparallels(numpy.arange(-90,90,30)) X, Y = map(x, y) map.contourf(X, Y, values) I get the following error: WARNING: x coordinate not montonically increasing - contour plot may not be what you expect. If it looks odd, your can either adjust the map projection region to be consistent with your data, or (if your data is on a global lat/lon grid) use the shiftgrid function to adjust the data to be consistent with the map projection region (see examples/contour_demo.py). And the resulting map is incorrect due to the horizontal trends, see http://tier2.ihepa.ufl.edu/~ram/files/moll.jpg but if I use the orthographic projection ie: map = basemap.Basemap(projection='ortho', lat_0=-20, lon_0=-30, resolution='c') Then there are no errors, and the map is displayed as expected, see http://tier2.ihepa.ufl.edu/~ram/files/ortho.jpg I am unsure as to why I am receiving this error for the mollweide projection, as my coordinate grid is covering the entire surface. I am clearly doing something wring here but I don't know what - does anyone know what is causing this issue? Cheers Adam
On 10/11/07, Ryan Krauss <rya...@gm...> wrote: > Can this be changed? Is there a better approach I should take in > getting my students started using scipy and pylab together? Yes, this was left in initially for backward compatibility but I think we should strive for maximal numpy compatibility going forward. In svn, we now have pyplot ehich is like pylab but minus the numpy stuff. Thus if you are using svn (or future releases) you can encourage your students to from scipy import * from matplotlib.pyplot import *
I have successfully (I think) coerced my students into using Scipy/Numpy for signal processing and dynamic system modeling. They are mechanical engineering coming from a Matlab background. In order to make using Python easy and have it feel like Matlab, I teach them to put from scipy import * from pylab import * at the beginning of every script. One problem with this is that the zeros and ones functions of pylab default to integers while those from scipy default to floating point numbers. I have had several students this week beating there heads against problems that turned out to be trying to put floating point values in an array that was created using pylab.zeros. Can this be changed? Is there a better approach I should take in getting my students started using scipy and pylab together? Thanks, Ryan