matplotlib-users Mailing List for matplotlib (Page 6)

Hi All,
I'm trying to access to the sampledoc tutorial, but seems it is no more on git/sourceforge,
i tried at the link :
http://matplotlib.sourceforge.net/sampledoc/
do you know where can i find it ?
Thanks!
Massimo.

Thanks. I believe it should all be fixed now.
On 09/17/2012 06:33 PM, Chr...@dl... wrote:
>
> thanks for your fast help. the links for the image tutorial are working already again.
>
>
> On Sep 17, 2012, at 11:53 PM, Michael Droettboom wrote:
>
>> Thanks for pointing this out. I'll get to the bottom of it.
>>
>> Mike
>>
>> On 09/17/2012 05:16 PM, Chr...@dl... wrote:
>>> hi all,
>>> a lot of links at the github repository are broken. for example all the links to png, source code, ... of the image tutorial (http://matplotlib.org/users/image_tutorial.html). but also links of other pages are broken (e.g. http://matplotlib.org/users/plotting/examples/demo_gridspec01.png or http://matplotlib.org/users/tight_layout_guide.html or ....) and a lot of google search results.
>>> best regards
>>> christian
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

thanks for your fast help. the links for the image tutorial are working already again.
On Sep 17, 2012, at 11:53 PM, Michael Droettboom wrote:
> Thanks for pointing this out. I'll get to the bottom of it.
> 
> Mike
> 
> On 09/17/2012 05:16 PM, Chr...@dl... wrote:
>> hi all,
>> a lot of links at the github repository are broken. for example all the links to png, source code, ... of the image tutorial (http://matplotlib.org/users/image_tutorial.html). but also links of other pages are broken (e.g. http://matplotlib.org/users/plotting/examples/demo_gridspec01.png or http://matplotlib.org/users/tight_layout_guide.html or ....) and a lot of google search results.
>> best regards
>> christian
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Thanks for pointing this out. I'll get to the bottom of it.
Mike
On 09/17/2012 05:16 PM, Chr...@dl... wrote:
> hi all,
> a lot of links at the github repository are broken. for example all the links to png, source code, ... of the image tutorial (http://matplotlib.org/users/image_tutorial.html). but also links of other pages are broken (e.g. http://matplotlib.org/users/plotting/examples/demo_gridspec01.png or http://matplotlib.org/users/tight_layout_guide.html or ....) and a lot of google search results.
> best regards
> christian
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

hi all,
a lot of links at the github repository are broken. for example all the links to png, source code, ... of the image tutorial (http://matplotlib.org/users/image_tutorial.html). but also links of other pages are broken (e.g. http://matplotlib.org/users/plotting/examples/demo_gridspec01.png or http://matplotlib.org/users/tight_layout_guide.html or ....) and a lot of google search results.
best regards
christian

On 9/17/12 5:09 AM, Joachim Saul wrote:
> Jeff, thanks for your feedback!
A workaround for this (having drawcoastlines use line segments instead 
of polygons) is now part of this pull request:
https://github.com/matplotlib/basemap/pull/78
Let's move discussion there..
-Jeff
>
> Jeff Whitaker [15.09.2012 17:25]:
>> On 9/15/12 8:05 AM, Joachim Saul wrote:
>>> Hi there,
>>>
>>> in basemap coastlines are apparently (always?) drawn as closed polygons not exceeding the map boundary, i.e. when the coastline intersects with the map boundary the polygon is continued along the map boundary until the next intersection point. The somewhat annoying side effect of this is a map boundary that appears thicker where it crosses landmasses. See for instance on http://matplotlib.org/basemap/users/examples the example "Plot hurricane tracks from a shapefile" where clearly the upper and left map boundaries are thicker where they cross the western U.S. or northern Canada. Another example where this effect is particularly pronounced is the example "Draw great circle between NY and London" on the same page. The effect gets worse if running these examples without antialiasing. Apparently only the upper and left boundaries are affected, whereas the lower and right boundaries are plotted properly.
>>>
>>> It looks to me as if this might simply be a bug due to the coastline not aligning perfectly with the map boundary, perhaps because of some roundoff error. Is there a way to avoid this? Wouldn't it be better to draw the coastlines not as closed polygons but as collections of line segments?
>>>
>>> Cheers,
>>> Joachim
>>>
>> Joachim: I've noticed this myself, but have not found any solution. I suppose I could add an option to treat coastlines as line segments, but then you would not be able to use the fillcontinents method.
> On the other hand, computing the coastlines /either/ as segments /or/
> closed polygons might be inexpensive enough to be done on the fly - i.e.
> segments in drawcoastlines() but closed polygons in fillcontinents(). A
> computational penalty comes into play only where both are called. But I
> think this would be acceptable.
>
>> Here's what happens now when a Basemap instance is created:
>>
>> 1) the intersection between the coastline polygons and the map boundary is computed using the geos C library.
>> 2) the coastline polygons are clipped at the map boundary
>> 3) the coordinates of the coastline polygons are transformed to map projection coordinates
>>
>> Then, when the drawcoastlines or fillcontinents methods are called only the polygons inside the map projection region are drawn. This saves *a lot* of time when you're using high-resolution coastlines in a small map region. There is a similar process for political boundaries, but since they are line segments you don't see the "thickening" around the map edges.
> Generally speaking this optimization stragegy is absolutely fine and
> works well - except for this nasty little line width artefact. ;)
>
>> Maybe one solution would be to clip the polygons to a region slightly larger than the actual map projection region.
> That should work but on the other hand it seems a little hackish and the
> resulting code could be harder to understand. Besides the suggestion
> given above I still have the feeling that part of the problem might be
> related to some roundoff issue - how else could the presence of
> thickened lines be (apparently) confined to only the upper and left border?
>
> Cheers,
> Joachim
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

From: Daniel Welling [mailto:dan...@gm...] 
Sent: Thursday, September 13, 2012 16:23
Greetings, all. 
I have an issue: I have several axes stacked in a column with a common time
vector on each x-axis. Each plot is a contour, so overplotting is not an
option. In a perfect world, I want the following:
1) The subplots are tightly spaced such that with ax.grid() activated, the
grid lines appear continuous. This makes comparing simultaneous
characteristics between subplots very easy.
2) The subplots are linked via the "sharex" keyword so I can move them all in
unison.
3) Only the bottommost subplot has x tick labels; on other plots, the long
time-formatted labels stick out of the left and right of the plots.
[...]
For #3, there is a convenience method of subplots, label_outer [1], that sets
the visibility of the tick labels (as Francesco described), making them
visible in the bottom row and invisible elsewhere (as in Sterling's code).
Just iterate over all of your subplots and call the label_outer method on each
one.
[1]
http://matplotlib.org/api/axes_api.html#matplotlib.axes.SubplotBase.label_oute
r

Sometimes, having a point of reference really helps in tracking the issue
down, particularly when complimented with the very cool "bisect" tool that
comes with git. In this case though, I knew where the problem came in
because I have been working closely in this area recently (and it's my
change which has exposed the problem). I have fixed this in the pull
request, and fully expect the fix to be in the next 1.2.x release candidate.
If your willing and able, you could get hold of my branch until it is
merged to carry on testing the release candidate.
Hope that helps,
All the best,
Phil
On 14 September 2012 17:53, Scott Lasley <sl...@sp...> wrote:
>
> On Sep 14, 2012, at 5:02 AM, Phil Elson <pel...@gm...> wrote:
>
> > Thanks for raising this. I have simplified and opened an issue for the
> bug (https://github.com/matplotlib/matplotlib/issues/1246) and will be
> looking at this asap.
> >
> > All the best,
> >
> > Phil
>
> I don't know if this helps, but my scripts and the code snippet in my
> email message work without crashing using matplotlib 1.2.x compiled from
> github on July 23, 2012 and
> numpy-1.8.0.dev_63cd8f3-py2.7-macosx-10.6-intel.egg on another mac running
> OS X 10.8.1.
>
> Thank you for looking into this,
> Scott

Jeff, thanks for your feedback!
Jeff Whitaker [15.09.2012 17:25]:
> On 9/15/12 8:05 AM, Joachim Saul wrote:
>> Hi there,
>>
>> in basemap coastlines are apparently (always?) drawn as closed polygons not exceeding the map boundary, i.e. when the coastline intersects with the map boundary the polygon is continued along the map boundary until the next intersection point. The somewhat annoying side effect of this is a map boundary that appears thicker where it crosses landmasses. See for instance on http://matplotlib.org/basemap/users/examples the example "Plot hurricane tracks from a shapefile" where clearly the upper and left map boundaries are thicker where they cross the western U.S. or northern Canada. Another example where this effect is particularly pronounced is the example "Draw great circle between NY and London" on the same page. The effect gets worse if running these examples without antialiasing. Apparently only the upper and left boundaries are affected, whereas the lower and right boundaries are plotted properly.
>>
>> It looks to me as if this might simply be a bug due to the coastline not aligning perfectly with the map boundary, perhaps because of some roundoff error. Is there a way to avoid this? Wouldn't it be better to draw the coastlines not as closed polygons but as collections of line segments?
>>
>> Cheers,
>> Joachim
>>
>
> Joachim: I've noticed this myself, but have not found any solution. I suppose I could add an option to treat coastlines as line segments, but then you would not be able to use the fillcontinents method.
On the other hand, computing the coastlines /either/ as segments /or/ 
closed polygons might be inexpensive enough to be done on the fly - i.e. 
segments in drawcoastlines() but closed polygons in fillcontinents(). A 
computational penalty comes into play only where both are called. But I 
think this would be acceptable.
> Here's what happens now when a Basemap instance is created:
>
> 1) the intersection between the coastline polygons and the map boundary is computed using the geos C library.
> 2) the coastline polygons are clipped at the map boundary
> 3) the coordinates of the coastline polygons are transformed to map projection coordinates
>
> Then, when the drawcoastlines or fillcontinents methods are called only the polygons inside the map projection region are drawn. This saves *a lot* of time when you're using high-resolution coastlines in a small map region. There is a similar process for political boundaries, but since they are line segments you don't see the "thickening" around the map edges.
Generally speaking this optimization stragegy is absolutely fine and 
works well - except for this nasty little line width artefact. ;)
> Maybe one solution would be to clip the polygons to a region slightly larger than the actual map projection region.
That should work but on the other hand it seems a little hackish and the 
resulting code could be harder to understand. Besides the suggestion 
given above I still have the feeling that part of the problem might be 
related to some roundoff issue - how else could the presence of 
thickened lines be (apparently) confined to only the upper and left border?
Cheers,
Joachim

On 2012年09月16日 8:54 AM, Benjamin Root wrote:
>
>
> On Sun, Sep 16, 2012 at 2:09 PM, Skipper Seabold <jss...@gm...
> <mailto:jss...@gm...>> wrote:
>
> Is there a way to overwrite suptitle? When using 3rd party libs that
> return a figure, if they set suptitle and don't give you the text
> object back then you can't overwrite it? This doesn't seem right to
> me.
>
> http://stackoverflow.com/questions/10559144/matplotlib-suptitle-prints-over-old-title
>
> Skipper
>
>
> Correct, this still seems to be the case. Looking at the code in
> figure.py, the suptitle() function just creates a text object and places
> it at a default location. Then it simply returns the object without
> saving a reference to it being a figure title. The only reference kept
> is in the self.texts list that it keeps. I see no reason why it has to
> be this way, though, and would certainly welcome a patch to fix this
> oversight (would make the code involving bbox_tight to be more simple, I
> think.
OK, I guess I see the problem now: Figure.suptitle really should be able 
to replace a prior suptitle, and the most straightforward way to 
facilitate this is with an explicit reference kept by the Figure.
Eric
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 2012年09月16日 8:54 AM, Benjamin Root wrote:
>
>
> On Sun, Sep 16, 2012 at 2:09 PM, Skipper Seabold <jss...@gm...
> <mailto:jss...@gm...>> wrote:
>
> Is there a way to overwrite suptitle? When using 3rd party libs that
> return a figure, if they set suptitle and don't give you the text
> object back then you can't overwrite it? This doesn't seem right to
> me.
>
> http://stackoverflow.com/questions/10559144/matplotlib-suptitle-prints-over-old-title
>
> Skipper
>
>
> Correct, this still seems to be the case. Looking at the code in
> figure.py, the suptitle() function just creates a text object and places
> it at a default location. Then it simply returns the object without
> saving a reference to it being a figure title. The only reference kept
> is in the self.texts list that it keeps. I see no reason why it has to
> be this way, though, and would certainly welcome a patch to fix this
> oversight (would make the code involving bbox_tight to be more simple, I
> think.
Why should a reference be kept other than that in self.texts? Instead 
of keeping track of it somewhere else, would it be sufficient for the 
suptitle method to add a default "suptitle" label to the text object? 
Is there really anything special about the "suptitle" compared to any 
other text object that might be placed on the figure?
Eric
>
> Ben Root
>

On Sun, Sep 16, 2012 at 2:54 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Sun, Sep 16, 2012 at 2:09 PM, Skipper Seabold <jss...@gm...>
> wrote:
>>
>> Is there a way to overwrite suptitle? When using 3rd party libs that
>> return a figure, if they set suptitle and don't give you the text
>> object back then you can't overwrite it? This doesn't seem right to
>> me.
>>
>>
>> http://stackoverflow.com/questions/10559144/matplotlib-suptitle-prints-over-old-title
>>
>> Skipper
>>
>
> Correct, this still seems to be the case. Looking at the code in figure.py,
> the suptitle() function just creates a text object and places it at a
> default location. Then it simply returns the object without saving a
> reference to it being a figure title. The only reference kept is in the
> self.texts list that it keeps. I see no reason why it has to be this way,
> though, and would certainly welcome a patch to fix this oversight (would
> make the code involving bbox_tight to be more simple, I think.
>
> Ben Root
Does not reply to the list by default (?), so reposting
Ah, thanks for pointing out the reference in self.texts. I can use
this. I don't have time for a patch now, but I filed this issue.
https://github.com/matplotlib/matplotlib/issues/1262
Skipper

On Sun, Sep 16, 2012 at 2:09 PM, Skipper Seabold <jss...@gm...>wrote:
> Is there a way to overwrite suptitle? When using 3rd party libs that
> return a figure, if they set suptitle and don't give you the text
> object back then you can't overwrite it? This doesn't seem right to
> me.
>
>
> http://stackoverflow.com/questions/10559144/matplotlib-suptitle-prints-over-old-title
>
> Skipper
>
>
Correct, this still seems to be the case. Looking at the code in
figure.py, the suptitle() function just creates a text object and places it
at a default location. Then it simply returns the object without saving a
reference to it being a figure title. The only reference kept is in the
self.texts list that it keeps. I see no reason why it has to be this way,
though, and would certainly welcome a patch to fix this oversight (would
make the code involving bbox_tight to be more simple, I think.
Ben Root

Is there a way to overwrite suptitle? When using 3rd party libs that
return a figure, if they set suptitle and don't give you the text
object back then you can't overwrite it? This doesn't seem right to
me.
http://stackoverflow.com/questions/10559144/matplotlib-suptitle-prints-over-old-title
Skipper

florisvb <flo...@gm...> writes:
> I'm trying to get my pdf outputs from matplotlib to work properly in
> illustrator, but keep having the issue that illustrator does not recognize
> the computer modern fonts (eg. CMR10 etc). Everything else seems to work
> perfectly.
Is there any error message from illustrator? If you view the pdf file in
Acrobat Reader and choose the document information dialog, what type
does it list the CMR10 font as? I think this would usually be Type 1,
and there could be some problem with how Type-1 fonts get embedded.
> text.usetex: True
Do you need usetex or is matplotlib's built-in formula rendering
sufficient? In the latter case TrueType versions of the various fonts
are embedded, which just might work better than Type 1.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 9/15/12 8:05 AM, Joachim Saul wrote:
> Hi there,
>
> in basemap coastlines are apparently (always?) drawn as closed polygons not exceeding the map boundary, i.e. when the coastline intersects with the map boundary the polygon is continued along the map boundary until the next intersection point. The somewhat annoying side effect of this is a map boundary that appears thicker where it crosses landmasses. See for instance on http://matplotlib.org/basemap/users/examples the example "Plot hurricane tracks from a shapefile" where clearly the upper and left map boundaries are thicker where they cross the western U.S. or northern Canada. Another example where this effect is particularly pronounced is the example "Draw great circle between NY and London" on the same page. The effect gets worse if running these examples without antialiasing. Apparently only the upper and left boundaries are affected, whereas the lower and right boundaries are plotted properly.
>
> It looks to me as if this might simply be a bug due to the coastline not aligning perfectly with the map boundary, perhaps because of some roundoff error. Is there a way to avoid this? Wouldn't it be better to draw the coastlines not as closed polygons but as collections of line segments?
>
> Cheers,
> Joachim
>
Joachim: I've noticed this myself, but have not found any solution. I 
suppose I could add an option to treat coastlines as line segments, but 
then you would not be able to use the fillcontinents method. Here's 
what happens now when a Basemap instance is created:
1) the intersection between the coastline polygons and the map boundary 
is computed using the geos C library.
2) the coastline polygons are clipped at the map boundary
3) the coordinates of the coastline polygons are transformed to map 
projection coordinates
Then, when the drawcoastlines or fillcontinents methods are called only 
the polygons inside the map projection region are drawn. This saves *a 
lot* of time when you're using high-resolution coastlines in a small map 
region. There is a similar process for political boundaries, but since 
they are line segments you don't see the "thickening" around the map edges.
Maybe one solution would be to clip the polygons to a region slightly 
larger than the actual map projection region.
-Jeff

Hi there,
in basemap coastlines are apparently (always?) drawn as closed polygons not exceeding the map boundary, i.e. when the coastline intersects with the map boundary the polygon is continued along the map boundary until the next intersection point. The somewhat annoying side effect of this is a map boundary that appears thicker where it crosses landmasses. See for instance on http://matplotlib.org/basemap/users/examples the example "Plot hurricane tracks from a shapefile" where clearly the upper and left map boundaries are thicker where they cross the western U.S. or northern Canada. Another example where this effect is particularly pronounced is the example "Draw great circle between NY and London" on the same page. The effect gets worse if running these examples without antialiasing. Apparently only the upper and left boundaries are affected, whereas the lower and right boundaries are plotted properly.
It looks to me as if this might simply be a bug due to the coastline not aligning perfectly with the map boundary, perhaps because of some roundoff error. Is there a way to avoid this? Wouldn't it be better to draw the coastlines not as closed polygons but as collections of line segments?
Cheers,
Joachim

Bump for this topic; I'd still love to know what the right thing is to do
here.
On Mon, Aug 20, 2012 at 10:08 PM, Daniel Hyams <dh...@gm...> wrote:
> Hmm, I just found out that if I change path.Path.contains_point to use
> "point_on_path" instead of "point_in_path", the containment tests work
> properly. I'm not that familiar with the path code...is the difference
> that one is testing for polygonal insideness, and one is testing for
> literally being on the "stroke"? If so, do we have to make sure that the
> proper one is called if there are no polygons involved in the path?
>
>
> On Mon, Aug 20, 2012 at 9:28 PM, Daniel Hyams <dh...@gm...> wrote:
>
>> I've run into a strange problem with contains() on an arrow; there is a
>> large area to the left of the arrow that insists that it is contained
>> within the arrow. Small runnable sample attached.
>>
>> I've looked at the path for the arrow, and it looks fine to me. I even
>> went so far as to hack a STOP onto the end of the path, but that resulted
>> in the same behavior.
>>
>> Can anyone else confirm this behavior? matplotlib 1.1.1 is what I'm
>> using. Seen on both Windows, Linux, and OSX.
>>
>> --
>> Daniel Hyams
>> dh...@gm...
>>
>
>
>
> --
> Daniel Hyams
> dh...@gm...
>
-- 
Daniel Hyams
dh...@gm...

On 2012年09月14日 10:15 AM, Benjamin Root wrote:
>
>
> On Fri, Sep 14, 2012 at 3:50 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 2012年09月14日 9:00 AM, Benjamin Root wrote:
> > tricontourf() might be more what you are looking for. Another
> > possibility is pcolor() (note that for irregularly spaced grids,
> > pcolormesh() would not work).
>
> Huh? I don't think there is anything pcolor can handle that pcolormesh
> can't handle faster. In both cases, the grids must be quadrilateral,
> but that's all.
>
> Eric
>
>
> Clarification: pcolormesh() must have a grid of coordinates (not
> necessarially equally spaced).
>
> As for pcolormesh() being able to handle anything that pcolor() can
> handle, I have run into situations where that was not the case. I don't
> remember the details, though. I think pcolorfast() operates like that
> (falling back to pcolor() as a last resort).
No, pcolorfast never falls back to pcolor. In order of fastest to 
slowest, it tries to use image rendering, then a variant of nonuniform 
image rendering, and then a quadmesh. It is a bit fussier about inputs 
than pcolor and pcolormesh, and does not draw lines. pcolor and 
pcolormesh differ in the mechanism they use (pcolor uses a 
PolyCollection) and in the way masked data are handled (pcolor draws 
nothing in masked regions).
Eric
>
> Ben Root
>

On Fri, Sep 14, 2012 at 3:50 PM, Eric Firing <ef...@ha...> wrote:
> On 2012年09月14日 9:00 AM, Benjamin Root wrote:
> > tricontourf() might be more what you are looking for. Another
> > possibility is pcolor() (note that for irregularly spaced grids,
> > pcolormesh() would not work).
>
> Huh? I don't think there is anything pcolor can handle that pcolormesh
> can't handle faster. In both cases, the grids must be quadrilateral,
> but that's all.
>
> Eric
>
>
Clarification: pcolormesh() must have a grid of coordinates (not
necessarially equally spaced).
As for pcolormesh() being able to handle anything that pcolor() can handle,
I have run into situations where that was not the case. I don't remember
the details, though. I think pcolorfast() operates like that (falling back
to pcolor() as a last resort).
Ben Root

Wonderful...pcolor is doing the job without processing, it takes exactly what
I already have...the n+1 values for x and y coordinates defining the
boundaries of the cells and the nxn matix itself. 
pcolormesh and pcolorfast also work.
Thank you very much.
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Need-to-plot-z-at-given-x-y-contour-or-something-tp38926p38930.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On 2012年09月14日 9:00 AM, Benjamin Root wrote:
> tricontourf() might be more what you are looking for. Another
> possibility is pcolor() (note that for irregularly spaced grids,
> pcolormesh() would not work).
Huh? I don't think there is anything pcolor can handle that pcolormesh 
can't handle faster. In both cases, the grids must be quadrilateral, 
but that's all.
Eric

Hi folks,
you may have already seen this, but in case you haven't, I'm thrilled
to share that the Python Software Foundation has just created its
newest and highest distinction, the Distinguished Service Award, and
has chosen John as its first recipient:
http://pyfound.blogspot.com/2012/09/announcing-2012-distinctive-service.html
This is a fitting tribute to his many contributions.
Cheers,
f

On Fri, Sep 14, 2012 at 2:51 PM, gsal <sal...@gm...> wrote:
> Hi, everybody:
>
> I don't have experience with images or contours and need some help plotting
> a 'z' quantity for given x,y coordinates.
>
> What are the choices?
>
> Here is a small sample of the data:
>
> The first row has the i-th x-coordinate at which the field starts to have
> the value [i,j].
> The first column has the j-th y-coordinate at which the field starts to
> have the value [i,j].
>
> The coordinate steps are not constant, nor the same for both dimensions;
> they can be anything because they come from some odd finite difference
> program.
>
> My first shot at this is getting combersome, I am hoping for a better way.
>
> So far, because the second decimal place in the x,y coordinate is alwasy
> zero, I simply turned those coordinates into integers by multiplying by ten
> and truncating; then by subtracting the first value from the rest, they
> look
> very much like matrix indeces (except for the missing ones):
>
> Then, because I don't know any better, I broadcast the values onto another
> matrix, to fill in the in-between values:
>
> Now, I have a matrix where every i,j has its own z-value and I am supposed
> to be able to plot it with ax.contourf(mymatrix)...which I can, up until
> about mymatrix[:,:1900] or so, afte that, I get the following error:
>
> Traceback (most recent call last):
> File "C:\findiff\t1.py", line 73, in <module>
> ax.contourf(full[:,:2000])
> File "C:\Python26\lib\site-packages\matplotlib\axes.py", line 7322, in
> contourf
> return mcontour.QuadContourSet(self, *args, **kwargs)
> File "C:\Python26\lib\site-packages\matplotlib\contour.py", line 1106, in
> __init__
> ContourSet.__init__(self, ax, *args, **kwargs)
> File "C:\Python26\lib\site-packages\matplotlib\contour.py", line 700, in
> __init__
> self._process_args(*args, **kwargs)
> File "C:\Python26\lib\site-packages\matplotlib\contour.py", line 1130, in
> _process_args
> C = _cntr.Cntr(x, y, z.filled(), _mask)
> ValueError: Arguments x, y, z, mask (if present) must be 2D arrays.
> x, y, z must be castable to double.
>
>
>
> My current matrix is about 12000x5000.
>
> Any asistance would be greatly appreciated.
>
> Thanks,
>
> Germán
>
>
>
tricontourf() might be more what you are looking for. Another possibility
is pcolor() (note that for irregularly spaced grids, pcolormesh() would not
work).
Cheers!
Ben Root

Hi, everybody:
I don't have experience with images or contours and need some help plotting
a 'z' quantity for given x,y coordinates. 
What are the choices?
Here is a small sample of the data:
 The first row has the i-th x-coordinate at which the field starts to have
the value [i,j].
 The first column has the j-th y-coordinate at which the field starts to
have the value [i,j].
 
 The coordinate steps are not constant, nor the same for both dimensions;
they can be anything because they come from some odd finite difference
program. 
 
 My first shot at this is getting combersome, I am hoping for a better way.
 
 So far, because the second decimal place in the x,y coordinate is alwasy
zero, I simply turned those coordinates into integers by multiplying by ten
and truncating; then by subtracting the first value from the rest, they look
very much like matrix indeces (except for the missing ones):
 Then, because I don't know any better, I broadcast the values onto another
matrix, to fill in the in-between values:
Now, I have a matrix where every i,j has its own z-value and I am supposed
to be able to plot it with ax.contourf(mymatrix)...which I can, up until
about mymatrix[:,:1900] or so, afte that, I get the following error:
Traceback (most recent call last):
 File "C:\findiff\t1.py", line 73, in <module>
 ax.contourf(full[:,:2000])
 File "C:\Python26\lib\site-packages\matplotlib\axes.py", line 7322, in
contourf
 return mcontour.QuadContourSet(self, *args, **kwargs)
 File "C:\Python26\lib\site-packages\matplotlib\contour.py", line 1106, in
__init__
 ContourSet.__init__(self, ax, *args, **kwargs)
 File "C:\Python26\lib\site-packages\matplotlib\contour.py", line 700, in
__init__
 self._process_args(*args, **kwargs)
 File "C:\Python26\lib\site-packages\matplotlib\contour.py", line 1130, in
_process_args
 C = _cntr.Cntr(x, y, z.filled(), _mask)
ValueError: Arguments x, y, z, mask (if present) must be 2D arrays.
x, y, z must be castable to double.
My current matrix is about 12000x5000.
Any asistance would be greatly appreciated.
Thanks,
Germán 
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Need-to-plot-z-at-given-x-y-contour-or-something-tp38926.html
Sent from the matplotlib - users mailing list archive at Nabble.com.