METAR Parsing for Precipitation Accumulation and Remarks Section

[DirkMPetersen]

Hello there! I have been using this module to parse METAR data and would like to suggest the addition of parsing precipitation data and and other miscellaneous objects in the remarks section of a METAR into the "metar" part of the module.

Parsing METARs into CSV's helps make working with the data that are contained in them much less intimidating, and fleshing out the parsing capabilities of this module would make this the no-brainer module to use for this purpose.

Here is an example:
5-MIN KOMA 190550Z 16005KT 10SM -FZDZ SCT019 OVC026 M01/M03 A3015 770 88 -900 150/05 RMK AO2 SLP219 FZDZB44 P0000 60000 I1000 I6000 T10111028 10006 21039 400281056 51018

Very useful information located within the "RMK" (or remarks) section include the following items:
FZDZB44 -> Freezing drizzle began at 0544Z
P0000 -> The amount of precipitation the has occurred since the last METAR is considered a trace.
I1000 -> 1-hr Ice accretion of a trace
I6000 -> 6-hr Ice accretion of a trace

Thanks for doing what you guys do! Like I said the amount of documentation with this python module is great, and fleshing this feature would make the the "go-to" METAR parser for python.

[dopplershift]

We definitely need to make sure the full remarks section is available in the decoded output--the fact that it's not there right now is a major oversight--borderline bug.

Decoding some blocks would be great. The only one of those mentioned above that gives me pause is the FZDZB44 because I'm not at all sure how I would represent that decoded into a column in a DataFrame.

[DirkMPetersen]

Perhaps that particular block could just have a column of its own, with the label of "precipitation onset time" and also be paired with " precipitation end time? It would only need to be filled out when those are included into the remarks section, and could be null when the aren't included.

FZDZE04 FZDZB44 is still very useful information, and just having their own column would be a plus with start time and end time as the names. I know a particular application that this would be great for is using continuous freezing precipitation for ice accretion research.

[dopplershift]

What would you want that to look like when there are multiple such periods, sometimes with multiple precipitation types?

[DirkMPetersen]

Hard to say exactly... Just a look at a particular 5-minute METAR that came in had this: PLB50E50SNE06B21E31B50 That is a VERY hairy thing to parse and organize effectively. Perhaps similarly to cloud groups with low, mid, and high clouds having them iterate up in number? I could see myself using columns in a dataframe with headers similar to this: wx_(1)_began , wx_(1)_ended , wx_(2)_began , wx_(2)_ended , etc. If this is too much, then I completely understand. I appreciate you looking at this!

…

-Dirk

On Wed, Mar 3, 2021 at 11:36 AM Ryan May ***@***.***> wrote: What would you want that to look like when there are multiple such periods, sometimes with multiple precipitation types? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1727 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANYQ56RQF3SVWSMJNBPJZ4DTBZXRTANCNFSM4YBZ4GAQ> .

[eliteuser26]

In issue #1306 I indicated that visibility and remarks were not part of the decoded Metar dataframe. Should I work on that issue by submitting a PR or wait for the code to be modified in the parsing section which decodes Metar reports?

[dopplershift]

@eliteuser26 PRs are always welcome (and I'm trying to prioritize getting the ones we have reviewed). I can say with certainty that addressing this issue/#1306 is not in our immediate plans.

[eliteuser26]

This is good to know. At least I can do some test on my side to see if I can add visibility and remarks in the code. This way I won't need to submit it just yet until it becomes a higher priority.

[mzuranski]

When it comes to parsing SLP out of remarks, would it be possible to have that populate the air_pressure_at_sea_level field?

Please correct me if I'm wrong on any of this, but right now air_pressure_at_sea_level is derived from the altimeter. The problem with that method is it assumes a standard atmosphere, and I've been noticing that result can vary significantly from SLP in the same observation. Obtaining SLP directly from the METAR would be ideal, but then we'd also need a way to toggle that I expect; we wouldn't want air_pressure_at_sea_level to be populated from a mix of both sources in the same DataFrame.

[mzuranski]

Similarly to SLP, could values from the T group populate the air_temperature and dew_point_temperature fields if it is available in the remarks?

Having a mix of sources for temp & dewpoint probably isn't as big of a deal as SLP, but the extra precision from the T group would be nice.

[dopplershift]

@mzuranski I would be fine with both of your suggestions.

[sgdecker]

I second all of @mzuranski 's suggestions, and, once parsing of SLP remarks is included, there should be an option to set air_pressure_at_sea_level to NaN if there is no SLP remark.