Replies: 3 comments 4 replies
-
|
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 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)? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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, andFilledContourPlot) 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(assumeslevelandtimeare single values, if they are given)PlotScalar(plotdataprovides x and y coordinates as the two coordinates)ImagePlot(plotdataagain 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(plotdataagain 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_buildbased onearth_relative)My main question is: can we safely relax these assumptions without breaking the API? Ideally, I'd like to do the following:
Let(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)levelandtimealso be arrays inPlots2Dfor more generalized subsettingx,y,longitude, andlatitudetoPlots2Dfor subsetting by scalaror array(erroring out if the corresponding xarray coordinate is not a dimension coordinate)plotdatainPlotScalar,ImagePlotandPlotVectorautomatically determine the two dimensions rather than always using x and y (erroring out if the squeezed data is not 2D)_buildinImagePlot,ContourPlot,FilledContourPlot, andBarbPlotconditionally use thetransformkwargMapPanel?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)?
Beta Was this translation helpful? Give feedback.
All reactions