matplotlib-users Mailing List for matplotlib

Eric Firing wrote:
> Matthias Michler wrote:
>> Hello list,
>>
>> playing with the example program (contourf_with_extended_colorbar.py) I also 
>> send in the last email and using random numbers I get the attached picture 
>> (contourf_vs_contour_different_behavior.png), which shows up that contour and 
>> contourf lines don't coinside. I thought that contour and contourf generate 
>> the same lines and differ only in plotting. Is this just due to the random 
>> numbers as an exceptional case or is this a bug? 
> 
> It is a bug that is inherent in the underlying contouring code.  The 
> code for filled contours is quite different, and more complicated, than 
> for unfilled contours.  I have been thinking about ways of solving this 
> problem, unifying the line-finding methods for filled and unfilled 
> contours, but it is not at all trivial.
> 

And I need to add: it may be that the difference between filled and 
unfilled contours that you showed in your plot is not actually a 
consequence of the difference between the filled and unfilled code 
paths, but of the sequence of calls to the underlying code.  So it is 
possible that when one wants both filled and unfilled contours, they 
could be made consistent via a refactoring of the internals of the 
ContourSet class, with corresponding changes in the Axes and pyplot 
APIs.  Again, this is not trivial, but there is some refactoring I would 
like to do anyway to make it easier for people to access the results of 
the basic contour-finding, and this would go along with it.

I don't know when I will get around to actually working on this; 
probably not before this summer.  If someone else wants to plunge in, 
that's fine.  I can provide a few thoughts on what might be done.

Eric

Matthias Michler wrote:
> Hello list,
> 
> playing with the example program (contourf_with_extended_colorbar.py) I also 
> send in the last email and using random numbers I get the attached picture 
> (contourf_vs_contour_different_behavior.png), which shows up that contour and 
> contourf lines don't coinside. I thought that contour and contourf generate 
> the same lines and differ only in plotting. Is this just due to the random 
> numbers as an exceptional case or is this a bug? 

It is a bug that is inherent in the underlying contouring code.  The 
code for filled contours is quite different, and more complicated, than 
for unfilled contours.  I have been thinking about ways of solving this 
problem, unifying the line-finding methods for filled and unfilled 
contours, but it is not at all trivial.

> 
> 
> Second question: Could it be useful to add two kwargs 'over_color' 
> and 'under_color' to contourf in order to allow specification of a extended 
> ListedColormap by kwarg 'colors' and these two colors?
> I tried to include this in the attached patch 
> (added_under_and_over_color_to_ContourSet.patch) and use it in the example 
> contourf_with_extended_colorbar_new.py. But it dosn't work completely 
> correct. Although the over color is correctly set to cyan in the cmap 
> In [14]: my_contourf.cmap._rgba_over
> Out[14]: (0.0, 1.0, 1.0, 1.0)
> red is used for values above the colormap-bounds. 
> 
> Thanks in advance for any comments and hints.

I need to look at your patch--but a priori, I am a bit worried about the 
tendency of APIs to get more and more complicated, with more and more 
kwargs, as time goes on.

Eric

> 
> best regards Matthias
> 
> On Thursday 09 April 2009 13:16:55 Matthias Michler wrote:
>> Hi Bala,
>>
>> you may want to have a look at the gallery including many example pictures
>> on http://matplotlib.sourceforge.net/gallery.html
>> especially the follwing two examples might be of interest for you
>> http://matplotlib.sourceforge.net/examples/pylab_examples/contourf_demo.htm
>> l http://matplotlib.sourceforge.net/examples/api/colorbar_only.html
>>
>> I used these two to set up the attached example, which is very close to
>> what you want.
>>
>> Question for developers: Could it be useful to add two kwargs 'over_color'
>> and 'under_color' to contourf in order to allow specification of a
>> ListedColormap by kwarg 'colors' and these two colors?
>>
>> best regards
>> Matthias
>>
>> On Thursday 09 April 2009 10:34:27 Bala subramanian wrote:
>>> Dear Matthias,
>>>
>>> Thanks a ton. This is a great help for me. Is there any way to specify a
>>> color range. By default it has produced different colors at the interval
>>> of 0.3, i need bit higher range like < 1 , 1 to 1.5, 1.5-2.0, 2-2.5, >
>>> 2.5. Also i need to set this range dynamically. Kindly write me how i can
>>> do this.
>>>
>>> Thanks in advance,
>>> Bala
>>>
>>> On Thu, Apr 9, 2009 at 9:08 AM, Matthias Michler
>> <Mat...@gm...>wrote:
>>>> Hi Bala,
>>>>
>>>> I added a small example showing up your matrix in order to have a
>>>> running example, where you can specify your needs.
>>>>
>>>> In the program contourf  could be replaced by contour or imshow - see
>>>> help /
>>>> docu / examples on the web
>>>> The colormap can be specified with the kwarg "cmap" : e.g.
>>>> pyplot.cm.gray.
>>>>
>>>> regards Matthias
>>>>
>>>> On Wednesday 08 April 2009 14:08:13 Bala subramanian wrote:
>>>>> Friends,
>>>>>
>>>>> I have a pairwise comparison of 50 data points. The comparison is
>>>>> based
>>>> on
>>>>
>>>>> the mean square deviation between the points. I want to plot this
>>>>> data by specifying different colors for diffrent ranges of mean
>>>>> square deviation. Any suggestion would be of much help to me. I have
>>>>> attached the data file with the mail.
>>>>>
>>>>> Thanks,
>>>>> Bala
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by:
>>>>> High Quality Requirements in a Collaborative Environment.
>>>>> Download a free trial of Rational Requirements Composer Now!
>>>>> http://p.sf.net/sfu/www-ibm-com
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ah -- that bug may have been fixed since 0.91, if I recall correctly.

