Weather conditions parser could be more strict to avoid invalid conditions
aeharding opened this issue · comments
Describe the bug
I found the following TAF in the wild:
TAF AMD KVOK 232200Z 2322/2423 15015G20KT 9999 BKN035 BKN050 510008 QNH2966INS
BECMG 2411/2412 17012KT 9000 -SHRA FEW006 BKN014 OVC021 510065 QNH2965INS TX24/2322Z TN16/2413Z LAST NO AMDS AFT 2322 NEXT 2409
The token AMDS is interpreted as a duststorm weather condition:
Expected behavior
Duststorm is not added as a weather condition.
Additional context
I think a good way to solve this problem would be to slightly rework parseWeatherCondition().
At a high level, this function is scanning any token for anything that matches a Phenomenon. When it finds DS, it determines it's a duststorm. However, it's ignoring that AM is not a valid descriptor, and thus AMDS isn't a valid weather condition.
Instead, parseWeatherCondition() could try to parse the token in order, ingesting as it finds a valid intensity/descriptor/phenomenon(s), and only return the weather condition if the entire token is ingested. Please see the following PR in the Javascript port: https://github.com/aeharding/metar-taf-parser/pull/32/files#diff-148bacb6839f9d7e10901515876440d2e966036b4b9ff4ef8562349353df35d1
I'm curious as to your thoughts on this!
One last thing I'd like to point out, is that visibility is 2409 despite it being 9000 As you said in #413, the best solution might be to rework the parser to parse in order, or to ignore latter matches for commands. However, that might be a larger task! I can make a separate issue for the visibility issue if you'd like :)
Looking at this document, it seems like one possibility would be to arrange command to only parse in order. For example, "for the next token, look for winds. If next token is not a valid wind, look for visibility, etc etc"
Would definitely require some rework, but might not be too bad, as the general structure of the command definitions wouldn't need to change.
An unintended benefit I've found of changing the parsing logic to something like this is that phenomenons are parsed in order. For example, SNRA is parsed as ['snow', 'rain'] and RASN is parsed as ['rain', 'snow'].
Also, according to the following source, the order is important:
If more than one form of precipitation is observed, the appropriate abbreviations shall be combined in a single group with the predominant type of precipitation being reported first.
http://www.moratech.com/aviation/metar-class/metar-pg9-ww.html
Hello @aeharding
Sorry for the late answer on this issue.
I do agree that the parseWeatherCondition method needs to be reworked. I noticed false positive matches and added the isValid method but it was not enough.
I like your idea of validating the weathercondition only if the entire token is consumed.
I will inspire from your fix and create a PR for this
👍