matplotlib-devel Mailing List for matplotlib (Page 2)

Andrew Straw wrote:
> Jeff Whitaker wrote:
> 
>> Dr. Phillip M. Feldman wrote:
>> 
>> 
>>> Basemap offers many projections, but is missing two of the most useful ones:
>>>
>>> - For satellite applications, it would be helpful to have a "camera"
>>> projection, i.e., a projection that shows the Earth as viewed from a
>>> specified point in space. This would be a generalization of the current
>>> geostationary projection.
>>> 
>>> 
>>> 
>> Philip: Don't think the proj4 lib supports this.
>> 
>> 
> I think it's already in there -- see nsper, for near sided perspective.
>
> -Andrew
>
> 
Hello Andrew-
It does sound as thought nsper is exactly what I need, but when I try to 
use it, I get the following error message:
ValueError: 'nsper' is an unsupported projection.
The supported projections are:
 aeqd Azimuthal Equidistant
 poly Polyconic
 gnom Gnomonic
 moll Mollweide
 tmerc Transverse Mercator
 nplaea North-Polar Lambert Azimuthal
 gall Gall Stereographic Cylindrical
 mill Miller Cylindrical
 merc Mercator
 stere Stereographic
 npstere North-Polar Stereographic
 geos Geostationary
 vandg van der Grinten
 laea Lambert Azimuthal Equal Area
 mbtfpq McBryde-Thomas Flat-Polar Quartic
 sinu Sinusoidal
 spstere South-Polar Stereographic
 lcc Lambert Conformal
 npaeqd North-Polar Azimuthal Equidistant
 eqdc Equidistant Conic
 cyl Cylindrical Equidistant
 omerc Oblique Mercator
 aea Albers Equal Area
 spaeqd South-Polar Azimuthal Equidistant
 ortho Orthographic
 cass Cassini-Soldner
 splaea South-Polar Lambert Azimuthal
 robin Robinson
Phillip 

On 2010年01月24日 21:17 , Phillip M. Feldman wrote:
> Even more useful than a geosynchronous projection is a camera projection
> that allows one to place the viewer at any location in space (i.e., any
> latitude and longitude for the nadir point, and any altitude). (I wrote
> something like this is Fortran 25 years ago). Generalizing the existing
> geostationary projection to turn it into a camera projection would make
> it far more useful. I hope that someone will consider making this change.
The projection code is not written by the basemap team. Rather, it uses the 
PROJ.4 library. You may direct feature requests for the PROJ.4 library here:
 http://trac.osgeo.org/proj/
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
> 
>> Basemap offers many projections, but is missing two of the most useful ones:
>>
>> - For satellite applications, it would be helpful to have a "camera"
>> projection, i.e., a projection that shows the Earth as viewed from a
>> specified point in space. This would be a generalization of the current
>> geostationary projection.
>> 
>> 
>
> Philip: Don't think the proj4 lib supports this.
> 
I think it's already in there -- see nsper, for near sided perspective.
-Andrew

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
>> Jeff Whitaker wrote:
>> 
>>> <snip>
>>> Philip: That's an error from the proj4 c library saying that it 
>>> didn't like one of the parameters you used to define the 
>>> projection. Since you didn't include the parameters you used, I 
>>> can't say which one is the culprit.
>>>
>>> -Jeff
>>>
>>> 
>>
>> 
> Philip: I believe that lat_0 must be zero for the geostationary 
> projection (you have to be looking down on the equator). I usually 
> leave the lat_0 parameter off entirely, in which case zero is 
> assumed. I'll try to catch that and raise a more insightful error 
> message.
>
> -Jeff
>
Hm. I suppose that you are right. "Geostationary" does imply that the 
viewer is 35786.2 km above the equator.
What would be more useful is a geosynchronous projection. This would 
allow the viewer to be located at any latitude. Geostationary is a 
special case of geosynchronous.
Even more useful than a geosynchronous projection is a camera projection 
that allows one to place the viewer at any location in space (i.e., any 
latitude and longitude for the nadir point, and any altitude). (I wrote 
something like this is Fortran 25 years ago). Generalizing the existing 
geostationary projection to turn it into a camera projection would make 
it far more useful. I hope that someone will consider making this change.
Phillip