Mike

Chaitanya Krishna wrote:
> Nope. Does not work.
>
> Fails with ...
>
> /home/cande/python/packages/matplotlib-0.91.1-py2.5-linux-x86_64.egg/matplotlib/mathtext.py:670:
> MathTextWarning: Unrecognized symbol '\['. Substituting with a dummy
> symbol.
>   % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
> /home/cande/python/packages/matplotlib-0.91.1-py2.5-linux-x86_64.egg/matplotlib/mathtext.py:670:
> MathTextWarning: Unrecognized symbol '\]'. Substituting with a dummy
> symbol.
>   % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
>
> Like it says, it renders the plot but with a dummy symbol. A plain [
> or ] does not even render the plot.
>
> Just tried, \left[ and \right] and they work.
>
> Cheers,
> Chaitanya
>
>
> On Tue, Apr 14, 2009 at 6:30 PM, Michael Droettboom <md...@st...> wrote:
>   
>> You need to escape the [ ], e.g. \[ \]
>> Does that work for you?
>>
>> Cheers,
>> Mike
>>
>> Chaitanya Krishna wrote:
>>     
>>> Forgot to mention the version in the last mail. I am using
>>>
>>> In [2]: matplotlib.__version__
>>> Out[2]: '0.91.1'
>>>
>>> Cheers,
>>> Chaitanya
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> High Quality Requirements in a Collaborative Environment.
>>> Download a free trial of Rational Requirements Composer Now!
>>> http://p.sf.net/sfu/www-ibm-com
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>       
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>     

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Nope. Does not work.

Fails with ...

/home/cande/python/packages/matplotlib-0.91.1-py2.5-linux-x86_64.egg/matplotlib/mathtext.py:670:
MathTextWarning: Unrecognized symbol '\['. Substituting with a dummy
symbol.
  % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
/home/cande/python/packages/matplotlib-0.91.1-py2.5-linux-x86_64.egg/matplotlib/mathtext.py:670:
MathTextWarning: Unrecognized symbol '\]'. Substituting with a dummy
symbol.
  % sym.encode('ascii', 'backslashreplace'), MathTextWarning)

Like it says, it renders the plot but with a dummy symbol. A plain [
or ] does not even render the plot.

Just tried, \left[ and \right] and they work.

Cheers,
Chaitanya


On Tue, Apr 14, 2009 at 6:30 PM, Michael Droettboom <md...@st...> wrote:
> You need to escape the [ ], e.g. \[ \]
> Does that work for you?
>
> Cheers,
> Mike
>
> Chaitanya Krishna wrote:
>>
>> Forgot to mention the version in the last mail. I am using
>>
>> In [2]: matplotlib.__version__
>> Out[2]: '0.91.1'
>>
>> Cheers,
>> Chaitanya
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

You need to escape the [ ], e.g. \[ \] 

Does that work for you?

Cheers,
Mike

Chaitanya Krishna wrote:
> Forgot to mention the version in the last mail. I am using
>
> In [2]: matplotlib.__version__
> Out[2]: '0.91.1'
>
> Cheers,
> Chaitanya
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Forgot to mention the version in the last mail. I am using

In [2]: matplotlib.__version__
Out[2]: '0.91.1'

Cheers,
Chaitanya

Hi,

Thanks for the previous replies. They were very helpful.

I would like to use '[' and ']' in my ylabels. But, when I try to use
them I get the following error

Lots of tracebacks here ...
matplotlib.pyparsing.ParseFatalException: Expected end of math '$'
$V_{Fe_{53}M} - V_{Fe_{54}}\ \ [\AA^{3}]$ (at char 0), (line:1, col:1)

