[META]: Support for unexpected/non-pristine wrfout datasets

[jthielen]

What is your issue?

As encountered in #36 and xarray-contrib/xwrf-data#34 (and perhaps elsewhere), there may be several unexpected factors (old versions, tweaked registries, subsetting, etc.) that could result in xWRF's standard functionality being unsupported or failing. While it is definitely something not to prioritize for immediate releases, it would still be nice to make as many subsets of xWRF functionality available to users whose WRF datasets "break" xWRF's norms as possible. So, I propose this to be a meta-issue to

• track such unexpected/non-pristine examples
• work towards features to enable extended compatibility and/or custom application of atomized functionality outside of the standard postprocess()
• discuss any high-level design strategies to improve the experience of xWRF in these situations

Running list of sub-issues

(feel free to add/modify)

• Missing latitude/longitude coordinates (xref #36)
  • Could be addressed by (one or both of)
    • Convenience methods to merge in coordinates from geo_em files
    • Recompute lat/lon from projection coordinates
• Dataset grid definition attributes partially invalid due to spatial subsetting prior to postprocessing (xref xarray-contrib/xwrf-data#34; local issue TBD)
  • Could be addressed by (one or both of)
    • Reference lat/lon being derived from XLAT/XLONG corner(s) rather than CEN_LON/CEN_LAT attrs
    • Require user input of needed info if some sanity check fails (which would also lead to support for completely missing attrs, not just CEN_LON/CEN_LAT being rendered invalid)