Nils Wagner <nwagner@...1052...> writes:
File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line
357, in _auto_legend_data
hlines = handle.get_lines()
AttributeError: LineCollection instance has no attribute 'get_lines'
It seems that get_lines() was removed from LineCollection in revision
2052 by Eric Firing:
r2052 | efiring | 2006-02-11 22:56:42 +0200 (Sat, 11 Feb 2006) | 3 lines
Add autolim kwarg to axes.add_collection; change get_verts()
methods of collections accordingly.
Perhaps Eric knows best how to fix _auto_legend_data()?
···
--
Jouni K. Sepp�nen
Jouni K. Sepp�nen wrote:
Nils Wagner <nwagner@...1052...> writes:
File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line
357, in _auto_legend_data
hlines = handle.get_lines()
AttributeError: LineCollection instance has no attribute 'get_lines'
It seems that get_lines() was removed from LineCollection in revision
2052 by Eric Firing:
> r2052 | efiring | 2006-02-11 22:56:42 +0200 (Sat, 11 Feb 2006) | 3 lines
>
> Add autolim kwarg to axes.add_collection; change get_verts()
> methods of collections accordingly.
Perhaps Eric knows best how to fix _auto_legend_data()?
It is fixed now in svn--to the extent that it ever was.
I put back get_lines() in collections and fixed a related bug in legend, so the test script now works in the sense that it makes a legend. It puts in an unlabeled line, presumably corresponding to the line collection making up the error bars. Maybe legend provides a way to avoid this. I haven't looked.
The larger problem, and the one that probably made me yank get_lines (without realizing the legend code was using it--my mistake--I do try to check for things like that) is that legend really wants to know the draw-time locations of all plot elements, and for collections (among other things) this cannot be determined in general. The collection get_lines and get_verts methods can give the right answer to legend only if the data and offset transforms are the same. Sometimes they are, sometimes they are not. LineCollection.get_lines() probably could be improved to do a better job than at present, but never a perfect one.
This is an example of a more widespread problem that we have thought about and discussed (including some good ideas from John, of course), but solving it is not simple. For the time being, at least, we are stuck with some imperfections.
In any case, thanks for bringing the legend/LineCollection bug to my attention. This is the sort of thing it is nice to get cleaned up before the next release, coming soon. Do you know of some other simple bugs like this we should look at ASAP?
Eric
I put back get_lines() in collections and fixed a related bug in legend,
so the test script now works in the sense that it makes a legend. It
puts in an unlabeled line, presumably corresponding to the line
collection making up the error bars. Maybe legend provides a way to
avoid this. I haven't looked.
If I'm understanding the problem you are describing correctly, it
looks like _nolegend_ needs to be set here. For artists we do not want
to be included in the legend, the label should be set to '_nolegend_'
and legend will ignore it in auto-legending. Or at least it should
and if it is not it is a bug.
The larger problem, and the one that probably made me yank get_lines
(without realizing the legend code was using it--my mistake--I do try to
check for things like that) is that legend really wants to know the
draw-time locations of all plot elements, and for collections (among
other things) this cannot be determined in general. The collection
get_lines and get_verts methods can give the right answer to legend only
if the data and offset transforms are the same. Sometimes they are,
sometimes they are not. LineCollection.get_lines() probably could be
improved to do a better job than at present, but never a perfect one.
One approach is to make every artist provide a get window extent which
returns a bounding box. There is the issue of how to get the renderer
before draw time, but we could fix this. It would be nice for draw
time layout algorithms to be able to assume this method, and a few
objects already provide it, eg text.
This is an example of a more widespread problem that we have thought
about and discussed (including some good ideas from John, of course),
but solving it is not simple. For the time being, at least, we are
stuck with some imperfections.
In any case, thanks for bringing the legend/LineCollection bug to my
attention. This is the sort of thing it is nice to get cleaned up
before the next release, coming soon. Do you know of some other simple
bugs like this we should look at ASAP?
I added unit/legend_unit.py script to create legends using a scatter
and vlines, which create RegPolyCollections and LineCollections. We
should use more stuff like this in general, unit scripts which
exercise the more arcane usages.
JDH
···
On 4/7/07, Eric Firing <efiring@...202...> wrote: