@ImportanceOfBeingErnest Regarding your comment I'm trying to fix some things in mpl_toolkit.

I have found the source of this issue here, at least why the tickmarks etc are gone. The twin()-method makes the "top" and "right" axes invisible. This is actually the same behaviour as in twinx().

What needs decision is the wanted default behaviour. Should all possible axes be displayed by default? Sure the added image is not how we want to have it (all possible axes visible).

@Sup3rGeo Any ideas how this should look like?

So, questions are, where to put the different axes and which should be made invisible. This decision also affects the remove method.

@smheidrich Sorry for disturbing, I'm trying to understand which axes need to be visible and which not. And for sure, the most logical solution. Looking at the commented code fragments before your changes in d268abf there has been quite some testing to probably find a nice solution. Do you remember why you've prefered this solution?

@kmuehlbauer The point behind my changes is summarized in the difference between the two images in this comment (which was also put into the tests as mpl_toolkits.tests.test_axes_grid1.test_twin_axes_empty_and_removed): previously, there was an (in my opinion, anyway) inconsistency between twinx/twiny and just twin, as seen in rows 3-5 of the first picture. My changes were only meant to make it consistent, but if this was a poor choice which messes up some other use cases then it should be either reverted altogether or made consistent in a different way.

By the way, there was another issue stemming from my changes that never got fixed, summarized here - but I guess that is a slightly different issue and this here relates to just twin and not set_visible? Regardless, that was another case where my changes didn't mesh well together with other parts of mpl_toolkits, because I really only tested the most simple case... very sorry about that. At this point it feels like it makes more sense to just revert my commit altogether (and then revert back associated example code, e.g. #5757 and #6836).

I have to say I don't know what the expected outcome of the code here should be. I think the images in the comment in #4898 by @smheidrich are pretty convincing. So in this case I would think that due to the use of the twin method all axes visible is indeed expected? I suppose one can still set them invisible manually in case they are undesired? (If in doubt, I'd say removing something that is present is often easier than getting something to show that isn't.)
But my understanding of the axisartist module is pretty limited. That's why it is helpful if people who actually use this module work on fixing it. One main problem is the documentation in my eyes, since it currently does not allow to easily grasp the concepts.

@smheidrich Thanks for coming back to this, and for the pointers.

I'll have another look into this the next days adding some of my use cases here.

@ImportanceOfBeingErnest I adapted my use case from a matplotlib example. I'm not sure, if I used the API correctly but we will find out.

Thanks for responding, all.

It would still be consistent if twin* were changed to behave like twinx/twiny did prior to d268abf, i.e. if it added just the ticks and ticklabels, while keeping the axis line of the host. That would solve this issue, wouldn't it? Row 3 of the mentioned test comparison image would have to be updated, of course.

Are the plots which are generated for the gallery and docs part of CI by now, with image comparison tests? That would come in handy when changing anything in mpl_toolkits.

Are the plots which are generated for the gallery and docs part of CI by now, with image comparison tests?

The documentation is tested in the sense that it generates successfully. If an example from the gallery was to error out, the test would fail. However there is no image comparisson. If an example simply produces some wrong image this is not caught. Of course one could simply copy the code from any example and create a test from it. In general, the number of image comparissons should not grow too large, and sometimes it would be enough to test for certain things like visibility or positions. Possibly, several examples can also be combined into a single image comparisson.

I see, thanks!

This is a stripped down version of my use case:

import matplotlib.pyplot as pl
import numpy as np

from matplotlib.projections import PolarAxes
from matplotlib.transforms import Affine2D
from mpl_toolkits.axisartist import (SubplotHost, GridHelperCurveLinear)
from mpl_toolkits.axisartist.grid_finder import FixedLocator, DictFormatter
import mpl_toolkits.axisartist.angle_helper as ah

# Transformation for polar data
# Set theta start to north
tr_rotate = Affine2D().translate(-90, 0)
# set theta running clockwise
tr_scale = Affine2D().scale(-np.pi / 180, 1)
# create transformation
tr = tr_rotate + tr_scale + PolarAxes.PolarTransform()

# build up curvelinear grid
extreme_finder = ah.ExtremeFinderCycle(20, 20,
                                       lon_cycle=360,
                                       lat_cycle=None,
                                       lon_minmax=(360, 0),
                                       lat_minmax=(0, np.inf),
                                       )

# locator and formatter for angle annotation
locs = [i for i in np.arange(0., 359., 10.)]
grid_locator1 = FixedLocator(locs)
tick_formatter1 = DictFormatter(dict([(i, r"${0:.0f}^\circ$".format(i))
                                      for i in locs]))

# grid_helper for curvelinear grid
grid_helper = GridHelperCurveLinear(tr,
                                    extreme_finder=extreme_finder,
                                    grid_locator1=grid_locator1,
                                    grid_locator2=None,
                                    tick_formatter1=tick_formatter1,
                                    tick_formatter2=None,
                                    )
# try to set nice locations for range gridlines
grid_helper.grid_finder.grid_locator2._nbins = 15.0
grid_helper.grid_finder.grid_locator2._steps = [0, 1, 1.5, 2,
                                                2.5,
                                                5,
                                                10]

fig = pl.figure(figsize=(6,5))

# generate curvelinear grid axis
cgax = SubplotHost(fig, 111, grid_helper=grid_helper)
fig.add_axes(cgax)

