Conversation
|
Integration requires more effort see #606 -- don't have time to work on this atm. |
Route Astropy WCS projections through a native AstroAxes bridge instead of the external container, preserve per-axes transform dispatch for SubplotGrid, and keep shared panel labels stable for both cartesian and astro axes.
Move logical ticklabel state access into the axes classes so Figure can share and hand off panel labels without branching on cartesian, geo, and astro subplot types.
Make the Astropy WCS bridge a true optional import by loading and registering AstroAxes only on WCS-specific access, while keeping the panel/share refactors and import behavior covered by tests.
Make Astropy a true opt-in runtime extra by adding dedicated package extras for Astro, geographic, and ternary integrations, along with an all extra that installs the optional runtime stack without changing the default UltraPlot dependency set. At the same time, tighten the Astro axes import path so explicit WCS usage fails with a clear installation message instead of silently returning None. astro.py is now treated as an Astropy-backed module again, the lazy loader in axes.__init__ raises a targeted ImportError with the recommended install command, and WCS string resolution in projections.py now relies on that explicit failure path. This also expands inline documentation in AstroAxes to make the WCS override points clearer, and updates the import tests to match the new optional-dependency behavior.
Add a dedicated Astropy WCS section to docs/usage.rst so the new AstroAxes integration is discoverable from the main usage guide. The section explains the optional install path, shows the two supported creation patterns (direct WCS objects and the "wcs" alias), and clarifies that UltraPlot handles figure-level sharing/layout while advanced coordinate customization still lives on ax.coords[...].
d1e11e0 to
ba2ecaf
Compare
ba2ecaf to
d9e8cca
Compare
Revert the non-sharing left and bottom panel relabeling that shifted shared subplot labels and broke existing image baselines. Also harden the Astro lazy-import test so missing astropy does not crash the subprocess before the optional import path is exercised.
|
@astrogewgaw can you test this? |
|
@cvanelteren I tested this using the minimal working example I shared earlier (the code for which has been added to the issue now as a comment here; do have a look), and it works! I will see if I can test it with some FITS images as well. Also, maybe @beckermr can also have a look at this if he has some time? Just a thought. |
|
Need to do some more testing and quality check the implementation; Astropy seems like a serious undertaking. We should also reach out to add us on the list of packages if this goes through. |
|
Key thing is that supporting other axis implementations is that it will become harder for me to keep up if the backend changes on their end; if we keep this in house and it changes significantly this would require me to keep up-to-date with their changes. Since I am not an astro-person, this would be harder to catch than users that use it every day. Naturally, I can write tests but this will not be perfect. |
|
@cvanelteren Makes sense. I can help with some of the testing, but I don't deal with that many astronomical images in my line of work, I am more of a time-domain astronomy guy. Do let me know if and when this makes to a future release of UltraPlot; until then, I can point my package to the latest commit on the |
Closes #606
Issue #606 is that UltraPlot does not correctly handle Astropy WCS projection objects passed as
projection=mosaic.wcs.In practice, this shows up when code like
ax.get_transform("icrs")fails with:The underlying problem is:
masked by the base Matplotlib artist API.