matplotlib-users Mailing List for matplotlib (Page 8)

I'm wondering if there is some way to do cross hatching as a way to fill
contours rather than colors (using contourf). The only references to
cross hatching I see in the documentation are for patches type objects.
As far as I can tell, contour and contourf return objects of their own
type (contour.QuadContourSet) that do not have hatch as an attribute.
If it's not possible currently, how hard would it be to add that
capability to contourf? What approach would you recommend?
Regards,
Jon

Hi all,
I am looking for a simple method to generate various 
colours (n > 15, n denotes the number of colours) for a 
stacked bar plot.
Any pointer would be appreciated.
The example 
http://matplotlib.sourceforge.net/examples/pylab_examples/table_demo.html
generates pastel colours. However the difference between 
the different colors decreases drastically.
Nils
 

I had a closer look at an issue raised previously
(http://old.nabble.com/can%27t-output-emf-pdf-eps-figure-file-corrently-with-my-dataset.-to31104695.html#a31107307),
because I found out where the problem lies: when plotting a figure in log
scale with some null values, screen plots display fine (Mac OS X backend);
however, when trying to save the figure (with savefig) to PDF, a "Path lacks
initial MOVETO" exception is raised (it looks like this may be related to
the way masked values are handled by both backends).
It would be better if Matplotlib's backends were consistent, here (i.e. if
it failed both on screen and when generating the PDF, or if it did not fail
at all).
I attach a slightly modified version of the original program: 
http://old.nabble.com/file/p32470066/t.py t.py . Commenting out the
savefig() call makes the program work nicely (Mac OS X backend, MacPort's
Matplotlib 1.0.1).
-- 
View this message in context: http://old.nabble.com/PDF-%28but-not-screen%29-output-raises-%22Path-lacks-initial-MOVETO%22-tp32470066p32470066.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