cgax.set_aspect('equal', adjustable='box')

# get twin axis for cartesian grid
caax = cgax.twin()

# make everything look right
# cgax.axis["top", "right"].set_visible(True)
# cgax.axis["top", "right"].major_ticklabels.set_visible(True)
# cgax.axis["left", "bottom"].major_ticks.set_visible(False)
# cgax.axis["left", "bottom"].major_ticklabels.set_visible(False)
# caax.axis["left", "bottom"].set_visible(True)
# caax.axis["left", "bottom"].major_ticklabels.set_visible(True)
# caax.axis["top", "right"].set_visible(False)

# show curvelinear and cartesian grids
cgax.grid(True)
caax.grid(True)

t = pl.title('Simple Curvelinear Grid')
t.set_y(1.05)

pl.show()

Retested with d5a4eda, updated code

Status Quo, created with d5a4eda

Wanted, created with d5a4eda

Just remove the comments below the line containing # make everything look right to get the wanted output.

The current behaviour makes top and right of cgax invisible, remaining left and bottom. But cgax.twin() is adding to left and bottom too, which leads to this overplotting. To make everything look nice, I had to make top and right of cgax visible again as well as the ticklabels. Also had to make left and bottom of caax visible and top and right invisible.

This is all true for the current configuration (xlim/ylim: 0,1). But think of (xlim/ylim: -1,0), Then the different axes need to be on the opposite of each other (at least the axes with the angles, see image below, created with d5a4eda) .

So, currently I'm a bit at loss, if there is single fitting solution at all.

Should it be that easy now? OK, in twin()-method the following is done:

self.axis["top", "right"].set_visible(False)
ax2.axis["top", "right"].set_visible(True)
ax2.axis["left", "bottom"].set_visible(False)

So the top and right of the twin-axes are set visible. But this does not activate the ticks etc.
So if I take my example from above and just do:

# make everything look right
caax.axis["top", "right"].toggle(all=True)

then I get an image with all wanted axes (see below, created with d5a4eda). We see that the placement of the bottom axes is not good. But we can't do much about it. Now the user has to switch axes to his liking.

In the light of these examples, it seems that the only problem with the current code is, that the ticks etc are not visible. My question is: Is this intended behaviour?

@smheidrich @ImportanceOfBeingErnest Can someone please sanity check?

The problem of the original poster @Sup3rGeo is that his angular (?) axis spans over three axes (top, left, bottom). left and bottom of the original axis remain untouched, but top and right are made unvisible within twin().

To solve this just one line has to be added restoring the original top axis. (tested with d5a4eda)

ax.axis["top"].set_visible(True)

I am actually quite beginner with matplotlib and it has been a while since I opened this one, so I am not totally sharp.

But I think I agree with @ImportanceOfBeingErnest:

So in this case I would think that due to the use of the twin method all axes visible is indeed expected? I suppose one can still set them invisible manually in case they are undesired? (If in doubt, I'd say removing something that is present is often easier than getting something to show that isn't.)
(...) One main problem is the documentation in my eyes, since it currently does not allow to easily grasp the concepts.

In general I would not expect anything on the host axis to be hidden when adding a twin, it was a bit confusing. Then when adjusting the axis, if there is no one-size-fits-all, the possibilities should be at least well documented.

@Sup3rGeo Thanks for responding. I would also agree, that it's a bit confusing if parts of the original host axis are silently hidden. I searched the current examples/demos but couldn't find anything related to this specific behaviour. Why not add nice example showing how to handle this specific use case?

Also the twin()-function docstring needs an update, it is the same as twinx() currently.

Other opinions?

Just so I understand: Does the issue of "angle" ticklabels being drawn on top of each other in the bottom left corner of #10748 (comment) have anything to do with this twin issue? At least in my testing, this happens even if I remove the twin call altogether, but I don't really get what's going on there anyway.

If it is a separate issue, the only issue here is that nothing on the host axes should be hidden when using any of the twin* methods, right? I think I'd agree that this would be better default behavior. It would also simplify the _remove_methods to just calls of self.parasites.remove(h).

As I wrote in #10748 (comment), this basically means changing twin* to behave like twinx/twiny did before d268abf, i.e. you'd call ax["right"].line.set_visible(False) in twinx to hide the parasite axis lines instead of the ones of the host, and analogously for twiny and twin. In contrast to pre- d268abf behavior, it would still be consistent between all the twin* methods.

I also agree that the twin docstring should definitely be fixed - that seems like a fairly uncontroversial change :)

Just so I understand: Does the issue of "angle" ticklabels being drawn on top of each other in the bottom left corner of #10748 (comment) have anything to do with this twin issue? At least in my testing, this happens even if I remove the twin call altogether, but I don't really get what's going on there anyway.

@smheidrich Correct, this particular problem has nothing to do with this issue, hence I wrote "But we can't do much about it."

If it is a separate issue, the only issue here is that nothing on the host axes should be hidden when using any of the twin* methods, right? I think I'd agree that this would be better default behavior. It would also simplify the _remove_methods to just calls of self.parasites.remove(h).

This sounds reasonable to me. It does not hide anything on the host axes and simplifies code.

I also agree that the twin docstring should definitely be fixed - that seems like a fairly uncontroversial change :)

For sure! 😁

All right then, should I submit a PR or is anyone else already working on it? Or is there something else to discuss first?

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!