Allow 1D plots to have the coordinate on the y-axis.

[ajdawson]

This PR adds an optional argument to the iris.plot.plot and iris.quickplot.plot functions that allows the coordinate to be presented on the y-axis of a 1D plot (see #581). This is necessary in order to make profile plots with iris, these types of plots are extremely common in meteorology and oceanography (temperature/salinity/velocity profiles in the ocean, temperature profiles in the atmosphere to name a few examples).

Implementation notes:

This change is implemented as a new boolean keyword argument. I am aware that this is not to many people's taste, but having explored other options I felt this was the best way to go for the following reasons:

• Guessing of vertical coordinates is quite difficult to do well. If we tried to automatically transpose the axes for plots of a cube with a vertical coordinate we are likely to miss some cases, and worse, misidentify others. I think this might end up disappointing the users.
• iris.quickplot needs to know how to draw the plot labels, so the information needs to be available at that level.
• Having a keyword argument to _draw_1d_from_points makes life easier for other modifications (e.g., y-axis inversion for vertical coords #522) since they can easily tell if the axes will be transposed.

I'd appreciate some feedback on this. If anyone has a better way of doing this that remains flexible I'd be happy to hear it.

[esc24]

I gave it a little though this morning. How about taking a lead from matplotlib's api? I'm thinking of pcolormesh where the x and y args are optional:

plt.pcolormesh(C)
plt.pcolormesh(X, Y, C)

How about if we did something similar where iplt.pcolormesh(cube) does what it does now, but we also allow
iplt.pcolormesh(X, Y, C) where X, Y and C can each be cubes or coords? The same could be done for 1d plots, where iplt.plot(y) does what it does now, but iplt.plot(x, y) support x and y being with cubes or coords. You can then do:

iris.plot.plot(cube, cube.coord('depth'))

or (what I need right now)

iris.plot.plot(cube.coord('time'), cube.coord('depth'))

We'd need to be careful to handle the 1d/2d coordinate cases. What do you think @ajdawson?

[ajdawson]

Is there much point doing this for iplt.pcolormesh? I thought the purpose of iris.plot was to simplify plotting cubes with their appropriate coordinates, and you can already control which coordinates are plotted in which order using the coords keyword. I can't think of a realistic example of using this.

For 1D plots this could work perhaps. However as I said previously my interpretation of the iris.plot module is that it is a simple wrapper for plotting a cubes, in the case of iris.plot.plot it is a simple wrapper for plotting a cube's data values against its respective dimension coordinate, so I'm not sure this is necessarily a good idea either. In my mind it adds a lot of complication and a whole host of possibilities that make life harder.

[rhattersley]

How about if we did something similar where iplt.pcolormesh(cube) does what it does now, but we also allow
iplt.pcolormesh(X, Y, C) where X, Y and C can each be cubes or coords? The same could be done for 1d plots, where iplt.plot(y) does what it does now, but iplt.plot(x, y) support x and y being with cubes or coords.

👍 I think this would even work for 2D coords in either order.

[esc24]

@ajdawson - I don't want to hijack your PR, but I wanted to propose an alternative. I'm not wedded to doing it for 2d plots, that's just where the thought originated. However, I do need to be able to do this:

iris.quickplot.plot(cube.coord('time'), cube.coord('depth'))

At the moment I can dig out the name/symbol/units and label the axes appropriately and pull out the points arrays and call plt.plot(), but this is messy and error prone. Allowing coords and cubes to be passed in like this addresses your need and mine and in my opinion mirrors matplotlib api more that your transpose keyword arg.

[ajdawson]

Can you just explain to me what the time and depth coordinates are.

[esc24]

Can you just explain to me what the time and depth coordinates are.

Yes. I have the trajectory of a balloon loaded from a file resulting in a time series. The cube contains a collection of 1d coords and a phenomenon of temperature:

Temperature / (unknown)             (*ANONYMOUS*: 836)
     Auxiliary coordinates:
          Travel Time                           x
          height                                x
          latitude                              x
          longitude                             x
          time                                  x
     Scalar coordinates:
          PP Index: 1.0
          Puff?: N
          Release Time: 2011-10-31 06:00:00
          Source: Trajectory1

I'm generating this plot:

The plot of temperature is easy, as it's the phenomenon, so I just specify 'time' as the coords keyword arg. However, plotting height against time has to be done manually by pulling out the points and the metadata, e.g. I have to convert the time values into datetime objects using the coordinate's units. Similarly for the plot of longitude vs latitude I need to take care over the coordinate system as well.

PS. I'd consider deprecating the coords keyword if we did this.

[ajdawson]

Thanks for the examples. The requirements for this functionality are certainly a lot more advanced than I had envisioned. I doubt I'll have time to do this though, so if this route is the popular one I'll close this PR and let some one else start a new one on this?

[rhattersley]

If we tried to automatically transpose the axes for plots of a cube with a vertical coordinate we are likely to miss some cases, and worse, misidentify others.

Can anyone suggest examples of where using guess_coord_axis == 'Z' would make an auto-transpose do the wrong thing?

[ajdawson]

It won't do the wrong thing currently, but it will miss out loads of vertical coordinates (anything not convertible to hPa or having a positive attribute). I was concerned that expanding this may lead to false positives. Unless you can be sure you are going to identify most (all ideally) vertical coordinates correctly I think this is a little risky.

[rhattersley]

At the moment I still like @esc24's idea. But it'd be good if we can keep as much benefit from this PR as possible. In that context, if the new "transpose" keyword was replaced with an is-vertical test this PR would make a nice stepping-stone.

It won't do the wrong thing currently, but it will miss out loads of vertical coordinates

I've just refreshed my memory of the CF definition of vertical coordinates and you're right. There a gaping great whole in the CF spec where it talks about "providing the standard_name attribute with an appropriate value" ... and yet I'm not aware of any list of "appropriate" standard names. I think this needs addressing on the CF mailing list and/or trac system.

Unless you can be sure you are going to identify most (all ideally) vertical coordinates correctly I think this is a little risky.

It would be risky if this was all we were going to do, but if we went on to implement @esc24's suggestion (or similar) then I think that risk goes away. (Also, any improvement on the "appropriate" standard names issue would help minimise the number of cases where the is-vertical test does the wrong thing.)

[ajdawson]

It would be risky if this was all we were going to do, but if we went on to implement @esc24's suggestion (or similar) then I think that risk goes away

I agree, I was referring to handling this automatically rather than the other suggestions.

[pelson]

Quick brain-dump:

There was a conversation a while ago to allow users to pick the dimension of the data to plot (I think the syntax was something like coords=('dim1', 'time')) I don't necessarily like the proposal, but I do think the functionality would be useful. An extension to this capability that I have thought of a couple of times would be to allow users to specify "data" in some way as one of the plot axis. Using this same clunky syntax that might look like coords=('data', 'time').
Having such a capability would allow one to define the coordinate order of the plot without the need for the boolean keyword argument.

[rhattersley]

Having such a capability would allow one to define the coordinate order of the plot without the need for the boolean keyword argument.

@esc24 and I touched on the data-token idea when we were discussing his proposal. But as things stand I'd rather we take the route he proposed on this PR.

[ajdawson]

I doubt I'll have time to do this though, so if this route is the popular one I'll close this PR and let some one else start a new one on this?

I've changed my mind! I've knocked up a quick prototype of this idea for iris.plot.plot and it seems to work sensibly. I'll continue to work on it and see if I can submit a new PR when it is in reasonable shape. I think I'll close this one so it won't clog up the PR list.

[ajdawson]

Does anyone have any thoughts on the following:

The new plot function will accept one or two arguments. In the case of the quickplot version, what should the title of the plot be when two input arguments are used and they are:

1. both cubes
2. both coordinates

[ajdawson]

@esc24 is that balloon file able to be used for test data? If not I'll construct something similar.

[ajdawson]

@esc24 is that balloon file able to be used for test data? If not I'll construct something similar.

Nevermind, it looks like the newly added NAME trajectory data.

[esc24]

Nevermind, it looks like the newly added NAME trajectory data.

Well spotted,