You are correct JJ; the annotation_clip=False attribute was exactly
what I was after, but somehow missed it in the docs :(.
On Wed, Sep 14, 2011 at 9:09 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Mon, Sep 12, 2011 at 3:20 AM, Daniel Hyams <dh...@gm...> wrote:
>> I would suggest the following modification to Annotation.draw in
>> text.py. All it does is set a clip box so that the annotation and
>> arrow is still drawn, but the arrow is clipped at the axes boundary.
>> It is a much nicer effect than the annotation disappearing. I have
>> made this modification in my source locally, and it works very well,
>> but I thought I would suggest here for inclusion into the main code
>> base.
>>
>
> Can you explain more explicitly why you think this behavior is better?
> For example, what is the point of annotating something if that
> something is not visible?
> Also, annotating texts are often placed outside of axes area. I don't
> think clipping out the arrow is a good idea in this case.
>
> Just in case, this is just a default behavior. You can override this
> behavior without changing the mpl source code.
>
> Regards,
>
> -JJ
>
--
Daniel Hyams
dh...@gm...

On Mon, Sep 12, 2011 at 3:20 AM, Daniel Hyams <dh...@gm...> wrote:
> I would suggest the following modification to Annotation.draw in
> text.py. All it does is set a clip box so that the annotation and
> arrow is still drawn, but the arrow is clipped at the axes boundary.
> It is a much nicer effect than the annotation disappearing. I have
> made this modification in my source locally, and it works very well,
> but I thought I would suggest here for inclusion into the main code
> base.
>
Can you explain more explicitly why you think this behavior is better?
For example, what is the point of annotating something if that
something is not visible?
Also, annotating texts are often placed outside of axes area. I don't
think clipping out the arrow is a good idea in this case.
Just in case, this is just a default behavior. You can override this
behavior without changing the mpl source code.
Regards,
-JJ

On Thu, Sep 15, 2011 at 5:08 AM, Youngung Jeong
<you...@gm...> wrote:
> but since contour function does not plot on the polar coordinate system
I think this is not True, but I may misunderstood you. Can you post an
example that does not work? Here is a simple example that shows it
does work. But I hardly use polar coordinate, and my example could be
too simple.
ax = subplot(111, polar=True)
aa = np.indices((10,10))
x = np.linspace(0., np.pi*2, 10)
y = np.linspace(0., 10, 10)
ax.pcolormesh(x, y, aa[0], cmap="gray")
ax.contour(x, y, aa[0])
Both pcolormesh and contour gives a consistent result.
However, I think, while the resulting contour lines are drawn in polar
coordinate system, the actual contouring is done in rectlinear
cooridinate system. So there may be some caveats.
Regards,
-JJ

On Thu, Sep 15, 2011 at 6:18 AM, Benjamin Root <ben...@ou...> wrote:
> There are some ways to do this, but I haven't tried them myself.
>
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/axislines.html
>
> Ben Root
>
You may better stick to the subplot with polar projection if your
original data is in polar coordinate.
The axislines module basically assumes that your data is in rectlinear
coordinate system. It only draws the gridlines and labels in
curvelinear system (although you can combine both).
Regards,
-JJ

On Thu, Sep 15, 2011 at 5:08 AM, Youngung Jeong
<you...@gm...> wrote:
> But it only gives one axis added to 'fig.axes'.
> Is there any work-around? Or am I missing some other feature of matplotlib?
Somehow, this is not clearly documented for the subplot command.
You need to use label parameter to create multiple axes at a same
position (for more details,
http://matplotlib.sourceforge.net/api/figure_api.html#matplotlib.figure.Figure.add_axes)
axr=fig.add_subplot(1,1,1, label="r")
axp=fig.add_subplot(1,1,1,projection='polar', label="p")
Regards,
-JJ

Having issues with installing the matplotlib package under Linux SUSE SLES 11
SP1 (s390): 
The original distribution gcc throws an error:
"src/ft2font.h:14:22: error: ft2build.h: No such file or directory"
when adding the file ft2build.h the linkage process stops at this error: 
G++ cannot find -lfreetype
When trying to manually install the latest Freetype2 package, I get an error
when using the package build commands, both at the "make" and "jam"
Errors:
-------
error at make command:
zbra:/opt/python/freetype2/freetype-2.4.6 # make
config.mk:25: builds/unix/unix-def.mk: No such file or directory
config.mk:26: builds/unix/unix-cc.mk: No such file or directory
make: *** No rule to make target `builds/unix/unix-cc.mk'. Stop.
error at jam command
zbra:/opt/python/freetype2/freetype-2.4.6 # jam install
don't know how to make install
...found 1 target(s)...
...can't find 1 target(s)...
Thanks in advance for any hints,
Claude 
-- 
View this message in context: http://old.nabble.com/Problems-installing-Matplotlib-under-SUSE-SLES-11-SP1-tp32468310p32468310.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Wed, Sep 14, 2011 at 4:34 PM, CAB <ca...@ya...> wrote:
>
>
> But now, let's say I want to italicize only the 'f' and 'x'. I can't find
> any easy way to do that while retaining the Arial font.
>
> And no, I don't want to use TeX. Target users' computers might not have
> it.
>
That's fine, that's why matplotlib imitates TeX with mathtext...
>
> I've tried using mathtext, but that uses one of mathtext's fonts, not mine
> (computer modern, etc., or sansserif, etc.)
>
I am sure there must be some way to change the font, but Arial might not be
supported for this... haven't tried though.
>
> I've tried setting mathregular, but that won't allow me to vary
> italic/nonitalic text.
>
>
Could you include some examples of what you tried?
> I'm left with not labeling the axes at all, but simply putting four
> different text objects next to each other and hoping that it doesn't look
> too jury-rigged.
>
>
Yeah, based on your requirements (italicize individual characters) your
choices are to either use the latex-like syntax that matplotlib allows for,
or to individually set the characters in their own text boxes. But, really,
I think if you rethink your requirements, then you will realize that
mathtext is the better way to go. It looks much more aesthetically pleasing
that way.
> Either that, or Photoshop the puppy.
>
>
Let's see if we can avoid that...
Cheers,
Ben Root

Hey, All,
I've combed the documentation ad nauseum, but I can't find a solution for this one, besides a very brute-force one.
Let's say I've set my default sans-serif font as 'Arial'. Fine.
Now, let's say, in a standard plot, I set the x label of this plot using something like:
matplotlib.pyplot.xlabel('f(x) (widgets/quatloo)')
Fine again.
But now, let's say I want to italicize only the 'f' and 'x'. I can't find any easy way to do that while retaining the Arial font.
And no, I don't want to use TeX. Target users' computers might not have it.
I've tried using mathtext, but that uses one of mathtext's fonts, not mine (computer modern, etc., or sansserif, etc.)
I've tried setting mathregular, but that won't allow me to vary italic/nonitalic text.
I'm left with not labeling the axes at all, but simply putting four different text objects next to each other and hoping that it doesn't look too jury-rigged.
Either that, or Photoshop the puppy.
Any suggestions?
Chad

Having issues with installing the matplotlib package under Linux SUSE SLES 11
SP1 (s390): 
The original distribution gcc throws an error: 
"src/ft2font.h:14:22: error: ft2build.h: No such file or directory"
when adding the file ft2build.h the linkage process stops at this error: 
G++ cannot find -lfreetype
When trying to manually install the latest Freetype2 package, I get an error
when using the package build commands, both at the "make" and "jam" 
Errors: 
-------
error at make command: 
zbra:/opt/python/freetype2/freetype-2.4.6 # make
config.mk:25: builds/unix/unix-def.mk: No such file or directory
config.mk:26: builds/unix/unix-cc.mk: No such file or directory
make: *** No rule to make target `builds/unix/unix-cc.mk'. Stop.
error at jam command
zbra:/opt/python/freetype2/freetype-2.4.6 # jam install
don't know how to make install
...found 1 target(s)...
...can't find 1 target(s)...
Thanks in advance for any hints, 
Claude 
-- 
View this message in context: http://old.nabble.com/Problems-installing-Matplotlib-under-SUSE-SLES-11-SP1-tp32467417p32467417.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Wed, Sep 14, 2011 at 3:08 PM, Youngung Jeong <you...@gm...>wrote:
> Hi,
>
> I have x-y grid data with z values and want to have a pixel view and
> contour view at the same time on the same position. Both cases should have
> polar coordinate system but since contour function does not plot on the
> polar coordinate system, it is plotted on a rectilinear projection with
> converting the polar grid into x-y grid. Please let me know if this isn't
> true.
>
> For pixel view, pcolormesh was used. The subplot was added with specifying
> the projection='polar', as something like below:
>
> >>> axp=fig.add_subplot(1,1,1,projection='polar')
> >>> axr=fig.add_subplot(2,2,1)
>
> Then, I will have two independent axes shown in the figure canvas.
> Since I want to place the two axes on the same position, if allowed, I
> would like to do:
>
> >>> axp=fig.add_subplot(1,1,1,projection='polar')
> >>> axr=fig.add_subplot(1,1,1)
>
> But it only gives one axis added to 'fig.axes'.
> Is there any work-around? Or am I missing some other feature of matplotlib?
>
> Youngung
>
>
There are some ways to do this, but I haven't tried them myself.
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/axislines.html
Ben Root

Hi,
I have x-y grid data with z values and want to have a pixel view and contour
view at the same time on the same position. Both cases should have polar
coordinate system but since contour function does not plot on the polar
coordinate system, it is plotted on a rectilinear projection with converting
the polar grid into x-y grid. Please let me know if this isn't true.
For pixel view, pcolormesh was used. The subplot was added with specifying
the projection='polar', as something like below:
>>> axp=fig.add_subplot(1,1,1,projection='polar')
>>> axr=fig.add_subplot(2,2,1)
Then, I will have two independent axes shown in the figure canvas.
Since I want to place the two axes on the same position, if allowed, I would
like to do:
>>> axp=fig.add_subplot(1,1,1,projection='polar')
>>> axr=fig.add_subplot(1,1,1)
But it only gives one axis added to 'fig.axes'.
Is there any work-around? Or am I missing some other feature of matplotlib?
Youngung

Hi,
I am trying to create a hatched region, with a "diagonal lines" hatch 
pattern. When using the PS backend, the hatch lines come out very 
narrow. Is there a way to increase the thickness of the hatch lines? 
I am using mpl version 1.0.1.
I think this question has been asked before (e.g., in 2008), but I 
couldn't find an answer.
Thanks!
-Jeff
P.S. I apologize if this message arrives twice.

On 09/14/2011 09:17 AM, Raymond Hawkins wrote:
> I'm getting odd behavior when I try to use fmin and pylab in the same program. The issue is illustrated in the code snippet below. As written, fmin won't work: the "print xopt" simply returns the contents of x0 as assigned in the line before fmin. If the "from pylab import *" line is commented out, however, then fmin runs as expected.
>
This is a good illustration of why "from package_x import *" is so 
strongly discouraged; it is throwing away one of the most important 
features of python--the default separation of packages into their own 
name spaces.
The only exception with respect to pylab is that for quick and dirty 
interactive use, particularly within ipython, it is sometimes worthwhile 
to sacrifice some name space separation for typing speed. But in a 
script that imports from more than one external package, it is best to 
always use explicit imports in some form.
The preferred idiom is to avoid importing pylab at all in scripts; 
instead, do this:
import numpy as np
import matplotlib.pyplot as plt
Eric
> I'm running python 2.7.2 on a MacBook Pro with a recent install& upgrade of scipy and matplotlib via macports. Any suggestions would be appreciated.
>
> -------------------------------------
>
> #!/opt/local/bin/python
>
> from scipy import *
> from scipy.optimize import fmin
> import matplotlib
> matplotlib.use('MacOSX')
> from pylab import *
>
> def rosen(x): # The Rosenbrock function
> return sum(100.0*(x[1:]-x[:-1]**2.0)**2.0 + (1-x[:-1])**2.0)
>
> x0 = [1.3, 0.7, 0.8, 1.9, 1.2]
>
> xopt = fmin(rosen, x0)
>
> print xopt
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs& more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, Sep 14, 2011 at 2:17 PM, Raymond Hawkins <rha...@ea...>wrote:
> I'm getting odd behavior when I try to use fmin and pylab in the same
> program. The issue is illustrated in the code snippet below. As written,
> fmin won't work: the "print xopt" simply returns the contents of x0 as
> assigned in the line before fmin. If the "from pylab import *" line is
> commented out, however, then fmin runs as expected.
>
> I'm running python 2.7.2 on a MacBook Pro with a recent install & upgrade
> of scipy and matplotlib via macports. Any suggestions would be appreciated.
>
> -------------------------------------
>
> #!/opt/local/bin/python
>
> from scipy import *
> from scipy.optimize import fmin
> import matplotlib
> matplotlib.use('MacOSX')
> from pylab import *
>
> def rosen(x): # The Rosenbrock function
> return sum(100.0*(x[1:]-x[:-1]**2.0)**2.0 + (1-x[:-1])**2.0)
>
> x0 = [1.3, 0.7, 0.8, 1.9, 1.2]
>
> xopt = fmin(rosen, x0)
>
> print xopt
>
Because pylab brings the numpy namespace into the current namespace, numpy's
fmin is imported and replaces the previously def'ed fmin from
scipy.optimize. Numpy's fmin function is completely different from scipy's
fmin. Try putting the "from scipy.optimize import fmin" after the pylab
import line. Or, do something like "from scipy.optimize import fmin as
fminimize" to avoid name collision.
I hope that helps.
Ben Root

Hi,
I am trying to create a hatched region, with a "diagonal lines" hatch 
pattern. When using the PS backend, the hatch lines come out very 
narrow. Is there a way to increase the thickness of the hatch lines? 
I am using mpl version 1.0.1.
I think this question has been asked before (e.g., in 2008), but I 
couldn't find an answer.
Thanks!
-Jeff

I'm getting odd behavior when I try to use fmin and pylab in the same program. The issue is illustrated in the code snippet below. As written, fmin won't work: the "print xopt" simply returns the contents of x0 as assigned in the line before fmin. If the "from pylab import *" line is commented out, however, then fmin runs as expected.
I'm running python 2.7.2 on a MacBook Pro with a recent install & upgrade of scipy and matplotlib via macports. Any suggestions would be appreciated.
-------------------------------------
#!/opt/local/bin/python
from scipy import *
from scipy.optimize import fmin
import matplotlib
matplotlib.use('MacOSX')
from pylab import *
def rosen(x): # The Rosenbrock function 
 return sum(100.0*(x[1:]-x[:-1]**2.0)**2.0 + (1-x[:-1])**2.0) 
 
x0 = [1.3, 0.7, 0.8, 1.9, 1.2] 
xopt = fmin(rosen, x0) 
print xopt

On 09/13/2011 06:36 AM, Leidner, Mark wrote:
>
> Dear Python/Matplotlib/Ogr Users:
>
> We are recent converts to Python, and are having trouble with some of
> its functionalities.
> We'd like to submit our case for your consideration in hopes to get some
> educated help on the subject.
>
> The problem:
> When trying to use contour collections generated by contourf, the
> resulting shapefile contains overly simplified contours which poorly
> approximate the underlying field.
>
> To reproduce the problem, we wrote a python script that specifies a 2-d
> analytical shape. This shape has small noise perturbations added, in
> order to simulate natural geophysical fields (wind speed, for example).
Your illustration seems horrendously complex. Can you distill it down 
to a simplest-possible case? Doing so might help you figure out where 
the problem is. I don't think it has anything to do with path 
simplification, because that occurs when the path is rendered. If I 
understand correctly, what mpl is plotting directly from your data is 
fine; you are running into surprises with the shapefile that you are 
generating from what mpl is using for its plotting. So, the problem 
would seem to be in the generation of the shapefile, not in mpl.
Eric
> .
> The shape is being sliced by contourf command, and the resulting
> collection is being plotted as a PDF file (PostScript) and converted to
> an output Shapefile using OGR module.
>
> We also wrote several functions, defined inside the script, that take
> care of unpacking and exporting the contour collections as polygon or
> multipolygon shapefile entities thru OGR shapefile methods.
>
> Two zoomed in views are attached (screenshot_* attachments): (1) a
> portion of the PDF figure, and (2) a visualization of the shapefile data
> for the same area. The PDF figure shows a contour line with fine scale
> structure (the fine structures are the noise we added) while a lack of
> fine structure is seen in the output shapefile. The PDF plot is what we
> expect. The output shapefile geometry is very different from what we
> would expect.
>
> We can't understand how a call to contourf can produce a plot that looks
> right AND shapefile data (taken from contourf's collections) that appear
> to grossly simplify the geometry. We expect that both the plot and the
> shapefile come from the same contourf function results, yet look totally
> different.
>
> We'd like to ask whether anyone else encountered limitations regarding
> the complexity of shapefiles written out by python?
> Is this a possible problem with matplotlib.pyplot.contourf.collections
> method?
>
> We would appreciate your help very much!
> Test script and the resulting shapefile data set are attached.
>
> Thank you!
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> S. Mark Leidner
> Staff Scientist/Oklahoma Business Development
> Atmospheric and Environmental Research, Inc.
> 350 David L. Boren Blvd, Suite 1535
> Norman, OK 73072-7264 USA
> ph: +1 405 325-1137
> cell: +1 781 354-5969
>
>
> Sergey Vinogradov, Ph.D., Staff Scientist
> Atmospheric and Environmental Research, Inc.
> 131 Hartwell Ave., Lexington, MA 02421, USA
> Phone: 1-781-761-2256 se...@ae...
> Fax: 1-781-761-2299 http://www.aer.com
> Web page :: http://ocean.mit.edu/~svinogra
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs& more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Tue, Sep 13, 2011 at 1:02 PM, Leidner, Mark <mle...@ae...> wrote:
> Ben,
>
> Good to hear from you.
>
> We are using matplotlib v1.0.1_5 on an install from Macports.
>
> Hearing that there is simplification logic is very intriguing.
>
> Mark
>
>
Try this and tell me if the results are better. Right before the line where
you call to_polygons(), add this line:
multipolygon.should_simplify = False
The simplification logic gets triggered automatically if the
rcParam['path.simplify'] is True and if there are more them 128 vertices and
those vertices are all simple LINETO segments. I think in your situation,
this is true. So, we can force a non-simplification directly like above, or
set your rcParams file with path.simplify to False (but this may make graph
rendering significantly slower and more resource intensive overall).
The path simplification logic is designed so that one does not see any
visual differences, however, there might need to be some additional logic
for those who are accessing the path directly.
I hope this helps!
Ben Root

Ben,
Good to hear from you.
We are using matplotlib v1.0.1_5 on an install from Macports.
Hearing that there is simplification logic is very intriguing.
Mark
On 09/13/11, Benjamin Root <ben...@ou...> wrote:
> On Tue, Sep 13, 2011 at 11:36 AM, Leidner, Mark <mle...@ae...> wrote:
> 
> > 
> > 
> > 
> > 
> > Dear Python/Matplotlib/Ogr Users:
> > 
> > We are recent converts to Python, and are having trouble with some of its functionalities.
> > We'd like to submit our case for your consideration in hopes to get some educated help on the subject.
> > 
> > 
> > 
> > The problem:
> > When trying to use contour collections generated by contourf, the resulting shapefile contains overly simplified contours which poorly approximate the underlying field.
> > 
> > To reproduce the problem, we wrote a python script that specifies a 2-d analytical shape. This shape has small noise perturbations added, in order to simulate natural geophysical fields (wind speed, for example).
> > 
> > 
> > .
> > The shape is being sliced by contourf command, and the resulting collection is being plotted as a PDF file (PostScript) and converted to an output Shapefile using OGR module.
> > 
> > 
> > We also wrote several functions, defined inside the script, that take care of unpacking and exporting the contour collections as polygon or multipolygon shapefile entities thru OGR shapefile methods.
> > 
> > 
> > 
> > Two zoomed in views are attached (screenshot_* attachments): (1) a portion of the PDF figure, and (2) a visualization of the shapefile data for the same area. The PDF figure shows a contour line with fine scale structure (the fine structures are the noise we added) while a lack of fine structure is seen in the output shapefile. The PDF plot is what we expect. The output shapefile geometry is very different from what we would expect.
> > 
> > 
> > 
> > 
> > We can't understand how a call to contourf can produce a plot that looks right AND shapefile data (taken from contourf's collections) that appear to grossly simplify the geometry. We expect that both the plot and the shapefile come from the same contourf function results, yet look totally different. 
> > 
> > 
> > 
> > We'd like to ask whether anyone else encountered limitations regarding the complexity of shapefiles written out by python?
> > Is this a possible problem with matplotlib.pyplot.contourf.collections method?
> > 
> > 
> > We would appreciate your help very much!
> > 
> > Test script and the resulting shapefile data set are attached.
> > 
> > Thank you!
> > 
> > 
> > 
> > 
> 
> I am not able to run the test case because I don't have osgeo (also note that Nio isn't used in the given example). However, I might have a guess as to what is going on. In mpl, there is path simplication logic to reduce complexity of the paths. There have been bugs in the past with this logic, and so it would be valuable to know what version of matplotlib you are using.
> 
> 
> 
> This simplification code is probably being activated within the call to to_polygons(). Which version of matplotlib are you using?
> 
> Ben Root
> 
> 
> 
> 
> 
> 

On Tue, Sep 13, 2011 at 11:36 AM, Leidner, Mark <mle...@ae...> wrote:
>
> Dear Python/Matplotlib/Ogr Users:
>
> We are recent converts to Python, and are having trouble with some of its
> functionalities.
> We'd like to submit our case for your consideration in hopes to get some
> educated help on the subject.
>
> The problem:
> When trying to use contour collections generated by contourf, the resulting
> shapefile contains overly simplified contours which poorly approximate the
> underlying field.
>
> To reproduce the problem, we wrote a python script that specifies a 2-d
> analytical shape. This shape has small noise perturbations added, in order
> to simulate natural geophysical fields (wind speed, for example).
> .
> The shape is being sliced by contourf command, and the resulting collection
> is being plotted as a PDF file (PostScript) and converted to an output
> Shapefile using OGR module.
>
> We also wrote several functions, defined inside the script, that take care
> of unpacking and exporting the contour collections as polygon or
> multipolygon shapefile entities thru OGR shapefile methods.
>
> Two zoomed in views are attached (screenshot_* attachments): (1) a portion
> of the PDF figure, and (2) a visualization of the shapefile data for the
> same area. The PDF figure shows a contour line with fine scale structure
> (the fine structures are the noise we added) while a lack of fine structure
> is seen in the output shapefile. The PDF plot is what we expect. The
> output shapefile geometry is very different from what we would expect.
>
> We can't understand how a call to contourf can produce a plot that looks
> right AND shapefile data (taken from contourf's collections) that appear to
> grossly simplify the geometry. We expect that both the plot and the
> shapefile come from the same contourf function results, yet look totally
> different.
>
> We'd like to ask whether anyone else encountered limitations regarding the
> complexity of shapefiles written out by python?
> Is this a possible problem with matplotlib.pyplot.contourf.collections
> method?
>
> We would appreciate your help very much!
> Test script and the resulting shapefile data set are attached.
>
> Thank you!
>
>
I am not able to run the test case because I don't have osgeo (also note
that Nio isn't used in the given example). However, I might have a guess as
to what is going on. In mpl, there is path simplication logic to reduce
complexity of the paths. There have been bugs in the past with this logic,
and so it would be valuable to know what version of matplotlib you are
using.
This simplification code is probably being activated within the call to
to_polygons(). Which version of matplotlib are you using?
Ben Root

Dear Python/Matplotlib/Ogr Users:
We are recent converts to Python, and are having trouble with some of its functionalities.
We'd like to submit our case for your consideration in hopes to get some educated help on the subject.
The problem:
When trying to use contour collections generated by contourf, the resulting shapefile contains overly simplified contours which poorly approximate the underlying field.
To reproduce the problem, we wrote a python script that specifies a 2-d analytical shape. This shape has small noise perturbations added, in order to simulate natural geophysical fields (wind speed, for example).
.
The shape is being sliced by contourf command, and the resulting collection is being plotted as a PDF file (PostScript) and converted to an output Shapefile using OGR module.
We also wrote several functions, defined inside the script, that take care of unpacking and exporting the contour collections as polygon or multipolygon shapefile entities thru OGR shapefile methods.
Two zoomed in views are attached (screenshot_* attachments): (1) a portion of the PDF figure, and (2) a visualization of the shapefile data for the same area. The PDF figure shows a contour line with fine scale structure (the fine structures are the noise we added) while a lack of fine structure is seen in the output shapefile. The PDF plot is what we expect. The output shapefile geometry is very different from what we would expect.
We can't understand how a call to contourf can produce a plot that looks right AND shapefile data (taken from contourf's collections) that appear to grossly simplify the geometry. We expect that both the plot and the shapefile come from the same contourf function results, yet look totally different. 
We'd like to ask whether anyone else encountered limitations regarding the complexity of shapefiles written out by python?
Is this a possible problem with matplotlib.pyplot.contourf.collections method?
We would appreciate your help very much!
Test script and the resulting shapefile data set are attached.
Thank you!
S. Mark Leidner
Staff Scientist/Oklahoma Business Development
Atmospheric and Environmental Research, Inc.
350 David L. Boren Blvd, Suite 1535
Norman, OK 73072-7264 USA
ph: +1 405 325-1137
cell: +1 781 354-5969
Sergey Vinogradov, Ph.D.,      Staff Scientist
Atmospheric and Environmental Research, Inc.
131 Hartwell Ave., Lexington, MA 02421, USA
Phone: 1-781-761-2256     se...@ae...
Fax:   1-781-761-2299    http://www.aer.com
Web page ::    http://ocean.mit.edu/~svinogra

Answering my own question... It's a question of order. I needed to
set_yscale('log') before calling clabel.
Jon
> Hi all,
> 
> I've run into a problem with a contour plot that has a
> logarithmic
> y-axis. The spacing around the inline contour label is too
> large,
> leading to a large segment of the contour being blocked
> out/erased. I
> tried making the plot with a linear axis and it didn't happen
> in that
> case, so I'm thinking that it has to do with the contour
> labeling
> routine not understanding logarithmic scaling. Attached is a
> plot
> demonstrating the problem. Is there a solution for this?
> 
> Jon Slavin