Failed to parse A2981 in weather.gov output

[xandkar]

URL: https://w1.weather.gov/data/METAR/KMHT.1.txt

Full payload fetched from URL:

000
SAUS70 KWBC 021906
MTRMHT
METAR KMHT 021853Z COR 05006KT 10SM TS SCT075CB BKN150 33/13 A2981 RMK
AO2 LTG DSNT S-W TSE28B31 SLP102 OCNL LTGCG VC N W TS VC N W
MOV S TCU N-NE T03330128

The part I tried to parse:

KMHT 021853Z COR 05006KT 10SM TS SCT075CB BKN150 33/13 A2981 RMK

stderr:

Error: KMHT 021853Z COR 05006KT 10SM TS SCT075CB BKN150 33/13 A2981 RMK
                                                              ^
ParsingError { positives: [runway_number], negatives: [] }

Output of dbg!(metar::Metar::parse("KMHT 021853Z COR 05006KT 10SM TS SCT075CB BKN150 33/13 A2981 RMK"));:

metar::Metar::parse("KMHT 021853Z COR 05006KT 10SM TS SCT075CB BKN150 33/13 A2981 RMK") = Err(
    MetarError {
        string: "KMHT 021853Z COR 05006KT 10SM TS SCT075CB BKN150 33/13 A2981 RMK",
        start: 62,
        length: 0,
        variant: ParsingError {
            positives: [
                runway_number,
            ],
            negatives: [],
        },
    },
)

[xandkar]

Another example:

Error: KMHT 021953Z 16008G16KT 10SM -TSRA FEW040CB SCT090 BKN150 BKN250
                                                                ^
ParsingError { positives: [cloud_density, cloud_type, temperature], negatives: [] }

[lilopkins]

Hi @xandkar,

So I've looked at the two METARs you have provided and there is an issue with the parsing of the first one with how the RMK section has been constructed. I will work on a fix for that one.

The second METAR you provided looks invalid to me anyway as it does not mention any temperature, dewpoint or air pressure component. Perhaps this was missed when they released them as sometimes METARs are released that are technically invalid.

[xandkar]

Thanks, @lilopkins!

A broader question - if it is common for providers to release technically invalid METARs, perhaps a more forgiving parsing approach is needed? Say to parse and return all that can be parsed and include an additional field for a list of codes that could not be interpreted?

https://www.weather.gov/ is an important provider, so it's probably worth it to work with whatever they've got.

[lilopkins]

That is and has been an interesting question. Given the vast number of possible ways in which a METAR may be produced incorrectly (and any potential ambiguity that could arise in interpreting it) I have not yet attempted to allow errors. The current goal of this parser is to interpret METARs when they are correct, but most importantly not panic and instead give the most sensible error possible if a METAR is 'incorrect'. In the future I may look at allowing 'partial' parsing to try and understand what is present even if some of it is malformed, but this is currently not yet in progress as there are a few fields of METARs that are not yet parsed.

In the case of the the first METAR you submitted, a more lenient parser may or may not have been able to cope with it anyway. Looking again at the second METAR, I've pulled up the historical archive and it seems that what you attached at least to this issue is not the full METAR, which is:

KMHT 021953Z 16008G16KT 10SM -TSRA FEW040CB SCT090 BKN150 BKN250 23/19 A2983 RMK AO2 PK WND 02029/1915 LTG DSNT S AND SW RAB21 SLP111 OCNL LTGCG S-SW TS S-SW MOV S P0013 T02280189

With this full METAR, it does parse correctly. I do try to monitor a variety of METARs across the world to correct for any abnormalities as they appear and the US generally never has issues, but of course I am very keen to fix them when they arise.