Dollar sign in WCSAxes ticks

[svank]

Description

I was exploring projections and ran into a case where WCSAxes shows a stray $ in a tick label. Whether this happens seems to be very sensitive to the value of lonpole I assign.

Expected behavior

This is a challenging frame for making RA ticks, so I can forgive the overlapping labels, but the stray $ probably shouldn't be there.

How to Reproduce

import matplotlib.pyplot as plt
import numpy as np
from astropy.wcs import WCS

map_scale = .4
shape = [int(90/map_scale), int(360/map_scale)]
starfield_wcs = WCS(naxis=2)
starfield_wcs.wcs.crpix = [shape[1]/2 + .5, shape[0]/2 + .5]
starfield_wcs.wcs.crval = 270, -30
starfield_wcs.wcs.cdelt = map_scale, map_scale
starfield_wcs.wcs.ctype = 'RA---CAR', 'DEC--CAR'
starfield_wcs.wcs.lonpole = 235
starfield_wcs.array_shape = shape

plt.subplot(111, projection=starfield_wcs)
plt.imshow(np.zeros(shape))
plt.grid()
plt.show()

Versions

platform
--------
platform.platform() = 'Linux-6.5.0-45-generic-x86_64-with-glibc2.35'
platform.version() = '#45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 15 16:40:02 UTC 2'
platform.python_version() = '3.12.7'

packages
--------
astropy              7.1.dev176+gb282736f25
numpy                1.26.4
scipy                1.14.1
matplotlib           3.9.2
pandas               2.2.3
pyerfa               2.0.1.4

[pllim]

😹

[pllim]

But more seriously, looks like the dollar sign was already there in astropy 6.1.7 though the axes did seem to display better than 7.0.0.

astropy 6.1.7

astropy 7.0.0

[pllim]

I am unfamiliar with this subpackage but combing the 7.0.0 change log, possible suspects for different axes behaviors:

• 17243

• 16366

Though I suspect the $ bug has been there for a long time.

[neutrinoceros]

A bisection indeed points to 16cb24251a459f1e0ff28085e63e90b3224878fd (#17243) as the first commit where this $ appears

[pllim]

Hmm but I see $ prior to that too. See https://github.com/astropy/astropy/issues/17451#issuecomment-2499153340

[neutrinoceros]

whoops, I wasn't looking in the right spot. This means my bisection is actually completely off. Let me try to go further back...

[neutrinoceros]

indeed, 6.0.0 already has the rogue $ and this is a far as I can easily go back, so a bisection isn't the right tool to find the source of error here, I think.

[pllim]

Thanks for trying!