Thanks. Should be fixed now in SVN.
Mike
Andrew Straw wrote:
···
Hi Mike, I think you introduced a regression in r7131. I picked this up
using "python backend_driver.py agg":examples/api$ python custom_projection_example.py
Traceback (most recent call last):
File "custom_projection_example.py", line 440, in <module>
subplot(111, projection="hammer")
File "/usr/local/lib/python2.6/dist-packages/matplotlib/pyplot.py",
line 645, in subplot
a = fig.add_subplot(*args, **kwargs)
File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
line 690, in add_subplot
a = subplot_class_factory(projection_class)(self, *args, **kwargs)
File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
7802, in __init__
self._axes_class.__init__(self, fig, self.figbox, **kwargs)
File "custom_projection_example.py", line 35, in __init__
Axes.__init__(self, *args, **kwargs)
File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
525, in __init__
self.set_figure(fig)
File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
597, in set_figure
self._set_lim_and_transforms()
File "custom_projection_example.py", line 94, in _set_lim_and_transforms
self.transProjection = self.HammerTransform(self.RESOLUTION)
TypeError: __init__() takes exactly 1 argument (2 given)Michael Droettboom wrote:
That's right, Eric. I think having resolution be an attribute of the artist (and not the projection) is the "path" of least resistance here. To clarify, however, the interpolation (more specifically, whether to interpolate) should remain a function of the projection, not the path. That's the important point that lead to it ending up in the wrong place in the first place. If we aim to keep the generalization that all grid lines are the same kind of object regardless of the projection, and therefore set a high resolution parameter on all the grid lines, we wouldn't want this to slow down the standard rectilinear axes. As long as the standard axes don't obey the parameter, then would should be fine. It's somewhat confusing, but I also am seeing this the resolution parameter on artists as more of an implementation detail than a public API. If someone wants to interpolate their data, IMHO that should be the user's responsibility, since they know the best way to do it. This functionality isn't really about data points, IMHO.
The more difficult change seems to be being backward compatible about the Polar plot accepting a resolution argument. I'm not even certain that it's worth keeping, since as you suggest, it makes more sense for it to be a property of the artist. I'd almost prefer to raise a warning if the user provides a resolution argument (other than 1) to Polar rather than trying to make it work. Is anyone actually using it, other than to set it to 1 on 0.98.x versions?
I should have some time to work on this today.
Mike
Eric Firing wrote:
Eric Firing wrote:
Jae-Joon Lee wrote:
The default resolution (which is used to interpolate a path in polar
coordinate) has change to 1 at some point. And because of this, a
radial grid becomes a 0-length line. Increasing the resolution will
bring back your gridlines.
This is not the right solution, though. There was a reason for the change in default resolution to 1--it gives the expected behavior for plotting a line between two points in polar coordinates--and it is not going back. The inability to set resolution on a per-artist basis is a serious problem that doesn't seem to have a simple solution. Until one can be found, some sort of special case handling will be needed for the radial grid lines.
Eric
Expanding on this: it looks like a possible solution is to attach a new "resolution" attribute to the Path object. This would ordinarily be None, but could be set to another value when the Path is created (or later). Then the PolarTransform.transform_path method (and the same in other curvilinear projections) could use that value, if not None, to control interpolation. Some additional changes would be needed to apply this to the radial gridlines.
Now it is not clear to me that resolution should be an attribute of the PolarAxes at all--the interpolation is done by a path method, so that method doesn't need a resolution parameter at all if resolution is a Path attribute. Except for backwards compatibility. Comments, Mike?
I can't implement it right now, but if no one comes up with a better solution, or wants to implement something like this one, then I can do it in a day or two.
(Of course, I may not be seeing a stumbling block.)
Eric
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA