Non string projection definitions in matplotlib #470
Conversation
| # initialise the axes_class | ||
| self._init_axes(fig, **kwargs) | ||
|
|
||
| def _init_axes(self, fig, **kwargs): |
There was a problem hiding this comment.
It is not quite obvious to me what is the benefit of this. Can you show some cases where this is useful?
I think Subplot must be a thin wrapper around Axes, and it should not change anything other that those related with position of axes. In other words, I think subplot_class_factory must be sufficient to create every subplot classes.
|
I think it is a good idea in general. However, I'm not sure if the current interface is optimal. It seems that the interface need two method, axes_isinstance and subplot. Correct me if I'm wrong (also, can you provide some actual implementation of the projection object?) First of all, projection should supported by the Figure.add_axes method. So, you may need "axes" method for the interface. However, I think what would be sufficient is a single method that returns the underlying Axes class and additional keyword parameters that needs to be passed to the Axes class for instantiation, i.e., no need for axes_isinstance, subplot etc. For example, class Hammer(object):
def __init__(self, central_meridian=0):
self._centeral_meridian = central_meridian
def __call__(self):
return HammerAxes, dict(central_meridian=self._centeral_meridian)And I believe that Figure.add_subplot method can be modified only to use this interface. |
|
Thanks for your feedback. Your right that your approach makes things easier (and requires a smaller change). I have made the changes in https://github.com/PhilipElson/matplotlib/compare/master...class_projections . You will notice that I went for calling the method I would really appreciate feedback on the changes linked above before I submit a fresh pull request. Thanks, |
|
As I said before, I believe the same mechanism should be implemented in add_axes method. Also, in the current implementation, any object with a "_as_mpl_axes" method is acceptable. But if you think about the documentation, I don't think it is the best option. " projection can be any object with _as_mpl_axes method which returns ...." I think it is better if we can simply say " *projection" can be any callable object witch returns ..." Or, you may define a base class and accept instances of this base class. Anyhow, It would be much better if the pull request should include proper documentation. Also, I think that it should include a real (although simple) implementation of projection class. I recommend you to include a stripped-out version of your projections.polar.Polar class in your "polar_fun" branch, i.e., a simple Polar class that is simply identical to "polar". No theta0, No clockwise. The other part may be submitted as a separate pull request. |
|
Since this branch was pre 1.1.0 I have created another pull request: #694 which should make life easier to merge when we get to that stage. Thanks, |
As per the devel mailing list:
I would like the ability to setup a plot projection in MPL that can be defined by various parameters and does not need to be serialised as a string and registered with matplotlib.projections.register_projection. For example, an extension of /examples/api/custom_projection_example.py might be to add the ability to define the central meridian to an arbitrary value rather than the current value of 0 - in this case I would expect to define the projection by creating an object which can then be turned into a matplotlib axes:
I have made a change to matplotlib which would enable this capability. Any feedback and thoughts would be really appreciated with the ultimate goal of getting this functionality into MPL.