MapPlot Zenith projection in AltAz coordinates

[HealthyPear]

Is it possible to support the Zenith projection of MapPlot also in azimuth and altitude/zenith coordinates instead of RA/Dec?

[steveberardi]

To confirm I understand your question, do you mean you'd like to use alt/az coordinates with plotting functions like circle()/marker()/etc in zenith-projection plots?

Currently, there is no built-in way to do this, since all the plotting functions (e.g. circle()) use RA/DEC only. You could use Skyfield to convert from RA/DEC to alt/az.

I do think it would be helpful to add some helper functions or something to starplot to help handle various coordinate systems. I'll think about how this could work and add it to the roadmap. If you have any ideas, suggestions are very welcome too! Thanks :)

Steve

[HealthyPear]

Exactly, I mean in general showing (and working with) MapPlot in AltAz instead then RA/Dec when using the Zenith projection: for me this would make more sense since this projection is already subjective to the position of the observer on Earth and it's basically what you would see with your eyes looking at the sky.

For converting now I am using a combination of astroplan and astropy because that is what I use normally in my line of work.

Maybe this is a bit too much for this issue alone, but just for context now I was looking into projecting onto MapPlot a polygon to show the profile of the mountain around the observatory I work on and my measurements are already all saved in AltAz and I wanted to compare the plot with some other person who instead plot in that reference coordinate frame, e.g. this is done with skyfield I believe using an alt/az system centered on zenith oriented with South at the bottom showing a zenith range and the culmination of the target source for each month.

I wanted to do it with starplot which seems cooler (and anyway is based on skyfield!) :)

(Maybe this is for another issue: I cannot manage to fill any polygon on the side of the horizon, it always fills the internal side of the plot).

[HealthyPear]

(Maybe this is for another issue: I cannot manage to fill any polygon on the side of the horizon, it always fills the internal side of the plot).

Ok I discovered that I need to pass the RA/Dec polygon points counterclockwise to properly fill a polygon at horizon. I don't think this is clear from the documentation, maybe better specify it.

[steveberardi]

Thanks for the extra info! I can see why alt/az makes more sense for your use case. I've been thinking more about how to handle different coordinate systems in Starplot, and thinking we could do it through some kind of coordinate base class that has multiple implementations (e.g. RaDec, AltAz, etc). And then modify all the plotting functions that deal with coordinates to support either a tuple of RA/DEC or an object that implements the coordinate base class.

I've got this on the roadmap now, but probably won't get around to building it until v0.12.0 or later. Trying to wrap up v0.11.0 in the next few weeks.

Thanks for raising that bug/issue around the polygons near the horizon. I've run into multiple issues with plotting polygons in matplotlib/cartopy and making sure they look good in all projections. I wasn't aware the coordinates needed to be in counterclockwise order, but that's a valuable discovery, thanks! I'll either add that info to the docs or find a way around it so coordinates in either direction work.

[steveberardi]

@HealthyPear ah, just thought of this... for the polygon filling issue, is your first coordinate of the polygon the same as the last coordinate? If it isn't, that may result in the wrong side getting filled.

[HealthyPear]

Sorry for the delay in the response...

is your first coordinate of the polygon the same as the last coordinate? If it isn't, that may result in the wrong side getting filled

I'll check and let you know if it works!

we could do it through some kind of coordinate base class that has multiple implementations (e.g. RaDec, AltAz, etc).

This is basically astropy.coordinates.SkyCoord, no need to reinvent the wheel (unless you have a good reason not to add this dependency, which can be used also to deal with units transformations and other things related to optical astronomy).

[steveberardi]

I realize I forgot to add some more info I found around this issue... but, basically you're right: that coordinates for polygons need to be in counterclockwise order (I added this to the docs, so hopefully that helps). I also found out that this dependence on order is by design, because it's a way to indicate if the polygon is internal to another polygon (i.e. a hole in the polygon).

Good idea about using astropy's SkyCoord class, I'll look into that and see if it'd be easy to integrate into Starplot. Generally, I like to avoid adding dependencies (and Starplot already has a lot), but this one may make a lot of sense. It may even already be an indirect dependency :)