How to safely define a selection of dimensions to average across?

[agstephens]

The average function will allow averaging across multiple dimensions. But what do we call them?

Here is a suggestion to be discussed:

• time - should match our standard parameter name for submitting over time
• level - should match our standard parameter name for submitting over level
• latitude - allowed (but might not always exist)
• longitude - allowed (but might not always exist)
• y - if y-axis is not really latitude
• x - if x-axis is not really longitude

Main issue: the user doesn't know what the options are - so we need to map them.

[agstephens]

@huard : I would be interested to hear your thoughts on this issue. Do you have some similar code where you have made these decisions? Thanks

[huard]

Time and level are not ambiguous, but I'm not sure about the use case you have in mind for averaging over lat and lon individually. Do mean zonal and meridional means ? Apart from theses, I don't see cases where lat/lon means would be done individually. Most use cases would refer to a spatial mean (bbox or polygon). In fact, zonal/meridional means are special bases of bbox subsetting. And bboxes are always defined as lat/lon, so users should never really have to worry about native x/y coordinates.

[agstephens]

@huard: Thanks for your comments on the dimension averaging issue.

I agree that there won't be many use cases for averaging across X and Y dimensions that are not latitude and longitude. I suspect that we will need to adapt our original plan. I had naively thought that we would only have to consider grids as part of the regridding process. However, they come into play in some cases of averaging and subsetting as well. We need a holistic solution.

@cehbrecht and @sol1105 - note the above comments in terms of the regridding workflows.

[agstephens]

Dealt with elsewhere.