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.
Mike, Thanks for taking care of this so quickly. Although I agree that _interpolation_steps is a low-level, implementation-dependent attribute (which might not be the right specification if interpolation were changed to take advantage of Bezier curves, for example), I think that some sort of "follow_curvilinear_coordinates" public Artist attribute would be desirable. For example, one might want to plot a set of arcs, or arc-shaped patches (warped rectangles) on a polar plot. It would be nice to be able to do this using lines, line collections, rectangle patches, or rectangle collections, by adding a single kwarg to set that attribute. Then it would be up to each Artist to use that attribute to set _interpolation_steps or whatever implementation mechanism is in place. Possibly it does not make sense as a general Artist attribute but should be restricted to a subset, but it is probably simpler to put it at the Artist level and then selectively apply it. Eric > > 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 > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
