matplotlib-users Mailing List for matplotlib (Page 6)

I have tried to install matplotlib but received an error msg that I need
python 2.7.
I installed 2.7, then installed matplotlib for appropriate os, but recieved
error msg when I ran my program.  Then, searching, I am seeing there are
some that have installed matplotlib for mac osx and python 2.6

Can someone direct me to a useful link to learn more, or does someone have
info about this, like what I am overlooking or missing?
thanks,
lulu



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/installating-matplotlib-in-mac-10-7-4-for-python-2-6-tp39436.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

That's also what that snippet I linked does. You can add it to to Basemap
and it should work.

However Jeff suggested we use this tiny package OWSlib and handle WMS that
way, which is better IMHO, but for some reason we did not got further reply.


On Fri, Oct 12, 2012 at 1:31 PM, Rich Signell <rsi...@us...> wrote:

> WMS services are required to respond to  "GetCapabiltiies" request,
> reporting what layers, styles, times, elevations, and projections they
> have available.  So for example, using the Unidata WMS example below,
> if we do:
>
>
> http://motherlode.ucar.edu:8080/thredds/wms/fmrc/NCEP/NAM/CONUS_12km/NCEP-NAM-CONUS_12km-noaaport_best.ncd?service=WMS&request=GetCapabilities
>
> we can see from the XML response that the Coordinate Reference Systems
> supported are:
>
> <CRS>EPSG:4326</CRS>
> <CRS>CRS:84</CRS>
> <CRS>EPSG:41001</CRS>
> <CRS>EPSG:3857</CRS>
> <CRS>EPSG:27700</CRS>
> <CRS>EPSG:3408</CRS>
> <CRS>EPSG:3409</CRS>
> <CRS>EPSG:32661</CRS>
> <CRS>EPSG:32761</CRS>
>
> And for this server, the supported response types are:
> <Format>image/jpeg</Format>
> <Format>image/png</Format>
> <Format>application/vnd.google-earth.kmz</Format>
> <Format>image/gif</Format>
>
> So I guess one way to proceed if you wanted to use WMS in Matplotlib
> and avoid reprojection in python would be to:
> 1. do the WMS GetCapabilities request to find the available supported
> Coordinate Reference Systems (which will vary with WMS server)
> 2. setup Basemap to use one of these CRS
> 3. use the bounding box of your current axis (in projection units) as
> part of a GetMap request to the WMS.
>
> -Rich
>
> On Thu, Oct 11, 2012 at 12:16 AM, klo uo <kl...@gm...> wrote:
> > I guess that's it?
> >
> > warpimage() as it is now, checks if passed image is url, so we can add
> > additional check if image is url, with urlparse to deduce image
> coordinates
> > and projection if present, then overlay it over already created Basemap
> > object.
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>
>
>
> --
> Dr. Richard P. Signell   (508) 457-2229
> USGS, 384 Woods Hole Rd.
> Woods Hole, MA 02543-1598
>

That's right.  The problem with having it on the front page is that it 
doesn't allow us to provide copies of that information for different 
versions of matplotlib.  It is linked to from the front page, however.

Mike

On 10/13/2012 06:20 AM, Kevin Davies wrote:
> I noticed that the list of matplotlib.pyplot methods has moved on the 
> website.  I used to rely on it for quick information, but now Google 
> doesn't even return it easily.  For the record, the information now 
> seems to be at http://matplotlib.org/api/pyplot_summary.html.
>
> Kevin
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I noticed that the list of matplotlib.pyplot methods has moved on
    the website.&nbsp; I used to rely on it for quick information, but now
    Google doesn't even return it easily.&nbsp; For the record, the
    information now seems to be at
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="http://matplotlib.org/api/pyplot_summary.html">http://matplotlib.org/api/pyplot_summary.html</a>.<br>
    <br>
    Kevin<br>
    <br>
    <br>
  </body>
</html>

Forgot to reply all.

---------- Forwarded message ----------
From: *Damon McDougall*
Date: Friday, October 12, 2012
Subject: [Matplotlib-users] color pallette suggestions wanted
To: Andreas Hilboll <li...@hi...>


On Fri, Oct 12, 2012 at 10:17 AM, Andreas Hilboll
<li...@hi...<javascript:;>>
wrote:
> Hi,
>
> I have some data I want to plot using pcolormesh. It's 2d climatological
> data, see the attached plot. My data is in a range from -7 to +0.6. I want
> to be 0.0 to be clearly visible, while at the same time, the color range
> should show the full dynamic of the values. I played with the bwr and
> seismic color maps, centering on zero, so that white is 0.0. However, I'm
> not too happy with the dynamic range I get in the negative.

Your data is not symmetric about zero, so you will always get a result
the looks 'too dynamic' in the negative values (that is, if you want
to use the whole colour map range). You need to make a sacrifice
somewhere to get the effect you want.

1) Move your data so it's symmetric around zero, that way you'll get a
nice dynamic change, but the position of 'zero' will be less clear.

2) Don't move your data and use a truncated colour map. That way the
position of 'zero' will be clear but you'll get less dynamic change in
the negative values.

Hope this helps.

Best,
Damon

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom



-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On 13/10/2012 00:37, Ethan Gutmann wrote:
> On Oct 12, 2012, at 4:15 PM, Mark Lawrence wrote:
>
>> On 12/10/2012 20:38, Ethan Gutmann wrote:
>>>
>>> I'm a little confused by this attitude.  I recognize that there are issues around dates, I've written a few date libraries myself to get around insane excel date issues (pop quiz for anyone at MS, was 1900 a leap year?) or just to simplify APIs for my own use.  But do neither of you think that nanoseconds are important to scientists?  I know of enough projects that work with pico (and a few with femto) seconds.  Even though I often work with climate data covering ~100s of years and used to work with geologic data covering ~billions of years, I may start working with raw laser data for distance measurements where nanoseconds can be a pretty big deal.  These data would be collected over a few years time, so a date utility that can handle that scale range would be useful.  I guess I'll be
>   writing my own date/time library again and hacking together some way of plotting data in a meaningful way in matplotlib.
>>>
>>> Don't get me wrong, matplotlib shouldn't have to reinvent the wheel here, but claiming that nobody could possibly care about 1e-12 seconds seems a little provincial.  My apologies if that is not how the above statements were intended.
>>>
>>> regards,
>>> Ethan
>>>
>>>
>>
>> I actually said "What percentage of computer users wants a delta of
>> 1e-12?  I suspect that the vast majority of users couldn't care two
>> hoots about miniscule time deltas in a world where changing time zones
>> can cause chaos...".
>>
>> How does this translate into "claiming that nobody could possibly care
>> about 1e-12 seconds seems a little provincial"?
>>
>> --
>> Cheers.
>>
>> Mark Lawrence.
>
> Like I said, my apologies if I mis-interpreted.  To me the statement "the vast majority of users couldn't care two hoots..." *implies* "since almost nobody needs this we won't worry about it", especially when it is in response to someone who felt this was an important feature:
> "A delta of 1e-9 is the *least* I'd expect. Maybe even 1e-12. ".
> My response was as much an issue with how I perceived the tone as anything else (obviously, tone doesn't cary well over email ;) )
>
> Don't get me wrong, I realize there are bigger fish to fry.  I just want add a vote that 1E-12 seconds (and less) can indeed be important to a significant number of people.  I suspect that many experimental physicists would be unable to use a time utility that can't handle those timescales.  Many of them will simply write there own utility, but then if they start running into any of the longer time scale issues e.g. leap years/seconds etc. they end up having to reinvent the wheel.  Others have also pointed out that databases[1], network packets and stock trading transactions[2] may care about nanoseconds.
>
> [1]http://code.activestate.com/lists/python-dev/117090/
> [2]http://code.activestate.com/lists/python-dev/117091/
>
> I'm glad to see that others are thinking about this and that future python versions may get down to nanosecond (or better?) resolution, though I haven't found the PEP for it yet.  Guido seems to have given his approval for more work on the matter at least : http://code.activestate.com/lists/python-dev/117147/
>
> PEP 418 mentioned before doesn't mention the date time class as far as I can tell.  http://www.python.org/dev/peps/pep-0418/
>
> regards,
> Ethan
>

I know that there are 1000s times more people dealing with order 
processing systems who want to know the number of working days including 
bank holidays in which to get their order processed than experimental 
physicists playing with relatively nothing.  You only have to look at 
the UK for real world problems like this as bank holidays are different 
in England and Wales when compared to both Scotland and Northern Ireland.

 From PEP 418 "This PEP proposes to add time.get_clock_info(name), 
time.monotonic(), time.perf_counter() and time.process_time() functions 
to Python 3.3."  I've checked and the functions have all been 
implemented in Python 3.3.  If they're inadequate patches are always 
welcome.

-- 
Cheers.

Mark Lawrence.

Andreas,

Perhaps you would be better off making your own colormap considering that
your data is not symmetric around zero. You could do something like the
following:

--------------------------------------
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.colors as plc

data = np.random.randn(12,72)
data = data*5. - 5.

zero =  -1*data.min()/(data.max() - data.min())

cdict = {'red':   [(0.0, 1.0, 1.0),
                  (zero, 1.0, 1.0),
                  (1.0, 0.0, 0.0)],
         'green': [(0.0, 0.0, 0.0),
                  (zero, 1.0, 1.0),
                  (1.0, 0.0, 0.0)],
         'blue':  [(0.0, 0.0, 0.0),
                  (zero, 1.0, 1.0),
                  (1.0, 1.0, 0.0)],
         }

cmap = plc.LinearSegmentedColormap('cmap', cdict, N=1000)
mappable = plt.cm.ScalarMappable(cmap=cmap)
mappable.set_array(data)

fig = plt.figure()
plt.pcolormesh(data, cmap=cmap)
fig.colorbar(mappable)

plt.show()
--------------------------------------

Of course, the zero calculation assumes that zero actually exists in your
data set. That can be fixed with a simple if...else statement if you want
this to be more robust.

You can get rid of a few lines from this code if you don't want to set a
ScalarMappable object. However, I was doing some stuff with line
collections where I wanted some colors to have an alpha associated with
them, and I found that I was losing that info with the simpler pyplot
interface for colorbar generation. So I left in the slightly more complex
code for reference. (This might be changed in newer versions of mpl, I just
haven't needed to rework my code to check.)

Ryan

On Fri, Oct 12, 2012 at 4:17 AM, Andreas Hilboll <li...@hi...> wrote:

> Hi,
>
> I have some data I want to plot using pcolormesh. It's 2d climatological
> data, see the attached plot. My data is in a range from -7 to +0.6. I want
> to be 0.0 to be clearly visible, while at the same time, the color range
> should show the full dynamic of the values. I played with the bwr and
> seismic color maps, centering on zero, so that white is 0.0. However, I'm
> not too happy with the dynamic range I get in the negative.
>
> Any suggestions are very welcome ...
>
> Cheers, Andreas.
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On Oct 12, 2012, at 4:15 PM, Mark Lawrence wrote:

> On 12/10/2012 20:38, Ethan Gutmann wrote:
>> 
>> I'm a little confused by this attitude.  I recognize that there are issues around dates, I've written a few date libraries myself to get around insane excel date issues (pop quiz for anyone at MS, was 1900 a leap year?) or just to simplify APIs for my own use.  But do neither of you think that nanoseconds are important to scientists?  I know of enough projects that work with pico (and a few with femto) seconds.  Even though I often work with climate data covering ~100s of years and used to work with geologic data covering ~billions of years, I may start working with raw laser data for distance measurements where nanoseconds can be a pretty big deal.  These data would be collected over a few years time, so a date utility that can handle that scale range would be useful.  I guess I'll be writing my own date/time library again and hacking together some way of plotting data in a meaningful way in matplotlib.
>> 
>> Don't get me wrong, matplotlib shouldn't have to reinvent the wheel here, but claiming that nobody could possibly care about 1e-12 seconds seems a little provincial.  My apologies if that is not how the above statements were intended.
>> 
>> regards,
>> Ethan
>> 
>> 
> 
> I actually said "What percentage of computer users wants a delta of 
> 1e-12?  I suspect that the vast majority of users couldn't care two 
> hoots about miniscule time deltas in a world where changing time zones 
> can cause chaos...".
> 
> How does this translate into "claiming that nobody could possibly care 
> about 1e-12 seconds seems a little provincial"?
> 
> -- 
> Cheers.
> 
> Mark Lawrence.

Like I said, my apologies if I mis-interpreted.  To me the statement "the vast majority of users couldn't care two hoots..." *implies* "since almost nobody needs this we won't worry about it", especially when it is in response to someone who felt this was an important feature: 
"A delta of 1e-9 is the *least* I'd expect. Maybe even 1e-12. ".  
My response was as much an issue with how I perceived the tone as anything else (obviously, tone doesn't cary well over email ;) )  

Don't get me wrong, I realize there are bigger fish to fry.  I just want add a vote that 1E-12 seconds (and less) can indeed be important to a significant number of people.  I suspect that many experimental physicists would be unable to use a time utility that can't handle those timescales.  Many of them will simply write there own utility, but then if they start running into any of the longer time scale issues e.g. leap years/seconds etc. they end up having to reinvent the wheel.  Others have also pointed out that databases[1], network packets and stock trading transactions[2] may care about nanoseconds.  

[1]http://code.activestate.com/lists/python-dev/117090/
[2]http://code.activestate.com/lists/python-dev/117091/

I'm glad to see that others are thinking about this and that future python versions may get down to nanosecond (or better?) resolution, though I haven't found the PEP for it yet.  Guido seems to have given his approval for more work on the matter at least : http://code.activestate.com/lists/python-dev/117147/  

PEP 418 mentioned before doesn't mention the date time class as far as I can tell.  http://www.python.org/dev/peps/pep-0418/ 

regards,
Ethan

On 12/10/2012 20:38, Ethan Gutmann wrote:
>
> I'm a little confused by this attitude.  I recognize that there are issues around dates, I've written a few date libraries myself to get around insane excel date issues (pop quiz for anyone at MS, was 1900 a leap year?) or just to simplify APIs for my own use.  But do neither of you think that nanoseconds are important to scientists?  I know of enough projects that work with pico (and a few with femto) seconds.  Even though I often work with climate data covering ~100s of years and used to work with geologic data covering ~billions of years, I may start working with raw laser data for distance measurements where nanoseconds can be a pretty big deal.  These data would be collected over a few years time, so a date utility that can handle that scale range would be useful.  I guess I'll be writing my own date/time library again and hacking together some way of plotting data in a meaningful way in matplotlib.
>
> Don't get me wrong, matplotlib shouldn't have to reinvent the wheel here, but claiming that nobody could possibly care about 1e-12 seconds seems a little provincial.  My apologies if that is not how the above statements were intended.
>
> regards,
> Ethan
>
>

I actually said "What percentage of computer users wants a delta of 
1e-12?  I suspect that the vast majority of users couldn't care two 
hoots about miniscule time deltas in a world where changing time zones 
can cause chaos...".

How does this translate into "claiming that nobody could possibly care 
about 1e-12 seconds seems a little provincial"?

-- 
Cheers.

Mark Lawrence.

On Fri, Oct 12, 2012 at 10:55 AM, Andreas Hilboll <li...@hi...> wrote:
> Hi,
>
> another question. Given the plot from my last email (I attached the code
> to this one as well), I would like to have the x-labels ("J", "F", ...)
> not at the location of the xticks, but centered in between to xticks. I
> would then move the xticks so that they form the bins to the data chunks,
> and the labels should be where the current xticks are.
>
> Any suggestions are again extremely welcome :)
>
> Cheers, Andreas.

This was on the first page of a google search:
http://www.mail-archive.com/mat...@li.../msg00607.html

Hope this helps.

Best,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Friday, October 12, 2012, Ethan Gutmann wrote:

>
> On Oct 11, 2012, at 2:58 PM, Benjamin Root wrote:
>
>
> On Thu, Oct 11, 2012 at 4:53 PM, Mark Lawrence <bre...@ya...<javascript:_e({}, 'cvml', 'bre...@ya...');>
> > wrote:
>
>> On 11/10/2012 10:55, Damon McDougall wrote:
>>
>> > Am I missing something here? Are seconds just floats internally? A
>> > delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
>> > *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
>> > doesn't do any denormalising<
>> http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x
>> >
>> > when encountered with deltas very close to zero...
>> >
>>
>> What percentage of computer users wants a delta of 1e-12?  I suspect
>> that the vast majority of users couldn't care two hoots about miniscule
>>
>>
> Preach on, my brother! Preach on!
>
> [psst -- you are facing the choir...]
>
>
>
> I'm a little confused by this attitude.  I recognize that there are issues
> around dates, I've written a few date libraries myself to get around insane
> excel date issues (pop quiz for anyone at MS, was 1900 a leap year?) or
> just to simplify APIs for my own use.  But do neither of you think that
> nanoseconds are important to scientists?  I know of enough projects that
> work with pico (and a few with femto) seconds.  Even though I often work
> with climate data covering ~100s of years and used to work with geologic
> data covering ~billions of years, I may start working with raw laser data
> for distance measurements where nanoseconds can be a pretty big deal.
>  These data would be collected over a few years time, so a date utility
> that can handle that scale range would be useful.  I guess I'll be writing
> my own date/time library again and hacking together some way of plotting
> data in a meaningful way in matplotlib.
>
> Don't get me wrong, matplotlib shouldn't have to reinvent the wheel here,
> but claiming that nobody could possibly care about 1e-12 seconds seems a
> little provincial.  My apologies if that is not how the above statements
> were intended.
>
> regards,
> Ethan
>

Oh, don't get me wrong, those time scales are important.  I was merely
expressing my dismay over the amount of problems that exists in the set of
tools for everyday use.  It is 2012, and Perl still has probably the best
datetime library out there...

Python can do much better.

Ben Root

On Oct 11, 2012, at 2:58 PM, Benjamin Root wrote:
> 
> On Thu, Oct 11, 2012 at 4:53 PM, Mark Lawrence <bre...@ya...> wrote:
> On 11/10/2012 10:55, Damon McDougall wrote:
> 
> > Am I missing something here? Are seconds just floats internally? A
> > delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
> > *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
> > doesn't do any denormalising<http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x>
> > when encountered with deltas very close to zero...
> >
> 
> What percentage of computer users wants a delta of 1e-12?  I suspect
> that the vast majority of users couldn't care two hoots about miniscule
> 
> 
> Preach on, my brother! Preach on!
> 
> [psst -- you are facing the choir...]


I'm a little confused by this attitude.  I recognize that there are issues around dates, I've written a few date libraries myself to get around insane excel date issues (pop quiz for anyone at MS, was 1900 a leap year?) or just to simplify APIs for my own use.  But do neither of you think that nanoseconds are important to scientists?  I know of enough projects that work with pico (and a few with femto) seconds.  Even though I often work with climate data covering ~100s of years and used to work with geologic data covering ~billions of years, I may start working with raw laser data for distance measurements where nanoseconds can be a pretty big deal.  These data would be collected over a few years time, so a date utility that can handle that scale range would be useful.  I guess I'll be writing my own date/time library again and hacking together some way of plotting data in a meaningful way in matplotlib.  

Don't get me wrong, matplotlib shouldn't have to reinvent the wheel here, but claiming that nobody could possibly care about 1e-12 seconds seems a little provincial.  My apologies if that is not how the above statements were intended.  

regards,
Ethan

>> > Hi, me again :)
>> >
>> > I'm looking for a way to have the xlabels on the top (instead of
>> bottom),
>> > and the ylabels on the right (instead of left). I guess I could do
>> > something with twinx / twiny and just not use the left/bottom axis,
>> but
>> > I'm sure there is some more elegant way ...
>>
>> I need to correct myself: I want the xticklabels / yticklabels to be on
>> top/right.
>>
>>
> I believe you are looking for tick_params():
> http://matplotlib.org/api/axes_api.html?highlight=tick_param#matplotlib.axes.Axes.tick_params
>
> ax.tick_params(axis='x', labelbottom=False, labeltop=True)
> ax.tick_params(axis='y', labelleft=False, labelright=True)

Yes, that's it, Ben. Thanks!

Jae-Joon Lee <lee...@pu...> writes:
> On Fri, Oct 12, 2012 at 3:39 AM, Nikolaus Rath <Nik...@pu...> wrote:
>> matplotlib actually rescales the raw imshow data when saving to a vector
>> format? Why is that? I think it should embed the bitmap with full
>> resolution in the vector file and rely on the consumer of the vector
>> file to scale it to whatever resolution is supported by the display
>> device.
>
> imshow supports interpolation and that's why rasterization comes in.
> If you turn off interpolation (w/ interpolation="none"), the original
> image will be embedded. Of course dpi has no meaning in this case.
>
> However, I agree with you that dpi should be a property of the backend
> only, not the figure. But I am not sure if this can be fixed soon. It
> will be difficult and will take lots of effort I think.

Yeah, that's what I feared. But in the mean time, are there any best
practices to minimize undesired effects like the one above? For example,
are there any other functions that need special parameters to not raster
their output when writing to a vector format? And is there a way to get
a figure on the screen with the right size when I don't know what dpi
the monitor is running with?

Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

On Fri, Oct 12, 2012 at 6:12 AM, Andreas Hilboll <li...@hi...> wrote:

> > Hi, me again :)
> >
> > I'm looking for a way to have the xlabels on the top (instead of bottom),
> > and the ylabels on the right (instead of left). I guess I could do
> > something with twinx / twiny and just not use the left/bottom axis, but
> > I'm sure there is some more elegant way ...
>
> I need to correct myself: I want the xticklabels / yticklabels to be on
> top/right.
>
>
I believe you are looking for tick_params():
http://matplotlib.org/api/axes_api.html?highlight=tick_param#matplotlib.axes.Axes.tick_params

ax.tick_params(axis='x', labelbottom=False, labeltop=True)
ax.tick_params(axis='y', labelleft=False, labelright=True)

Cheers!
Ben Root

WMS services are required to respond to  "GetCapabiltiies" request,
reporting what layers, styles, times, elevations, and projections they
have available.  So for example, using the Unidata WMS example below,
if we do:

 http://motherlode.ucar.edu:8080/thredds/wms/fmrc/NCEP/NAM/CONUS_12km/NCEP-NAM-CONUS_12km-noaaport_best.ncd?service=WMS&request=GetCapabilities

we can see from the XML response that the Coordinate Reference Systems
supported are:

<CRS>EPSG:4326</CRS>
<CRS>CRS:84</CRS>
<CRS>EPSG:41001</CRS>
<CRS>EPSG:3857</CRS>
<CRS>EPSG:27700</CRS>
<CRS>EPSG:3408</CRS>
<CRS>EPSG:3409</CRS>
<CRS>EPSG:32661</CRS>
<CRS>EPSG:32761</CRS>

And for this server, the supported response types are:
<Format>image/jpeg</Format>
<Format>image/png</Format>
<Format>application/vnd.google-earth.kmz</Format>
<Format>image/gif</Format>

So I guess one way to proceed if you wanted to use WMS in Matplotlib
and avoid reprojection in python would be to:
1. do the WMS GetCapabilities request to find the available supported
Coordinate Reference Systems (which will vary with WMS server)
2. setup Basemap to use one of these CRS
3. use the bounding box of your current axis (in projection units) as
part of a GetMap request to the WMS.

-Rich

On Thu, Oct 11, 2012 at 12:16 AM, klo uo <kl...@gm...> wrote:
> I guess that's it?
>
> warpimage() as it is now, checks if passed image is url, so we can add
> additional check if image is url, with urlparse to deduce image coordinates
> and projection if present, then overlay it over already created Basemap
> object.
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>



-- 
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598

> Hi, me again :)
>
> I'm looking for a way to have the xlabels on the top (instead of bottom),
> and the ylabels on the right (instead of left). I guess I could do
> something with twinx / twiny and just not use the left/bottom axis, but
> I'm sure there is some more elegant way ...

I need to correct myself: I want the xticklabels / yticklabels to be on
top/right.

Hi, me again :)

I'm looking for a way to have the xlabels on the top (instead of bottom),
and the ylabels on the right (instead of left). I guess I could do
something with twinx / twiny and just not use the left/bottom axis, but
I'm sure there is some more elegant way ...

Cheers, Andreas.

Hi,

another question. Given the plot from my last email (I attached the code
to this one as well), I would like to have the x-labels ("J", "F", ...)
not at the location of the xticks, but centered in between to xticks. I
would then move the xticks so that they form the bins to the data chunks,
and the labels should be where the current xticks are.

Any suggestions are again extremely welcome :)

Cheers, Andreas.

Hi,

I have some data I want to plot using pcolormesh. It's 2d climatological
data, see the attached plot. My data is in a range from -7 to +0.6. I want
to be 0.0 to be clearly visible, while at the same time, the color range
should show the full dynamic of the values. I played with the bwr and
seismic color maps, centering on zero, so that white is 0.0. However, I'm
not too happy with the dynamic range I get in the negative.

Any suggestions are very welcome ...

Cheers, Andreas.

On Thursday, October 11, 2012, Benjamin Root wrote:

>
>
> On Thu, Oct 11, 2012 at 4:53 PM, Mark Lawrence <bre...@ya...<javascript:_e({}, 'cvml', 'bre...@ya...');>
> > wrote:
>
>> On 11/10/2012 10:55, Damon McDougall wrote:
>> > On Wed, Oct 10, 2012 at 5:00 PM, Benjamin Root <ben...@ou...<javascript:_e({}, 'cvml', 'ben...@ou...');>>
>> wrote:
>> >>
>> >>
>> >> On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <
>> bre...@ya... <javascript:_e({}, 'cvml',
>> 'bre...@ya...');>>
>> >> wrote:
>> >>>
>> >>> On 10/10/2012 15:41, Mark Lawrence wrote:
>> >>>> On 10/10/2012 14:29, Benjamin Root wrote:
>> >>>>>
>> >>>>> I know of a few people who have difficulties with matplotlib's
>> datetime
>> >>>>> handling, but they are usually operating on the scale of
>> milliseconds
>> >>>>> or
>> >>>>> less (lightning data), in which case, one is already at the edge of
>> the
>> >>>>> resolution handled by python's datetime objects.  However, we would
>> >>>>> certainly welcome any sort of examples of how matplotlib fails in
>> >>>>> handling
>> >>>>> seconds scale and lower plots.
>> >>>>>
>> >>>>> Cheers!
>> >>>>> Ben Root
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> I'll assume that the milliseconds above is a typo.  From
>> >>>> http://docs.python.org/library/datetime.html "class
>> datetime.timedelta A
>> >>>> duration expressing the difference between two date, time, or
>> datetime
>> >>>> instances to microsecond resolution."  Still, what's a factor of 1000
>> >>>> amongst friends? :)
>> >>>>
>> >>>
>> >>> http://www.python.org/dev/peps/pep-0418/ has been implemented in
>> Python
>> >>> 3.3 and talks about clocks with nanosecond resolutions.  I've flagged
>> it
>> >>> up here just in case people weren't aware.
>> >>>
>> >>
>> >> Ah, you are right, I meant microseconds.
>> >>
>> >> With apologies to Spaceballs:
>> >>
>> >> "Prepare to go to microsecond resolution!"
>> >> "No, no, microsecond resolution is too slow"
>> >> "Microsecond resolution is too slow?"
>> >> "Yes, too slow. We must use nanosecond resolution!"
>> >> "Prep-- Prepare Python, for nanosecond resolution!"
>> >>
>> >> Cheers!
>> >> Ben Root
>> >
>> > Am I missing something here? Are seconds just floats internally? A
>> > delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
>> > *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
>> > doesn't do any denormalising<
>> http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x
>> >
>> > when encountered with deltas very close to zero...
>> >
>>
>> What percentage of computer users wants a delta of 1e-12?  I suspect
>> that the vast majority of users couldn't care two hoots about miniscule
>> time deltas in a world where changing time zones can cause chaos.  Where
>> some applications cannot handle years before 1970, or 1904, or 1900 or
>> whatever.  Or they can't go too far forward, 2036 I think but don't
>> quote me.  Where people like myself had to put a huge amount of effort
>> into changing code so that applications would carry on working when the
>> date flipped over from 31st December 1999 to 1st January 2000.  If
>> things were that simple why is matplotlib using third party modules like
>> dateutil and pytz?  Why doesn't the "batteries included" Python already
>> provide this functionality?
>>
>>
> Preach on, my brother! Preach on!
>
> [psst -- you are facing the choir...]
>
> Cheers!
> Ben Root
>
>
Clearly I have misunderstood something and hit a nerve. Apologies.


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On 2012/10/10 3:07 AM, Anand Sivaramakrishnan wrote:
> Thanks for the many useful responses - I eventuallyfound by experiment
> that imshow(  interpolation='nearest' works *if* I write a png file.
> Saving a pdf file mushed up my crisp pixel boundaries.  However, saving
> as png, then using (mac osx) preview to convert to pdf worked fine.
> Go figure()!

This doesn't seem right to me, that pdf would be "mushed".  Would you 
supply an example, please?  Ideally a simple script with the png result 
and the mpl pdf result?

Eric

>
>>
>>
>>     I have solved this problem earlier using figimage(), but that was
>>     a lot of work (I had to create a pixel-by-pixel array with all
>>     greyscale values set myself, and then I was working in pixel
>>     coordinates rather than my data coordinates).  Has anyone figured
>>     out how to get imshow to stop smoothing the image?  Using imshow(…
>>     interpolation='none'…) or imshow(… interpolation=None…) raise
>>     exceptions.
>>
>>     I found NonUniformImage too hard to figure out from the documentation.
>>
>>     ------------------------------------------------------------------------------
>>     Don't let slow site performance ruin your business. Deploy New
>>     Relic APM
>>     Deploy New Relic app performance management and know exactly
>>     what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>     Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>     http://p.sf.net/sfu/newrelic-dev2dev
>>     _______________________________________________
>>     Matplotlib-users mailing list
>>     Mat...@li...
>>     <mailto:Mat...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Fri, Oct 12, 2012 at 3:39 AM, Nikolaus Rath <Nik...@ra...> wrote:
> matplotlib actually rescales the raw imshow data when saving to a vector
> format? Why is that? I think it should embed the bitmap with full
> resolution in the vector file and rely on the consumer of the vector
> file to scale it to whatever resolution is supported by the display
> device.

imshow supports interpolation and that's why rasterization comes in.
If you turn off interpolation (w/ interpolation="none"), the original
image will be embedded. Of course dpi has no meaning in this case.

However, I agree with you that dpi should be a property of the backend
only, not the figure. But I am not sure if this can be fixed soon. It
will be difficult and will take lots of effort I think.

-JJ

Thanks for taking this on, Damon and Gökhan.

Note this will need to create a different symlink (to dateutil_py3 
instead) on Python 3.  This means, of course, that it will be impossible 
to develop on both Python 2 and 3 simultaneously, but that's true of 
"setuptools' develop" in any event, so it's no great loss.

Mike

On 10/11/2012 03:38 PM, Damon McDougall wrote:
> On Thu, Oct 11, 2012 at 9:25 PM, Gökhan Sever <gok...@gm...> wrote:
>> I am not sure about that technical detail, but it works fine here on my
>> Fedora 16 (x86_64) system.
>>
>>
>> On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall
>> <dam...@gm...> wrote:
>>>
>>>
>>> On Thursday, October 11, 2012, Gökhan Sever wrote:
>>>>
>>>>
>>>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
>>>> <dam...@gm...> wrote:
>>>>>
>>>>> Gökhan, did you implement the symlink fix? If so, would you mind
>>>>> making a pull request out of it? I was just about to look into doing
>>>>> this, but if you've done it already that'd save us some effort rolling
>>>>> out fixes for 1.2.
>>>>>
>>>>> Cheers.
>>>>> Damon
>>>>
>>>>
>>>> Hi Damon,
>>>>
>>>> I think adding these lines before execfile line in setupegg.py should fix
>>>> it:
>>>>
>>>> import os
>>>> os.chdir('lib')
>>>> if not os.path.isdir('dateutil'):
>>>>      os.symlink('dateutil_py2', 'dateutil')
>>>> os.chdir('..')
>>>>
>>>>
>>>> Could you give it a test? Do we require a similar symlink for py3?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> --
>>>> Gökhan
>>>
>>> Awesome. I'll give it a go later on. I'm a little concerned using
>>> os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being
>>> threadsafe on windows. Does the same apply here?
> I'm not sure how to test this. I'm running `setupegg.py develop` from
> within a python virtual env, but somehow it's picking up dateutil
> version 1.5. I don't get the `matplotlib will provide` message... Hmm.
>

On Thu, Oct 11, 2012 at 4:53 PM, Mark Lawrence <bre...@ya...>wrote:

> On 11/10/2012 10:55, Damon McDougall wrote:
> > On Wed, Oct 10, 2012 at 5:00 PM, Benjamin Root <ben...@ou...> wrote:
> >>
> >>
> >> On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <
> bre...@ya...>
> >> wrote:
> >>>
> >>> On 10/10/2012 15:41, Mark Lawrence wrote:
> >>>> On 10/10/2012 14:29, Benjamin Root wrote:
> >>>>>
> >>>>> I know of a few people who have difficulties with matplotlib's
> datetime
> >>>>> handling, but they are usually operating on the scale of milliseconds
> >>>>> or
> >>>>> less (lightning data), in which case, one is already at the edge of
> the
> >>>>> resolution handled by python's datetime objects.  However, we would
> >>>>> certainly welcome any sort of examples of how matplotlib fails in
> >>>>> handling
> >>>>> seconds scale and lower plots.
> >>>>>
> >>>>> Cheers!
> >>>>> Ben Root
> >>>>>
> >>>>>
> >>>>
> >>>> I'll assume that the milliseconds above is a typo.  From
> >>>> http://docs.python.org/library/datetime.html "class
> datetime.timedelta A
> >>>> duration expressing the difference between two date, time, or datetime
> >>>> instances to microsecond resolution."  Still, what's a factor of 1000
> >>>> amongst friends? :)
> >>>>
> >>>
> >>> http://www.python.org/dev/peps/pep-0418/ has been implemented in
> Python
> >>> 3.3 and talks about clocks with nanosecond resolutions.  I've flagged
> it
> >>> up here just in case people weren't aware.
> >>>
> >>
> >> Ah, you are right, I meant microseconds.
> >>
> >> With apologies to Spaceballs:
> >>
> >> "Prepare to go to microsecond resolution!"
> >> "No, no, microsecond resolution is too slow"
> >> "Microsecond resolution is too slow?"
> >> "Yes, too slow. We must use nanosecond resolution!"
> >> "Prep-- Prepare Python, for nanosecond resolution!"
> >>
> >> Cheers!
> >> Ben Root
> >
> > Am I missing something here? Are seconds just floats internally? A
> > delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
> > *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
> > doesn't do any denormalising<
> http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x
> >
> > when encountered with deltas very close to zero...
> >
>
> What percentage of computer users wants a delta of 1e-12?  I suspect
> that the vast majority of users couldn't care two hoots about miniscule
> time deltas in a world where changing time zones can cause chaos.  Where
> some applications cannot handle years before 1970, or 1904, or 1900 or
> whatever.  Or they can't go too far forward, 2036 I think but don't
> quote me.  Where people like myself had to put a huge amount of effort
> into changing code so that applications would carry on working when the
> date flipped over from 31st December 1999 to 1st January 2000.  If
> things were that simple why is matplotlib using third party modules like
> dateutil and pytz?  Why doesn't the "batteries included" Python already
> provide this functionality?
>
>
Preach on, my brother! Preach on!

[psst -- you are facing the choir...]

Cheers!
Ben Root