Dr. Phillip M. Feldman wrote:
> Basemap offers many projections, but is missing two of the most useful ones:
>
> - For satellite applications, it would be helpful to have a "camera"
> projection, i.e., a projection that shows the Earth as viewed from a
> specified point in space. This would be a generalization of the current
> geostationary projection.
> 
Philip: Don't think the proj4 lib supports this.
> - Basemap current offers North-Polar and South-Polar azimuthal equidistant
> projections. A useful generalization is the azimuthal equidistant
> projection with a specified latitude and longitude at the center of the map.
> 
That's already implemented - just use the 'aeqd' projection, specifying 
lat_0,lon_0,width and height keywords.
-Jeff

If and when you have time on your hands, a projection that is rarely used but
quite interesting is Guyou's Doubly-Periodic Projection. (See the first and
third figures in http://www.members.shaw.ca/quadibloc/maps/mcf0703.htm). 
This projection puts the worst distortion at four points in the ocean, and
does a reasonable job of preserving the shapes and relative sizes of the
major land masses.
-- 
View this message in context: http://old.nabble.com/missing-projections-tp27297141p27297216.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Basemap offers many projections, but is missing two of the most useful ones:
- For satellite applications, it would be helpful to have a "camera"
projection, i.e., a projection that shows the Earth as viewed from a
specified point in space. This would be a generalization of the current
geostationary projection.
- Basemap current offers North-Polar and South-Polar azimuthal equidistant
projections. A useful generalization is the azimuthal equidistant
projection with a specified latitude and longitude at the center of the map.
-- 
View this message in context: http://old.nabble.com/missing-projections-tp27297141p27297141.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi,
Combining "stepfilled" with log scale sometimes gives inappropriate plots:
a=[4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5]
hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True)
The problem is not restricted to the case here with more bins than unique 
elements, but sometimes reducing the bin number makes the issue go away.
Cheers,
Olle

Hello,
The current matplotlib installers for Windows are built with Microsoft
Visual Studio 2003/2008 compilers. It is relatively easy once you have
all the dependencies and it gives you working binaries for Python 2.4,
2.5, 2.6, and 2.6 64-bit.
I have found the instructions at
<http://matplotlib.sourceforge.net/users/installing.html> and
<http://docs.python.org/install/> sufficient for building matplotlib
from sources. My setup.cfg is attached.
Matplotlib, when compiled with mingw, had some problems saving png
images
<http://www.mail-archive.com/mat...@li.../msg11791.html>.
Can you save to pdf?
I have not tried libpng-1.2.40, it is three weeks old, but version
1.2.42 works when PNG_DEPRECATED, PNG_USE_RESULT, PNG_NORETURN,
PNG_ALLOCATED, PNG_DEPSTRUCT, PNG_STDIO_SUPPORTED, and
PNG_SEQUENTIAL_READ_SUPPORTED are defined.
I can not reproduce the GTK problems with the latest official matplotlib
0.99.1, pyGTK 2.12.1-3, and GTK 2.16.6 binaries. Are you using the GTK
or GTKAgg backend?
--
Christoph Gohlke
Laboratory for Fluorescence Dynamics
University of California, Irvine
http://www.lfd.uci.edu/~gohlke/
On 1/20/2010 2:21 PM, Patrick Marsh wrote:
> Greetings,
> 
> I recently recreated my development environment on my windows machine
> and have attempted to build MPL off the SVN trunk. I am able to
> successfully compile and build windows installers using both Python
> 2.5.4 and Python 2.6.4 using MinGW. However, when I install my builds
> and try to use them I have some issues.
> 
> First, I was unable to build MPL using libpng-1.4.0. I was forced to
> revert to libpng-1.2.40
> 
> Python 2.5.4
> 1. After successfully building MPL with GTK support (Yes - I can import
> GTK in my Python interpreter with no problems.), I am unable to show or
> save figures using MPL. Using IPython, I was able to create the figure
> instance but Python quits when trying to display or save said figure
> instance.
> 
> 2. After rebuilding MPL without GTK support, I get the same errors.
> 
> 
> Python 2.6.4
> 1. I am able to display figure instances using MPL build with GTK
> support. However, when I try to save the figure (in any format) Python
> quits.
> 
> 2. I get the same behavior when I build MPL without GTK support.
> 
> 
> I have tried building MPL by building the dependencies myself and also
> with using the win32_static/win32_static_mingw32 folders and get the
> same issues either way. I am hoping whoever is responsible for building
> the windows binaries is willing to work with me to solve these issues.
> I'd like to be able to build MPL successfully using both Python 2.5.4
> and Python 2.6.4 and then write up a detailed How-To build on Windows.
> 
> Any help would be appreciated.
> 
> Thanks,
> Patrick

