Gridpoints unit selection

[netbymatt]

Is your feature request related to a problem? Please describe.
The /gridpoints/{wfo}/{x},{y} path only provides data in SI units, even though there are keys throughout the json object that suggest the original units are US. Here's an excerpt:

"temperature": {
    "sourceUnit": "F",
    "uom": "unit:degC",
    "values": [
        {
            "validTime": "2019-10-24T07:00:00+00:00/PT2H",
            "value": 6.6666666666666856
        },

It's also very clear from the values that the data was in °F in this case and converted to °C from the repeating decimal caused by the 5/9 conversion factor. Other paths further down the gridpoints chain allow the units to specified such as /gridpoints/{wfo}/{x},{y}/forecast/hourly?units=si

Describe the solution you'd like
Allow units to be specified on the /gridpoints/{wfo}/{x},{y} path. I've seen bandwidth concerns cited on other discussions and in the FAQ and this looks like an opportunity for bandwidth savings. And as a bonus it eliminates the need to convert client side and deal with conversion inaccuracies that cause repeating decimals to be shown to the end user unless number formatting techniques are used.

Describe alternatives you've considered
This is completely fixable on the client side, but base data seems to be in different units than what's available in the API.

Other comments
Keeping a common default units for the entire API would make sense, but at this point it's deployed and probably not possible to implement without potentially breaking client code. /gridpoints/{wfo}/{x},{y} returns SI units and /gridpoints/{wfo}/{x},{y}/forecast/hourly returns US units. Adding a common units parameter throughout seems like the correct solution to this.

[StephenClouse]

Unfortunately this is not something we intend to change.

The choice of SI units for the baseline data was a very deliberate design choice. We designed the API in part to serve as an interoperability service for data distribution to WMO nations, and so we limited its output to units defined in the WMO Codes Registry. This, as you might expect, limits itself to SI units along with a very narrow subset of non-SI units used in international aviation (such as knots and nautical miles). Non-WMO units are introduced only where there is literally no other alternative. The design was always to defer these conversions to the consuming client.

In a few rare cases we do an internal conversion to a WMO-supported unit more convenient for end user consumption; for example, the MADIS service natively sends us observation temperatures in Kelvin and we convert these to degrees Celsius. In cases where units are natively US customary, such as the forecast grid data, these are converted to WMO-supported units for the reasons stated above.

The units flag on the forecast endpoints is one of the rare exceptions. It affects only the human-readable textual forecast elements, and this exists only because there is no feasible way to export this functionality, as the textual output routines are currently proprietary to the National Weather Service. But this option does not alter the structured data for the reasons already stated.

I hope this explains our stance and reasoning for the design, although I realize it's not the answer you're looking for. We still might rethink this at a later date, but it is a very low priority.

The sourceUnit showing in the forecast grid output is a bug that we have fixed in an upcoming release; it is an option for our internal debugging that should not be appearing in production.

[netbymatt]

Excellent response. I completely understand.

Can I recommend that when you're required to make these conversions to fit the WMO specification, such as the ones that I'm seeing on /gridpoints/{wfo}/{x},{y}, that you take into account significant figures? I'm sure that the field instruments that you're using report 4 or 5 significant figures at most. This would make the data more correct from scientific and engineering standpoint. And as a side effect it would probably reduce some of the rounding errors and other formatting issues that get introduced with client-side conversions.