Skip to content
This repository was archived by the owner on May 26, 2022. It is now read-only.

Adding plot API for discussion#3

Closed
adrn wants to merge 3 commits into
astropy:masterfrom
adrn:plotting
Closed

Adding plot API for discussion#3
adrn wants to merge 3 commits into
astropy:masterfrom
adrn:plotting

Conversation

@adrn

@adrn adrn commented Oct 10, 2012

Copy link
Copy Markdown
Member

(Sorry, ignore two corrective commits...)

The idea is to discuss how to handle plotting within the AstroPy package. This means:

  • How to enforce consistent plotting API's amongst objects
  • What does the interface look like?

Discussion point: What name do we choose? plot(), show(), display()?

Conclusion: I think plot() is the most natural and is probably what most people with expect, but we will ask for community feedback.

Discussion point: Do we make it matplotlib agnostic and enable other backends?

Conclusion: For now, we write the code so that the access to the API is generic but defaults to using matplotlib. In the future, if someone wants to implement a way to register other plotting backends or packages, our API won't have to change.

Discussion point: What do we do with NDData objects? Should they have a plot() method?

Conclusion: An argument for the plot() method is that it encourages subclasses to implement this method. An argument against the method is that it is really hard to make something generic enough to be useful in many cases. The decision for NDData is to only plot when the number of dimensions <= 2. For more than 2 dimensions, the user is expected to either sum over the other dimensions or slice it however they want to get the object down to 2 dimensions. Then they can use the .plot() method to view the data.

Discussion point: How do we incorporate other keyword arguments for customizing the plot?

No conclusion: One solution is to not accept any kwargs, and to force the user to use the object-oriented "Axis" object that is returned to retroactively change parameters. The other option is to accept any other keyword arguments, but the problem here is, taking matplotlib as an example, plotting one-dimensional data will use the matplotlib plot() function whereas plotting two-dimensional data will use imshow(), but the user never sees this distinction. I don't think we came to a conclusion, but I implemented one just so we have something to discuss.

@eteq eteq mentioned this pull request Oct 12, 2012
Comment thread plot_api.py

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something I have thought about a bit (see astrofrog#1 - but no need to comment there at this stage!). You could have

high_d_data.plot(slice=[1, 'x', 4', 'y'])

which means pick the second slice in pixel space in the first dimension, plot the second dimension on the x axis, slice 5 from the third dimension, and the fourth dimension on the y axis. This is all necessary because the WCS could depend on the position of the slices for any of the coordinates not directly shown.

@astrofrog

Copy link
Copy Markdown
Member

One way to deal with the keyword arguments if we don't want to confuse users if plot actually calls imshow is to not use **kwargs, but instead have

two_d_data.plot(imshow_kwargs={...})

it's a bit more clunky, but it does deal with cases where plot will call multiple plotting commands - for example if both imshow and plot are shown. I can't think of specific examples, but we want to be future-proof.

Note: this is clunky, but remember that in most cases, this is for quick viewing, and the user should just have to call plot().

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants