Suggestion: consistent treatment of units

[drmrbrewer]

Is there a way to ask the parser not to convert altitude from InHg to hPa? I'm not particularly fussed about this, but seeing as though there is no unit conversion for other values (like wind speed KT, temperature °C and visibility SM) it would seem more consistent if there were also no unit conversion for altitude... i.e. we either do all the conversion at our side, or all on your side, not a mix of the two.

In fact, I understand that the altitude value in the raw METAR can either be prefixed with A (meaning InHg) or Q (meaning hPa)... so I assume that in both cases the library returns a value in hPa? Would it be more consistent to specify a value and unit for altitude, like is the case for wind speed?

[aeharding]

This makes complete sense. I don't think the library should convert units (except to parse human readable to machine readable)... for example, 1 1/4 to 1.25.

[drmrbrewer]

Thanks for considering this. It would also seem to make sense to present temperature and dewpoint in a consistent manner to others, with value and unit?

This would also make it easier to implement this suggestion, since you could then just sneak in a raw value too.

[aeharding]

Changing temperature/dewPoint to objects to accomodate raw is a possibility, although providing unit is unnecessary for those because temps are always degC afaik. Ideally I'd only provide unit if the unit of measurement is dynamic.

[drmrbrewer]

although providing unit is unnecessary for those because temps are always degC afaik.

I think that may be the case, though I don't know the METAR rules in sufficient detail to know if there might be a modifier (like there is for altitude: A or Q) for those locations that more routinely deal in Fahrenheit. Probably not, but including the unit anyway would be a belt and braces approach.