Enhance the `OBTYPE` header column for `MPR` and `ORANK` line types

[JohnHalleyGotway]

Describe the Enhancement

This issue arose via dtcenter/METplus#2476 discussion from @robdarvell.

The OBTYPE stat header column is populated based on the message type specified in the Point-Stat and Ensemble-Stat configuration files. The same OBTYPE string is written for all STAT output line types generated by each verification task, including the matched pair (MPR) and observation rank (ORANK) line types.

However, the message_type_group_map configuration option enables multiple input message types to be grouped together into the same verification task. In Rob's example he's grouping both AUTO and MANU message types together into a group named SURF. Rather than setting OBTYPE to SURF in output MPR lines, he'd prefer to write the input obtype name instead.

This task is to enhance the Point-Stat and Ensemble-Stat tools where the message_type_group_map is involved in the setting of the OBTYPE output column. Provide the option of writing OBTYPE for the MPR and ORANK lines using the original input message type rather than the mapped name of the group.

Recommend adding this logic through a configurable option rather than making a wholesale change:
obtype_as_group_val_flag = FALSE
Where FALSE (default) maintains the current behavior of writing SURF, and TRUE would write the original observation message types of AUTO of MANU instead.

This would support the MetOffice usage without changing the output for others.

Time Estimate

2 days?

Sub-Issues

Consider breaking the enhancement down into sub-issues.
None needed.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

2799991

Define the Metadata

Assignee

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

Labels

• Review default alert labels
• Select component(s)
• Select priority
• Select requestor(s)

Milestone and Projects

• Select Milestone as the next official version or Backlog of Development Ideas
• For the next official version, select the MET-X.Y.Z Development project

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy
• Need a METplus issue to make any new config options settable.

Enhancement 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 Development issue
  Select: Milestone as the next official version
  Select: MET-X.Y.Z Development project for development toward the next official release
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[robdarvell]

Just an additional bit of context regarding this change. It could be asked as to why couldn't you have 2 GROUP_MAP keys, one just containing AUTO and one just MANU and then run your job from that.
That was one option which was looked at. There was one issue with that approach. It was noted that as we use a time window for which observations to use, there were occasional times where within the window, there were 2 obs for a location, one which came from AUTO and the other from MANU. We only want one of these to be stored (the one nearest), and with the 2 group approach you would get the nearest for MANU and also the nearest for AUTO (which is not the desired outcome).