Describe the New Feature

The MET Grid-Stat tool supports a configuration option named grid_weight_flag to define weights for computing statistics aggregated over multiple grid points. The grid weighting is based on the area each grid point represents, giving larger weight to grid boxes with larger areas.

This task is to develop a method for weighting the aggregation of point observations. And the same basic motivation applies, wanting to avoid overemphasizing areas with dense observations, and underemphasizing areas with sparse observations.

Consider also whether point_weight_flag should be added to Stat-Analysis jobs when aggregating MPR lines to compute partial sums, contingency tables, and statistics.

This request originally arose when aggregating SEEPS for individual stations into a spatial summary. The UK Met Office defines weights for that aggregation based on the spatial density of those stations. However, those weights are pre-defined and static since the stations they use are consistent run-to-run.

Recommend that when implementing this in MET, the weights NOT be static, in general. Instead, dynamically compute them for each verification task based on the location of the observations being processed.. The number and location of point observations can change dramatically run-to-run based on the masking region, variable, and data source. That being said, re-defining them in each run would likely be slower. Recommend that when specifying a mask.sid list of station id's we provide an option to define a fixed station weight.

The tasks for this issue include:

• Collaborating with @RachelNorth and @mpm-meto to clarify the algorithm for defining these weights.
• Add point_weight_flag configuration option for each verification task in Point-Stat and Ensemble-Stat with a default value of NONE, meaning apply a weight of 1 to all points.
• Support setting point_weight_flag equal to DENSITY to define the weights on the fly based on station location.
• When mask.sid is set to a file and station names are read from that file, add an option for a raw weight to be specified for that station (perhaps SID(weight) with a numeric weight?). When aggregating across multiple stations, note that the true weight should be computed as the raw station weight divided by the sum of the weights of all points.
• Set the existing weights in the PairDataPoint and PairDataEnsemble classes and ensure that those weights are used correctly in the computation of statistics.
• In particular, ensure that the these weights are used in the aggregation of SEEPS_MPR data to compute the aggregated SEEPS data.

Acceptance Testing

List input data types and sources.
Describe tests required for new functionality.

Time Estimate

1 week.

Sub-Issues

Consider breaking the new feature down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Split between MetOffice and NOAA R2O keys.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy
• Need a METplus issue to handle configuring the new point_weight_flag option.
• If changes to any output line types are made, would need a METdataio issue to handle those changes.

New Feature Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.