I also ran into this problem recently and was disappointed to find that the
notch was based on a normal approximation.
While there are a number of ways to calculate the notch size, it would be
useful to allow the user to supply (either as an optional keyword, or as a
vector input for the notch keyword) their own notch locations. 
For example, I have some code that calculates bootstrapped confidence
intervals - in the case of a significantly non-normal distribution this
would be a better way to find the notch boundaries (which will likely not
even be symmetric). While I'm not advocating building other calculations in,
having the option to supply my own notch locations would be immensely
useful. The default should probably remain as is (IMO) but should also be
mentioned in the documentation as being based on that assumption.
I'm happy to submit an update to do just that if it's seen as a good idea.
Steve.
Andrew Straw wrote:
> 
> Andrew Straw wrote:
>> Also, I think that formula is only for normally distributed data. Which, 
>> especially if you're using boxplots, medians, and quartiles, may not be 
>> a valid assumption.
>>
>> Maybe we should at least raise a warning when someone uses notch=1. The 
>> current implementation seems dubious, at best, IMO.
>> 
> 
> (I sent the previous version of this email a bit too early -- this is
> slightly edited for clarity.)
> 
> I read the following reference:
> 
> McGill, R., Tukey, J.W., and Larsen, W.A. (1978) "Variations of
> Boxplots", The American Statistician, 32:12-16.
> 
> McGill et al. have an entire section devoted to "Choice of Notch Size",
> starting with:
> 
> "In notched box plots, one is, of course, faced with the question of how
> best to determine the widths of the notches. Many methods, both
> classical and non-parametric, might be considered. None will likely be
> best in all cases."
> 
> ...
> 
> 
-- 
View this message in context: http://old.nabble.com/boxplot-notch-tp26798967p27249739.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Greetings,
I recently recreated my development environment on my windows machine and
have attempted to build MPL off the SVN trunk. I am able to successfully
compile and build windows installers using both Python 2.5.4 and Python
2.6.4 using MinGW. However, when I install my builds and try to use them I
have some issues.
First, I was unable to build MPL using libpng-1.4.0. I was forced to revert
to libpng-1.2.40
Python 2.5.4
1. After successfully building MPL with GTK support (Yes - I can import GTK
in my Python interpreter with no problems.), I am unable to show or save
figures using MPL. Using IPython, I was able to create the figure instance
but Python quits when trying to display or save said figure instance.
2. After rebuilding MPL without GTK support, I get the same errors.
Python 2.6.4
1. I am able to display figure instances using MPL build with GTK support.
 However, when I try to save the figure (in any format) Python quits.
2. I get the same behavior when I build MPL without GTK support.
I have tried building MPL by building the dependencies myself and also with
using the win32_static/win32_static_mingw32 folders and get the same issues
either way. I am hoping whoever is responsible for building the windows
binaries is willing to work with me to solve these issues. I'd like to be
able to build MPL successfully using both Python 2.5.4 and Python 2.6.4 and
then write up a detailed How-To build on Windows.
Any help would be appreciated.
Thanks,
Patrick
-- 
Patrick Marsh
Ph.D. Student / Graduate Research Assistant
School of Meteorology / University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
National Severe Storms Laboratory
http://www.patricktmarsh.com

Hi,
 I do see strange behavior when using "Zoom to rectangle"
on my figures embedded in gtk through glade.
When clicking on the figure and start drawing the rectangle,
the bottom axis moves up as well as the graph which screw up
the whole figure during the rectangle definition. When releasing
the mouse button the figure looks ok.
I attach a small script together with glade file (slightly modified
from the matplotlib examples) that allows to reproduce the problem:
 -> launch the script, press the "Zoom to rectangle button" and start
drawing the rectangle region on the graph, you will see the issue...
It as to be noticed that pure gtk version (without glade) does work
properly.
I'm on MacOsX 10.5.8 using gtk.gtk_version (2, 18, 6)
and gtk.pygtk_version (2, 16, 0) with python 2.6
Hope someone could help me solving this annoying issue.
Regards,
David

John Haiducek wrote:
> I have a matplotlib application whose memory consumption increases with
> each call to matplotlib.colorbar.draw_all(). I'm using the matplotlib
> 0.99.0 as found in the ubuntu karmic (universe) repository. 
> 
> I've filed a bug report, ID 2934351, titled "Possible memory leak in
> colorbar", with a minimum working example attached to the bug report.
Thanks for the report. I closed the report with a comment. What you 
found is a case of confusing code, not a true memory leak in mpl. I 
will try to clarify it a bit without getting into a major refactoring.
Eric
> 
> John Haiducek
> 
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, 2010年01月18日 at 08:19 -1000, Eric Firing wrote:
> Thanks for the report. I closed the report with a comment. What you 
> found is a case of confusing code, not a true memory leak in mpl. I 
> will try to clarify it a bit without getting into a major refactoring.
> 
> Eric
Thanks Eric, I changed my app to create a new colorbar every time it
redraws the plot and that fixes the memory issue for me.
John

I have a matplotlib application whose memory consumption increases with
each call to matplotlib.colorbar.draw_all(). I'm using the matplotlib
0.99.0 as found in the ubuntu karmic (universe) repository. 
I've filed a bug report, ID 2934351, titled "Possible memory leak in
colorbar", with a minimum working example attached to the bug report.
John Haiducek

Eric Firing wrote:
> Ian,
>
> I have applied your patch and modified contourf_demo slightly to illustrate
> interior masking. Thanks very much for the beautiful work! These contour
> bugs that you fixed were major mpl problems--general embarrassments, and
> specific impediments to my own applications, since the data sets I work with
> often have masked interior regions. (And, I also use line contours on top
> of filled contours, so the saddle-point decision fix helps as well.)
I'm glad my contribution passes the quality control checks!
> It occurs to me that there might be a nice refinement: when following a
> masked boundary, how hard would it be to cross the single-cell gap
> diagonally instead of proceeding step-wise along the boundary? In the case
> of the circular masked region that I added to the contourf_demo, this would
> simply smooth out the boundary of that region.
>
> Eric
I think it would be fairly easy to do half a solution to this, but
difficult to do it properly. It would be easy to change the
edge_walker function to miss out a grid point when, for example,
moving clockwise around a masked region from an i-edge to a j-edge.
But what should happen in the situations when a contour level
intersects one of those two edges: either (a) do nothing, or (b) still
do the diagonal cut-off. The do nothing option (a) is easy (!) but
means that there will be a mixture of diagonal cut-offs and stepwise
changes, which won't look particularly elegant, whereas (b) will mean
some pretty serious rewriting as the contouring code will have to deal
with these diagonal edges for both contour lines and filled contours,
and there will have to be some slightly arbitrary interpolation from
the grid z-values to these diagonal edges. So the answer to your
question is "difficult but doable".
My preference is to leave it as it is, as the current blocky solution
is what I expect to see. But I am happy to take a look at it if
you/others think it is a good idea.
On the subject of contouring masked grids, I sometimes want to specify
which grid squares are masked rather than which grid points, i.e. for
a grid of nx by ny points I want to specify a mask of (nx-1) by (ny-1)
squares. I've discovered that cntr.c uses such a square mask,
creating it from the incoming point mask. It would therefore be easy
to add support for such a grid by changing the python front end to
pass it in. Is this a good idea and would this be useful to others,
or am I being overly simplistic?
Ian
P.S. Eric, I see that you work with Kelvin Richards - he was my PhD
supervisor many years ago. Small world!

Neil Crighton wrote:
> Hi,
>
> I posted a patch that makes some small changes to minor tick autoscaling:
>
> http://sourceforge.net/tracker/?
> func=detail&aid=2924245&group_id=80706&atid=560722
>
> If someone could check it's ok and apply it, that would be great.
> 
I can't see the harm, so I applied this in r8082. Also, the patch did
two things. The second thing, "don't create minor ticks on top of
existing major ticks", I pulled out into a second patch and applied in
r8083.

