How much can we generalize the 2D declarative plotting classes before it's an API break?

[jthielen]

As a part of my explorations into using the declarative interface, I'd like to figure out how to get cross sections and Hovmöller diagrams implemented. If all the 2D plotting classes (Plots2D, PlotScalar, PlotVector, ImagePlot, BarbPlot, ContourPlot, and FilledContourPlot) were generically 2D instead of horizontally 2D, I would think this would be as easy as adding new panel types. However, as it is, various assumptions that we are working on spatial horizontal coordinates are currently built in along the inheritance chain:

• Plots2D (assumes level and time are single values, if they are given)
  • PlotScalar (plotdata provides x and y coordinates as the two coordinates)
    • ImagePlot (plotdata again provides x and y coordinates as the two coordinates, and forces a cartopy transform in _build)
    • ContourPlot (forces a cartopy transform in _build)
    • FilledContourPlot (forces a cartopy transform in _build)
  • PlotVector (plotdata again provides x and y coordinates as the two coordinates, and assumes they are available for earth vs. grid relative velocities)
    • BarbPlot (forces a cartopy transform in _build based on earth_relative)

My main question is: can we safely relax these assumptions without breaking the API? Ideally, I'd like to do the following:

• Let level and time also be arrays in Plots2D for more generalized subsetting (EDIT: on later review, reconsidered the array suggestion, as that breaks traitlets. Better to just let them be None and count on the user to do any array subsetting pre-declarative interface)
• Add x, y, longitude, and latitude to Plots2D for subsetting by scalar or array (erroring out if the corresponding xarray coordinate is not a dimension coordinate)
• Have plotdata in PlotScalar, ImagePlot and PlotVector automatically determine the two dimensions rather than always using x and y (erroring out if the squeezed data is not 2D)
  • generalized ordering does become a concern here though...not sure best approach for that
• Have _build in ImagePlot, ContourPlot, FilledContourPlot, and BarbPlot conditionally use the transform kwarg
  • Only if the two dimensions are x and y?
  • Only if inside a MapPanel?

Beyond the API break considerations, what are the thoughts in general on this approach to enabling alternative 2D plots like cross sections (transect and vertical dimensions) and Hovmöller diagrams (latitude or longitude and time dimensions)?

[jthielen]

Also, if this seems like a good way forward, it might also be good to revisit the x/y vs. lat/lon coordinate details in the declarative internals along the way. For example, I'm a bit confused by this bit in PlotScalar.plotdata, which seems to trace back to the original declarative implementation by @dopplershift in #989:

if 'degree' in x.units:
    x, y, _ = self.griddata.metpy.cartopy_crs.transform_points(ccrs.PlateCarree(),
                                                               *np.meshgrid(x, y)).T
    x = x[:, 0]
    y = y[0, :]

This seems like it is only ever going to transform lat/lon coordinates back to lat/lon (with possible mangling of globe information if not default), unless I'm missing something (perhaps to do with pre-#1090 behavior)?

[kgoebber]

Yes, I think you are correct. That is what I found when working on the contour issue that came up through support and will be taken out in PR #1681.

[jthielen]

Yes, I think you are correct. That is what I found when working on the contour issue that came up through support and will be taken out in PR #1681.

Good to know!

[kgoebber]

The original vision for the declarative syntax was to produce maps, so that is partially how and why we got the structure. I think we could update the backend to be more inclusive and better able to support multiple 2D plots, but what about making Plot2D to be PlotMap2D, then create a non-map version Plotxy2D to capture Hovmoller, meteorograms, etc, and a PlotSkewT for a slightly simplified skewT plotting. It would be a bit extra to not have it fall all under one class, but could be more readable for folks to be able to contribute.

[jthielen]

The problem with this is that it is not just Plot2D, but all the descendant classes (PlotScalar, PlotVector, ImagePlot, BarbPlot, ContourPlot, and FilledContourPlot). It would get really annoying to have to have multiple families of these depending on the base plot type, hence why I thought making the plot classes more general would give the nicer interface.

Also, probably best for a separate discussion, but I would be inclined to make SkewT a panel, since SkewT is really a "special axes" just like a Cartopy map is, and you can have multiple plotting things on a SkewT?

[jthielen]

In case it is useful for discussion (at this afternoon's telecon?), here is a branch with an illustration of these generalizations: https://github.com/jthielen/MetPy/tree/generalize-2d-declarative. Haven't seen what tests break yet.

[kgoebber]

So I just tried all of the declarative tests and the only issue I had was with text moving around on plots - no real functionality break. I'll begin working from this to see what we can come up with.