When I replace the [, ] with (, ), I have no problems. Is there any
work around to get the [, ]?

Cheers,
Chaitanya

That's what was happening! Thanks again Jeff!




________________________________
From: Jeff Whitaker <js...@fa...>
To: antonv <vas...@ya...>
Cc: mat...@li...
Sent: Tuesday, April 14, 2009 4:39:13 AM
Subject: Re: [Matplotlib-users] basemap error or user error?

antonv wrote:
> Jeff, thanks for the comment on rebuilding the lons and lats!
> 
> I have attached 2 images, one that is from the whole data in the file and
> the other the zoomed version. http://www.nabble.com/file/p23031035/basemap_all.png basemap_all.png http://www.nabble.com/file/p23031035/basemap_zoom.png basemap_zoom.png 
> What seems to be happening is that the coordinates seem to be in different
> projections as the values of lats.min(),lons.min(),lats.max(),lons.max() are 25.0,210.0,50.0,250.0 while the list I'm providing is
> 32.35,-121.0,34.75,-116.75. 

Anton:  Try using (32.35, 239,34.75,243.25).  The longitudes in your data probably go from 0 to 360, so negative longitudes are outside the region spanned by your data.

-Jeff
> Any ideas on why basemap seems to be reading
> both coordinate lists and provides the proper land contours while contourf
> seems to be off?
> 
> Thanks,
> Anton
> 
> 
> 
> 
> 
> 
> Jeff Whitaker wrote:
>  
>> antonv wrote:
>>    
>>> Hi all,
>>> 
>>> I have a weird thing happening with basemap and I am not sure if it's
>>> basemap or me, but more than likely it's me :(
>>> 
>>> Here is the grib file that I am using:
>>> http://downloads.75ive.com/multi_1.20090321.t18z_multi_1.wc_10m.all.grb2
>>> http://downloads.75ive.com/multi_1.20090321.t18z_multi_1.wc_10m.all.grb2 
>>> And here is my code:
>>> #############################################
>>> import matplotlib
>>> import matplotlib.mpl as mpl
>>> import matplotlib.pyplot as plt
>>> import matplotlib.mlab as mlab
>>> import numpy as np
>>> import matplotlib.pylab as pylab
>>> from mpl_toolkits.basemap import Basemap
>>> from grib2 import Grib2Decode
>>> 
>>> grbs = Grib2Decode('multi_1.20090321.t18z_multi_1.wc_10m.all.grb2')
>>> 
>>> lats, lons = grbs[0].grid()
>>> mapCoords = [32.35,-121.0,34.75,-116.75]
>>> #mapCoords = [lats.min(),lons.min(),lats.max(),lons.max()]
>>> 
>>> colorList =
>>> [[0.,0.,205./255.],[0,102./255.,255./255.],[0,183./255.,255./255.],[0,224./255.,255./255.],
>>>            [0,255./255.,255./255.],[0,255./255.,204./255.],[0,255./255.,153./255.],[0,255./255.,0],
>>>            [153./255.,255./255.,0],[204./255.,255./255.,0],[255./255.,255./255.,0],[255./255.,204./255.,0],
>>>            [255./255.,153./255.,0],[255./255.,102./255.,0],[255./255.,0,0],[176./255.,48./255.,96./255.],
>>>             [208./255.,32./255.,144./255.],[255./255.,0,255./255.]]
>>> cmap = matplotlib.colors.ListedColormap(colorList, name = 'theColorMap',
>>> N =
>>> len(colorList))
>>> 
>>> m = Basemap(projection='merc',lat_ts = 30,\
>>>            llcrnrlat=mapCoords[0],llcrnrlon=mapCoords[1],urcrnrlat=mapCoords[2],urcrnrlon=mapCoords[3],\
>>>             resolution='h',area_thresh=0.5, suppress_ticks = True)
>>> 
>>> fig = plt.figure(figsize=(14.58,10.58))
>>> fig.set_dpi(100)
>>> 
>>> nlats, nlons = grbs[0].data().shape
>>> 
>>> x = np.linspace(lons.min(),lons.max(),nlons)
>>> y = np.linspace(lats.min(),lats.max(),nlats)
>>> 
>>> X, Y = m(*np.meshgrid(x, y))
>>> 
>>> z = grbs[0].data().filled(1)
>>> 
>>> m.contourf(X,Y,z,cmap=cmap,levels=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19],extend='both')
>>> 
>>> m.fillcontinents(color='green',lake_color='b')
>>> m.drawcoastlines(color='k', linewidth=0.75)
>>> m.drawcountries(color='k', linewidth=0.25)
>>> m.drawstates(color='k', linewidth=0.25)
>>> m.drawmapboundary(linewidth=1.0, color='k')
>>> 
>>> plt.show()
>>> #############################################
>>> 
>>> If you look at lines 14 and 15 you can see that i have a variable called
>>> mapCoords that feeds the lat/lon coordinates to the basemap object. If i
>>> set
>>> them up using the commented line (line 15) it will plot the map for all
>>> the
>>> data in the file and it will display it correctly. If i use line 14 which
>>> is
>>> the zoomed area that i am interested in it will display the basemap map
>>> correctly zoomed in but it will not show the plotted data. Any ideas on
>>> what
>>> is happening here?
>>> 
>>> Also, if you have any comments on optimizing the code I would really
>>> appreciate it!
>>> 
>>> Thanks,
>>> Anton
>>> 
>>>        
>> Anton:  Probably your data doesn't cover the zoomed region, but without actually having your data  I can't be sure. 
>> One question:  why are you rebuilding the lons and lats from scratch when you already have them?  It seems like you can get rid of
>> 
>> nlats, nlons = grbs[0].data().shape
>> x = np.linspace(lons.min(),lons.max(),nlons)
>> y = np.linspace(lats.min(),lats.max(),nlats)
>> X, Y = m(*np.meshgrid(x, y))
>> 
>> and replace it with
>> 
>> X,Y = m(lons, lats)
>> 
>> 
>> -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-113
>> Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
>> 
>> 
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
>> 
>>    
> 
>  


      