Ian Thomas wrote:
> Hello all,
> 
> I think I have fixed two bugs in the contouring code (src/cntr.c):
> 1) inconsistent behaviour in how contour and contourf handle saddle
> grid squares, and
> 2) incorrect handling of masked regions in filled contour plots.
Ian,
I have applied your patch and modified contourf_demo slightly to 
illustrate interior masking. Thanks very much for the beautiful work! 
These contour bugs that you fixed were major mpl problems--general 
embarrassments, and specific impediments to my own applications, since 
the data sets I work with often have masked interior regions. (And, I 
also use line contours on top of filled contours, so the saddle-point 
decision fix helps as well.)
It occurs to me that there might be a nice refinement: when following a 
masked boundary, how hard would it be to cross the single-cell gap 
diagonally instead of proceeding step-wise along the boundary? In the 
case of the circular masked region that I added to the contourf_demo, 
this would simply smooth out the boundary of that region.
Eric
> 
> Attached is a gzipped tar file containing an explanation of the bugs
> and what I've done, as well as an svn diff against HEAD and small
> example scripts to demonstrate the bugs before and after the fixes.
> 
> I have tested the fixes for the cases I normally come up with, but
> this is by no means exhaustive.
> 
> Ideally it would be good if someone who is more familiar with cntr.c
> than I am could take a look at what I've done and see if it is OK.
> 
> Ian Thomas
> ian...@go...
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
I posted a patch that makes some small changes to minor tick autoscaling:
http://sourceforge.net/tracker/?
func=detail&aid=2924245&group_id=80706&atid=560722
If someone could check it's ok and apply it, that would be great.
Cheers,
Neil
_______________________________________
http://www.astro.dur.ac.uk/~nhmc

Ian Thomas wrote:
> Hello all,
> 
> I think I have fixed two bugs in the contouring code (src/cntr.c):
> 1) inconsistent behaviour in how contour and contourf handle saddle
> grid squares, and
> 2) incorrect handling of masked regions in filled contour plots.
> 
> Attached is a gzipped tar file containing an explanation of the bugs
> and what I've done, as well as an svn diff against HEAD and small
> example scripts to demonstrate the bugs before and after the fixes.
> 
> I have tested the fixes for the cases I normally come up with, but
> this is by no means exhaustive.
> 
> Ideally it would be good if someone who is more familiar with cntr.c
> than I am could take a look at what I've done and see if it is OK.
Ian,
I will take a look, and commit the changes if things look OK. I suspect 
Mike D. and I are the most familiar with this code (apart from the 
original author--and I don't know who that is); both of us have tried 
unsuccessfully to solve the masked region problem. If you have solved 
these problems, that's fantastic!
Eric

Hello all,
I think I have fixed two bugs in the contouring code (src/cntr.c):
1) inconsistent behaviour in how contour and contourf handle saddle
grid squares, and
2) incorrect handling of masked regions in filled contour plots.
Attached is a gzipped tar file containing an explanation of the bugs
and what I've done, as well as an svn diff against HEAD and small
example scripts to demonstrate the bugs before and after the fixes.
I have tested the fixes for the cases I normally come up with, but
this is by no means exhaustive.
Ideally it would be good if someone who is more familiar with cntr.c
than I am could take a look at what I've done and see if it is OK.
Ian Thomas
ian...@go...

Andrew Straw wrote:
> Nico Schlömer wrote:
> 
>> Hey, and is there any sort of matplotlib market place where I could
>> put the file for general bashing/downloading once it can do more than
>> a sin-plot?
>> 
>> 
> Well, github is my suggestion. If it's a patchset of the MPL source, 
> then fork the MPL repository at http://github.com/astraw/matplotlib . If 
> it's a standalone thing, just create a new project. Github makes this 
> kind of sharing easy at all levels from casual one-off events to close 
> collaboration.
> 
We can also link to it from the matplotlib website once you have a 
location established, for example from here:
 http://matplotlib.sourceforge.net/users/toolkits.html
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Nico Schlömer wrote:
> Hey, and is there any sort of matplotlib market place where I could
> put the file for general bashing/downloading once it can do more than
> a sin-plot?
> 
Well, github is my suggestion. If it's a patchset of the MPL source, 
then fork the MPL repository at http://github.com/astraw/matplotlib . If 
it's a standalone thing, just create a new project. Github makes this 
kind of sharing easy at all levels from casual one-off events to close 
collaboration.
-Andrew

> Maybe you could port psfrag to pdf instead (my selfish desire...)
Ever tried
http://tug.ctan.org/tex-archive/support/pdfrack/
?
--Nico

Nico Schlömer wrote:
> The advantage that I see with TikZ is that the font is *exactly* the
> font used in the surrounding text, no matter the scaling of the axes.
I used to do that with psfrag -- it is a really nice tool. I miss it 
with pdftex. It does add an extra step, but it also supports any PS 
graphics. I wanted it the other day for a diagram I made with INkScape 
(I couldn't get the TeX plugin working...)
Maybe you could port psfrag to pdf instead (my selfish desire...)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...