On Tue, Apr 14, 2009 at 8:34 AM, Ryan May <rm...@gm...> wrote:

> I don't think matplotlib supports anything like this out of the box.
> However, you should be able to do this by subclassing the Formatter class in
> matplotlib/ticker.py.  I believe Chaco has support for ticking like this for
> dates, so you could look to it for inspiration on how to go about
> implementing the concept.

Here is the code for the autodateformatter (scale is in days).
Perhaps you can just tweak it to work like you want and then set you
custom formatter with

  ax.xaxis.set_major_formatter(myformatter)


   class AutoDateFormatter(ticker.Formatter):
       """
       This class attempts to figure out the best format to use.  This is
       most useful when used with the :class:`AutoDateLocator`.
       """

       # This can be improved by providing some user-level direction on
       # how to choose the best format (precedence, etc...)

       # Perhaps a 'struct' that has a field for each time-type where a
       # zero would indicate "don't show" and a number would indicate
       # "show" with some sort of priority.  Same priorities could mean
       # show all with the same priority.

       # Or more simply, perhaps just a format string for each
       # possibility...

       def __init__(self, locator, tz=None):
           self._locator = locator
              self._formatter = DateFormatter("%b %d %Y %H:%M:%S %Z", tz)
              self._tz = tz

          def __call__(self, x, pos=0):
              scale = float( self._locator._get_unit() )

              if ( scale == 365.0 ):
                  self._formatter = DateFormatter("%Y", self._tz)
              elif ( scale == 30.0 ):
                  self._formatter = DateFormatter("%b %Y", self._tz)
              elif ( (scale == 1.0) or (scale == 7.0) ):
                  self._formatter = DateFormatter("%b %d %Y", self._tz)
              elif ( scale == (1.0/24.0) ):
                  self._formatter = DateFormatter("%H:%M:%S %Z", self._tz)
              elif ( scale == (1.0/(24*60)) ):
                  self._formatter = DateFormatter("%H:%M:%S %Z", self._tz)
              elif ( scale == (1.0/(24*3600)) ):
                  self._formatter = DateFormatter("%H:%M:%S %Z", self._tz)
              else:
                  self._formatter = DateFormatter("%b %d %Y %H:%M:%S
%Z", self._tz)

           return self._formatter(x, pos)


JDH

On Tue, Apr 14, 2009 at 8:56 AM, Ryan May <rm...@gm...> wrote:

> Also, you can use itertools.cycle to loop over a set of markers probably a
> bit more cleanly than the example:
>
> markers = itertools.cycle(lines.Line2D.markers.keys())
> marker = markers.next()


Yes, that is better that the somewhat opaque i%N trick.  And the call
to "keys()" is unnecessary because the iterator will cycle over the
keys of the dict anyhow, but I think it makes it a little clearer what
kind of data structure you are working with.

JDH

On Tue, Apr 14, 2009 at 8:50 AM, John Hunter <jd...@gm...> wrote:

> On Tue, Apr 14, 2009 at 8:09 AM, Chaitanya Krishna <ic...@gm...>
> wrote:
> > Hello all,
> >
> > Usually when I plot two or more lines, the color of the lines change.
> > Is it possible to change this default behavior so that when I plot two
> > or more lines, the symbols change and not the color.
> >
> > This would be useful if someone is trying to make plots in black and
> > white so that the symbols change instead of line colors.
>
> You can do this with a little manual intervention -- below is a script
> which cycles through all of mpl's line markers.
>
>    import numpy as np
>    import matplotlib.lines as lines
>    import matplotlib.pyplot as plt
>
>    markers = list(lines.Line2D.markers.keys())
>    markers.sort()
>    N = len(markers)
>
>    fig = plt.figure()
>    ax = fig.add_subplot(111)
>    x = np.arange(20)
>    for i in range(50):
>        marker = markers[i%N]
>        print marker
>        y = i*x
>        ax.plot(x, y, marker=marker, linestyle='', mfc='blue')
>
>    plt.show()
>
> You could do a similar trick with linestyles using the
> lines.Line2D.lineStyles and lines.Line2D.drawStyles dictionaries
> (these map the symbols to the internal Line2D function we use to draw
> the symbols).  See also
>
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/line_styles.html


Also, you can use itertools.cycle to loop over a set of markers probably a
bit more cleanly than the example:

markers = itertools.cycle(lines.Line2D.markers.keys())
marker = markers.next()

Ryan


-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

On Tue, Apr 14, 2009 at 8:09 AM, Chaitanya Krishna <ic...@gm...> wrote:
> Hello all,
>
> Usually when I plot two or more lines, the color of the lines change.
> Is it possible to change this default behavior so that when I plot two
> or more lines, the symbols change and not the color.
>
> This would be useful if someone is trying to make plots in black and
> white so that the symbols change instead of line colors.

You can do this with a little manual intervention -- below is a script
which cycles through all of mpl's line markers.

    import numpy as np
    import matplotlib.lines as lines
    import matplotlib.pyplot as plt

    markers = list(lines.Line2D.markers.keys())
    markers.sort()
    N = len(markers)

    fig = plt.figure()
    ax = fig.add_subplot(111)
    x = np.arange(20)
    for i in range(50):
        marker = markers[i%N]
        print marker
        y = i*x
        ax.plot(x, y, marker=marker, linestyle='', mfc='blue')

    plt.show()

You could do a similar trick with linestyles using the
lines.Line2D.lineStyles and lines.Line2D.drawStyles dictionaries
(these map the symbols to the internal Line2D function we use to draw
the symbols).  See also

  http://matplotlib.sourceforge.net/examples/pylab_examples/line_styles.html


JDH

>
> Regards,
> Chaitanya
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Mon, Apr 13, 2009 at 5:34 PM, C M <cmp...@gm...> wrote:

> Hi, I've asked this before but still am stuck.  I want to use
> mpl's automatic tick locating and date formatting for a zoomable
> date plot, OTHER THAN the hour formatting.  The default hour formatting
> (when zoomed in on 1 day) is like "05:00:00 UTC", but I'd like to be
> of the form something more readable for users, like: "5:00pm 12/03".
>
> If I just use my own custom date formatter, then ALL the zoom levels
> will have this format, but I'd only like it for when the plot is zoomed
> down to the level of one day.  (So it is a rule of "if zoomed to one day,
> use my custom dateformatter, otherwise, use the automatic one").
>
> Why I'd like this:  for looking across weeks or months worth of data,
> hours are irrelevant, but for looking at days, hours are relevant, but
> users will not think in terms of UTC and they will want to see on the
> x axis which day they are looking at.
>
> Does anyone know how this can be done in mpl?  Thank you,


I don't think matplotlib supports anything like this out of the box.
However, you should be able to do this by subclassing the Formatter class in
matplotlib/ticker.py.  I believe Chaco has support for ticking like this for
dates, so you could look to it for inspiration on how to go about
implementing the concept.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hello all,

Usually when I plot two or more lines, the color of the lines change.
Is it possible to change this default behavior so that when I plot two
or more lines, the symbols change and not the color.

This would be useful if someone is trying to make plots in black and
white so that the symbols change instead of line colors.

Regards,
Chaitanya

Andres Luhamaa wrote:
> Hello!
> I have a problem writing postscript output from a high resolution map. 
> It does not give any error, but output file gives a lot of errors while 
> I open it with gv. The following example works for basemap resolution 
> 'i', but not with resolution 'f'. Any ideas what I should do in a 
> different way or are there known limitations in PS or a bug?
>
> Andres
>   

Andres:  Works for me (using SVN trunk), so the bug in the ps backend 
must have been fixed since the last release.

-Jeff
> #!/usr/bin/env 
> python                                                          
> import numpy as np
> import matplotlib
> matplotlib.use( 'PS' )
> from mpl_toolkits.basemap import Basemap
> import os
> import matplotlib.pyplot
> import pylab as plt
> import matplotlib.colors as colors
> fig=plt.figure()
> m=Basemap(llcrnrlon=0.83513989,llcrnrlat=53.49684419,urcrnrlon=55.00709304,urcr\
> nrlat=64.88386147,
>         projection='lcc',lat_0=60,lon_0=0.,
>           resolution ='i'
> #          
> ,area_thresh=100.                                                   
>           )
> m.drawcoastlines()
> m.drawcountries()
> m.drawmapboundary()
> m.drawparallels([40,50,60,70],labels=[1,0,0,1])
> m.drawmeridians([-160,-140,-120,-100,-80,-60,-40,-20,0,20,40,60,80,100,120,140,\
> 160,180],labels=[0,1,0,1])
> plt.savefig('surfgeopot.eps')
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

antonv wrote:
> Jeff, thanks for the comment on rebuilding the lons and lats!
>
> I have attached 2 images, one that is from the whole data in the file and
> the other the zoomed version. 
> http://www.nabble.com/file/p23031035/basemap_all.png basemap_all.png 
> http://www.nabble.com/file/p23031035/basemap_zoom.png basemap_zoom.png 
>
> What seems to be happening is that the coordinates seem to be in different
> projections as the values of lats.min(),lons.min(),lats.max(),lons.max() are 
> 25.0,210.0,50.0,250.0 while the list I'm providing is
> 32.35,-121.0,34.75,-116.75. 

Anton:  Try using (32.35, 239,34.75,243.25).  The longitudes in your 
data probably go from 0 to 360, so negative longitudes are outside the 
region spanned by your data.

-Jeff
> Any ideas on why basemap seems to be reading
> both coordinate lists and provides the proper land contours while contourf
> seems to be off?
>
> Thanks,
> Anton
>
>
>
>
>
>
> Jeff Whitaker wrote:
>   
>> antonv wrote:
>>     
>>> Hi all,
>>>
>>> I have a weird thing happening with basemap and I am not sure if it's
>>> basemap or me, but more than likely it's me :(
>>>
>>> Here is the grib file that I am using:
>>> http://downloads.75ive.com/multi_1.20090321.t18z_multi_1.wc_10m.all.grb2
>>> http://downloads.75ive.com/multi_1.20090321.t18z_multi_1.wc_10m.all.grb2 
>>>
>>> And here is my code:
>>> #############################################
>>> import matplotlib
>>> import matplotlib.mpl as mpl
>>> import matplotlib.pyplot as plt
>>> import matplotlib.mlab as mlab
>>> import numpy as np
>>> import matplotlib.pylab as pylab
>>> from mpl_toolkits.basemap import Basemap
>>> from grib2 import Grib2Decode
>>>
>>> grbs = Grib2Decode('multi_1.20090321.t18z_multi_1.wc_10m.all.grb2')
>>>
>>> lats, lons = grbs[0].grid()
>>> mapCoords = [32.35,-121.0,34.75,-116.75]
>>> #mapCoords = [lats.min(),lons.min(),lats.max(),lons.max()]
>>>
>>> colorList =
>>> [[0.,0.,205./255.],[0,102./255.,255./255.],[0,183./255.,255./255.],[0,224./255.,255./255.],
>>>            
>>> [0,255./255.,255./255.],[0,255./255.,204./255.],[0,255./255.,153./255.],[0,255./255.,0],
>>>            
>>> [153./255.,255./255.,0],[204./255.,255./255.,0],[255./255.,255./255.,0],[255./255.,204./255.,0],
>>>            
>>> [255./255.,153./255.,0],[255./255.,102./255.,0],[255./255.,0,0],[176./255.,48./255.,96./255.],
>>>             [208./255.,32./255.,144./255.],[255./255.,0,255./255.]]
>>> cmap = matplotlib.colors.ListedColormap(colorList, name = 'theColorMap',
>>> N =
>>> len(colorList))
>>>
>>> m = Basemap(projection='merc',lat_ts = 30,\
>>>            
>>> llcrnrlat=mapCoords[0],llcrnrlon=mapCoords[1],urcrnrlat=mapCoords[2],urcrnrlon=mapCoords[3],\
>>>             resolution='h',area_thresh=0.5, suppress_ticks = True)
>>>
>>> fig = plt.figure(figsize=(14.58,10.58))
>>> fig.set_dpi(100)
>>>
>>> nlats, nlons = grbs[0].data().shape
>>>
>>> x = np.linspace(lons.min(),lons.max(),nlons)
>>> y = np.linspace(lats.min(),lats.max(),nlats)
>>>
>>> X, Y = m(*np.meshgrid(x, y))
>>>
>>> z = grbs[0].data().filled(1)
>>>
>>> m.contourf(X,Y,z,cmap=cmap,levels=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19],extend='both')
>>>
>>> m.fillcontinents(color='green',lake_color='b')
>>> m.drawcoastlines(color='k', linewidth=0.75)
>>> m.drawcountries(color='k', linewidth=0.25)
>>> m.drawstates(color='k', linewidth=0.25)
>>> m.drawmapboundary(linewidth=1.0, color='k')
>>>
>>> plt.show()
>>> #############################################
>>>
>>> If you look at lines 14 and 15 you can see that i have a variable called
>>> mapCoords that feeds the lat/lon coordinates to the basemap object. If i
>>> set
>>> them up using the commented line (line 15) it will plot the map for all
>>> the
>>> data in the file and it will display it correctly. If i use line 14 which
>>> is
>>> the zoomed area that i am interested in it will display the basemap map
>>> correctly zoomed in but it will not show the plotted data. Any ideas on
>>> what
>>> is happening here?
>>>
>>> Also, if you have any comments on optimizing the code I would really
>>> appreciate it!
>>>
>>> Thanks,
>>> Anton
>>>
>>>   
>>>       
>> Anton:  Probably your data doesn't cover the zoomed region, but without 
>> actually having your data  I can't be sure. 
>>
>> One question:  why are you rebuilding the lons and lats from scratch 
>> when you already have them?  It seems like you can get rid of
>>
>> nlats, nlons = grbs[0].data().shape
>> x = np.linspace(lons.min(),lons.max(),nlons)
>> y = np.linspace(lats.min(),lats.max(),nlats)
>> X, Y = m(*np.meshgrid(x, y))
>>
>> and replace it with
>>
>> X,Y = m(lons, lats)
>>
>>
>> -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-113
>> Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>     
>
>   

Hello!
I have a problem writing postscript output from a high resolution map. 
It does not give any error, but output file gives a lot of errors while 
I open it with gv. The following example works for basemap resolution 
'i', but not with resolution 'f'. Any ideas what I should do in a 
different way or are there known limitations in PS or a bug?

Andres

#!/usr/bin/env 
python                                                          
import numpy as np
import matplotlib
matplotlib.use( 'PS' )
from mpl_toolkits.basemap import Basemap
import os
import matplotlib.pyplot
import pylab as plt
import matplotlib.colors as colors
fig=plt.figure()
m=Basemap(llcrnrlon=0.83513989,llcrnrlat=53.49684419,urcrnrlon=55.00709304,urcr\
nrlat=64.88386147,
        projection='lcc',lat_0=60,lon_0=0.,
          resolution ='i'
#          
,area_thresh=100.                                                   
          )
m.drawcoastlines()
m.drawcountries()
m.drawmapboundary()
m.drawparallels([40,50,60,70],labels=[1,0,0,1])
m.drawmeridians([-160,-140,-120,-100,-80,-60,-40,-20,0,20,40,60,80,100,120,140,\
160,180],labels=[0,1,0,1])
plt.savefig('surfgeopot.eps')

Thanks for the suggestion. Apt-get build-dep did help a little bit, but it
alone did not solve the problem because the 0.98.5.2 version of Matplotlib
depended on things that were not listed as dependencies for 0.91.1, which is
what apt-get could see from the normal repositories.

A friend ultimately helped work through a couple bugs in a couple of the
dependencies, and then we were able to build and install Matplotlib 0.98.5.2
from the source.

Thanks.


Michael Droettboom-3 wrote:
> 
> One of the cool things about Debian-esque distros is you can say:
> 
>   apt-get build-dep python-matplotlib
> 
> which will install all of the build dependencies for matplotlib.  It 
> will download a lot, but if bandwidth/disk space is not an issue, it's 
> nicely automated.
> 
> That's one of the first things I do on any new Ubuntu or Debian install 
> -- and then I check out matplotlib from source or SVN and build with no 
> problems.
> 
> Cheers,
> Mike
> 
-- 
View this message in context: http://www.nabble.com/How-do-I-install-Matplotlib-0.98-on-Ubuntu-8.04-Hardy-Heron--tp22996008p23034258.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Jeff, thanks for the comment on rebuilding the lons and lats!

I have attached 2 images, one that is from the whole data in the file and
the other the zoomed version. 
http://www.nabble.com/file/p23031035/basemap_all.png basemap_all.png 
http://www.nabble.com/file/p23031035/basemap_zoom.png basemap_zoom.png 

What seems to be happening is that the coordinates seem to be in different
projections as the values of lats.min(),lons.min(),lats.max(),lons.max() are 
25.0,210.0,50.0,250.0 while the list I'm providing is
32.35,-121.0,34.75,-116.75. Any ideas on why basemap seems to be reading
both coordinate lists and provides the proper land contours while contourf
seems to be off?

Thanks,
Anton






Jeff Whitaker wrote:
> 
> antonv wrote:
>> Hi all,
>>
>> I have a weird thing happening with basemap and I am not sure if it's
>> basemap or me, but more than likely it's me :(
>>
>> Here is the grib file that I am using:
>> http://downloads.75ive.com/multi_1.20090321.t18z_multi_1.wc_10m.all.grb2
>> http://downloads.75ive.com/multi_1.20090321.t18z_multi_1.wc_10m.all.grb2 
>>
>> And here is my code:
>> #############################################
>> import matplotlib
>> import matplotlib.mpl as mpl
>> import matplotlib.pyplot as plt
>> import matplotlib.mlab as mlab
>> import numpy as np
>> import matplotlib.pylab as pylab
>> from mpl_toolkits.basemap import Basemap
>> from grib2 import Grib2Decode
>>
>> grbs = Grib2Decode('multi_1.20090321.t18z_multi_1.wc_10m.all.grb2')
>>
>> lats, lons = grbs[0].grid()
>> mapCoords = [32.35,-121.0,34.75,-116.75]
>> #mapCoords = [lats.min(),lons.min(),lats.max(),lons.max()]
>>
>> colorList =
>> [[0.,0.,205./255.],[0,102./255.,255./255.],[0,183./255.,255./255.],[0,224./255.,255./255.],
>>            
>> [0,255./255.,255./255.],[0,255./255.,204./255.],[0,255./255.,153./255.],[0,255./255.,0],
>>            
>> [153./255.,255./255.,0],[204./255.,255./255.,0],[255./255.,255./255.,0],[255./255.,204./255.,0],
>>            
>> [255./255.,153./255.,0],[255./255.,102./255.,0],[255./255.,0,0],[176./255.,48./255.,96./255.],
>>             [208./255.,32./255.,144./255.],[255./255.,0,255./255.]]
>> cmap = matplotlib.colors.ListedColormap(colorList, name = 'theColorMap',
>> N =
>> len(colorList))
>>
>> m = Basemap(projection='merc',lat_ts = 30,\
>>            
>> llcrnrlat=mapCoords[0],llcrnrlon=mapCoords[1],urcrnrlat=mapCoords[2],urcrnrlon=mapCoords[3],\
>>             resolution='h',area_thresh=0.5, suppress_ticks = True)
>>
>> fig = plt.figure(figsize=(14.58,10.58))
>> fig.set_dpi(100)
>>
>> nlats, nlons = grbs[0].data().shape
>>
>> x = np.linspace(lons.min(),lons.max(),nlons)
>> y = np.linspace(lats.min(),lats.max(),nlats)
>>
>> X, Y = m(*np.meshgrid(x, y))
>>
>> z = grbs[0].data().filled(1)
>>
>> m.contourf(X,Y,z,cmap=cmap,levels=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19],extend='both')
>>
>> m.fillcontinents(color='green',lake_color='b')
>> m.drawcoastlines(color='k', linewidth=0.75)
>> m.drawcountries(color='k', linewidth=0.25)
>> m.drawstates(color='k', linewidth=0.25)
>> m.drawmapboundary(linewidth=1.0, color='k')
>>
>> plt.show()
>> #############################################
>>
>> If you look at lines 14 and 15 you can see that i have a variable called
>> mapCoords that feeds the lat/lon coordinates to the basemap object. If i
>> set
>> them up using the commented line (line 15) it will plot the map for all
>> the
>> data in the file and it will display it correctly. If i use line 14 which
>> is
>> the zoomed area that i am interested in it will display the basemap map
>> correctly zoomed in but it will not show the plotted data. Any ideas on
>> what
>> is happening here?
>>
>> Also, if you have any comments on optimizing the code I would really
>> appreciate it!
>>
>> Thanks,
>> Anton
>>
>>   
> Anton:  Probably your data doesn't cover the zoomed region, but without 
> actually having your data  I can't be sure. 
> 
> One question:  why are you rebuilding the lons and lats from scratch 
> when you already have them?  It seems like you can get rid of
> 
> nlats, nlons = grbs[0].data().shape
> x = np.linspace(lons.min(),lons.max(),nlons)
> y = np.linspace(lats.min(),lats.max(),nlats)
> X, Y = m(*np.meshgrid(x, y))
> 
> and replace it with
> 
> X,Y = m(lons, lats)
> 
> 
> -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-113
> Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
View this message in context: http://www.nabble.com/basemap-error-or-user-error--tp23017806p23031035.html
Sent from the matplotlib - users mailing list archive at Nabble.com.