sky: overcastcumulonimbus at 1000 feet

should read

sky: overcast^cumulonimbus at 1000 feet

Consider the following METAR report:

METAR EBBR 172150Z 11008KT 2000 -SN BR FEW003 BKN006 M03/M04 Q1007 R25/4999 R02/4999// R75/290066

Parsing this report raises the following error:

ParserError: Unparsed groups in body 'R25/4999' while processing 'METAR EBBR 172150Z 11008KT 2000 -SN BR FEW003 BKN006 M03/M04 Q1007 R25/4999 R02/4999// R75/290066'

However, an RVR of the form 'R25/4999' is totally valid and should be parsed without error.

PR count is low and fairly stable. Might be a good time to run the code base through a style formatter. I can take the lead on this if desired.

I have historical METARs to parse going back several years. Is there a way I can import and tell the import the month/year that the METAR originated?

Another not supported METAR is

METAR EDDH 251020Z 26006KT 230V290 9999 R23///// R15///// FEW032 BKN080 26/19 Q1017 NOSIG

Is it intended to make the library capable of understanding this kind of METAR at some point?

For me it is not critical, I just thought it could be good to share it.

Thanks a lot for the great project!

Is there a way to distinguish between a TEMPO group visibility and present wx in an International METAR?

NFFN 300000Z 26007KT 9999 SCT025CB BKN045 25/24 Q1010 TEMPO 3000 TSRA

Hello :)
First of all, thanks to all of you for this lib.
And I want to know if it's possible to add the relative humidity in the decoded results?
It seems to not be an international standard but I see that some METARS have this value:
https://tgftp.nws.noaa.gov/data/observations/metar/decoded/LFLC.TXT

Thanks :)

This METAR has R28L/2600FT but reduction reads:

visual range: on runway 28L, 2600 meters
(should read: visual range: on runway 28L, 2600 feet)

Reference: METAR KPIT 091955Z COR 22015G25KT 3/4SM R28L/2600FT TSRA OVC010CB 18/16 A2992 RMK SLP045 T01820159

Automatic report could broke the present weather output.

This METAR :
METAR FSIA 220100Z AUTO 14014KT 120V180 9999 ///////// 27/23 Q1010

gives an error when the method present_weather is triggered:

UnboundLocalError: local variable 'precip_text' referenced before assignment

P0000 represents a trace of precipitation, similarly, the 6-group 60000 and 7-group 70000 mean trace as well. The library should denote this as such. Will boggle how and produce a PR :)

Hi,

This error show me for tha following metar code:

SKNA 131100Z 8000 HZ FEW060 26/XX A2974 =

The error is:

-----------------------------------------------------------------------
METAR:  SKNA 131100Z 8000 HZ FEW060 26/XX A2974 =
-----------------------------------------------------------------------
Traceback (most recent call last):
  File "sample.py", line 90, in <module>
    obs = Metar.Metar(code)
  File "/home/xavier/python-metar/metar/Metar.py", line 413, in __init__
    raise ParserError(handler.__name__+" failed while processing '"+code+"'\n"+" ".join(err.args))
metar.Metar.ParserError: _handleWind failed while processing '8000 HZ FEW060 26/XX A2974 = '
direction must be 0..360: '800.0'

But the value 8000 is a visibility field not wind direction

Any idea?
Thanks

Metar in question:

KAXA 120335Z AUTO 34025G34KT 10SM SCT100 120 M09/M15 A2988 RMK AO2

Short story of how I found this:
Parsing was throwing an error about not using M09/M15 even though the regex for that was just fine. The issue was the _handleSky didn't seem to be consuming all the sky values? _handleTemp was trying to parse 120 M09/M15 A2988 RMK AO2 which was too much for it.

Thoughts on what that 120 is? Is that where the clouds clear? Is that a repeat of SCT so they just shortened it? I'd be happy to PR my little fix, once we determine the best course of action.

Thanks.

Is there are way of putting all the information in a dict to be stored ?

I am looking for a way to store all the information provided in the example you have on your github.

I am trying to store more than one METAR and I need a easy way of calling each METAR.

from metar import Metar
obs = Metar.Metar('METAR KEWR 111851Z VRB03G19KT 2SM R04R/3000VP6000FT TSRA BR FEW015 BKN040CB BKN065 OVC200 22/22 A2987 RMK AO2 PK WND 29028/1817 WSHFT 1812 TSB05RAB22 SLP114 FRQ LTGICCCCG TS OHD AND NW -N-E MOV NE P0013 T02270215')
print obs.string()
{station: KEWR, type: routine report, cycle 19 (automatic report), time: Tue Jan 11 18:51:00 2005 ... etc

This METAR I found seems to deviate from the spec, but was returned from a station:

KAXA 180835Z AUTO 3.45833303KT 10SM CLR 10/07 A3003 RMK AO2

which gives the error:
Unparsed groups in body '3.45833303KT' while processing 'KAXA 180835Z AUTO 3.45833303KT 10SM CLR 10/07 A3003 RMK AO2'

Definitely a goofy one. Any thoughts on what to do there? From what I can tell, the validation I'm doing, others are just ignoring it.

EDIT: This is actually from your group's data @akrherz - I'm using your sample python downloader for 2012-08-01 to 2012-09-01. That's the goofy AXA station.

Black cleaned up the code (thanks for the merge @akrherz).

Do we add a pytest-pep8 to Travis to enforce now? My vote would be yes.

I just realized that this package occurs twice at PyPI

metar
python-metar

I wonder aloud how we fix this and if we have the same issue at conda-forge

I just found an other fun stuff in METAR, the RF group.

RF group reports rainfall in the last ten minutes and accumulated rainfall since 0900 local. For example, RF02.2/024.4 reports that 2.2mm of rainfall has fallen in the 10 minutes prior to the report time; and 24.4mm has fallen since 0900 local.

Seems like all the cool kids are using pytest these days, so perhaps we should as well? This could be one of those changes we tackle for a 2.0 release. I am willing to effort the code change.

checklist:

• ensure python setup.py test properly runs pytest (actually runs more than 0 tests)

I want to clarify what license is used by Metar.
setup.py says the MIT license.
But the LICENSE file (extracted from README) looks like a BSD license.

in file: metar/station.py, line 39:

print(sta_id, stations[sta_id].name, stations[sat_id].country)

instead of sat_id there should be sta_id

This METAR METAR COR ESNS 141420Z 10007KT 9999 FEW045TCU SCT047 14/06 Q1010= fail metar.Metar.ParserError: Unparsed groups in body: ESNS 141420Z because of the group "METAR COR" .

ref : http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI1/Publications/2014update/306_vol_I1_2014_en_track.pdf

By the way, thanks for this great lib :)

Hi,

in this METAR METAR LOXZ 141420Z 08006KT 20KM VCSH FEW025SC SCT040SC BKN090AC 21/14 Q1015 BECMG SCT090 parsing is ok but when we want the string representation we got an error

line 1161, in sky_conditions
    what = CLOUD_TYPE[cloud]
KeyError: 'AC'

AC for Alto Cumulus should be added.

Although the unit testing at travis runs without problem, another way of testing actually fails:
python3 setup.py test
produces this error:

ERROR: Station (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: Station
Traceback (most recent call last):
  File "/usr/lib64/python3.6/unittest/loader.py", line 153, in loadTestsFromName
    module = __import__(module_name)
  File "/home/jos/python-metar-master/metar/Station.py", line 8, in <module>
    from datatypes import position, distance, direction
ModuleNotFoundError: No module named 'datatypes'

and looking at the source code I think it is right, this sure seems a mistake to me in the Station.py file.
This is the case for the current git version and also in the 1.6.0 release version.

In addition, it may be good to activate this way of testing as well on travis, or change the code to let the nose testing execute this test.

it this compatible with pandas. I need the visibility,wind speed, ceilings/clouds, time, Routine/Speci. Is there any easy way to output the data short and simple.

The METAR I want to read is this:

METAR EDDH 300720Z 22019G31KT 8000 -RA FEW009 BKN011 09/07 Q1003 WS R23 TEMPO BKN015

But when I try to do so, I get the following exception:

metar.Metar.ParserError: Unparsed groups in body: 'WS R23'

I do not use METARs frequently so I checked the manual which said that the code means "Wind shear in the lower layers". Actually I am not interested in the wind shears at all but if there is an exception I need to deal with it somehow.

This is probably an issue with the METAR format in general, but the library probably still should attempt to account for it. For example:

m  = Metar("KSUX 301552Z 31013KT 10SM CLR M21/M24 A3091 RMK AO2 SLP500 T1201244")
m.press_sea_level.value("IN") #28.053406598988072
m.press.value("IN") #30.91

I am curious if you have any thoughts on this? I'll likely make a PR to attempt to account for it.

Hi all,
from this Metar METAR YMML 221830Z 22013KT 9999 FEW009 BKN011 BKN028 11/08 Q1027 FM1830 20010KT 4000 SHRA BKN010 FM1915 18012KT 8000 SHRA SCT015 or this one METAR YMML 221830Z 22013KT 9999 FEW009 BKN011 BKN028 11/08 Q1027 FM1830 20010KT 4000 SHRA BKN010 FM1915 18012KT 8000 SHRA SCT015 the FM group break the parser :
metar.Metar.ParserError: Unparsed groups in body 'FM2200 15008KT CAVOK' while processing 'YMML 102100Z 13008KT 9999 SCT018 16/10 Q1018 FM2200 15008KT CAVOK'

I am working with v1.6 from conda

Getting a parse error on a metar from OMAA right now

Exception has occurred: ParserError
Unparsed groups in body 'DIST CB TO NW' while processing 'OMAA 200300Z 06006KT 8000 -RA FEW040 22/19 Q1012 WS ALL RWY TEMPO VRB30G45KT 1500 TSRA BLDU FEW040CB DIST CB TO NW'```

If you're like me and get most of your METAR codes from FAA's ASOS program, you get a lot of parser errors.

The MetarParser subclass in cloudside gets around this by simply logging the error and moving on.

It'd be nice to have this as an option upstream.

While I hesitate to even bring this up, the mix of 2-space and 4-space indentation makes the code base a little tricky to work with.

I propose we standardize to 4 spaces, and remove all of the trailing white space in that process.

I would also suggest that we address other PEP8-ish issues, but separately from the indentation.

It's kind of hard to figure out where the home of this code is, because the PyPi page points to SourceForge, which looks long dead.

Likewise the PyPi page doesn't look like its been updated in a long time, version 1.4 was released in 2009.

Unless there is a compelling reason for the current state of play, any objection to some combination of:

• Updating PyPi to point to this Github Repository
• Incrementing the version number and publishing a new build?
• Deleting the SourceForge page, or alternately, updating the documentation there so that its clear the project is actually happening here and providing a link?

current code fails to parse this METAR.

>>> from metar.Metar import Metar
>>> report = Metar('KICT 210556Z 01015KT 5SM -SNFZDZ BR OVC014 M08/M09 A3025 RMK AO2 SNB21 SLP261 P0000 60000 T10781094 11050 21078 410281078 51010')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/akrherz/projects/python-metar/metar/Metar.py", line 435, in __init__
    raise ParserError(message)
metar.Metar.ParserError: Unparsed groups in body '-SNFZDZ' while processing 'KICT 210556Z 01015KT 5SM -SNFZDZ BR OVC014 M08/M09 A3025 RMK AO2 SNB21 SLP261 P0000 60000 T10781094 11050 21078 410281078 51010'

Will have to investigate if -SNFZDZ is valid or not.

Not sure if this is out of scope for this project but I am trying to parse the ASOS 5 minute records which look like:

23061KALS ALS20180827181010908/27/18 18:10:31 5-MIN KALS 280110Z AUTO 24012KT 10SM CLR 23/02 A3009 7380 25 9900 230/12 RMK AO2 T02280022

The parts after the 5-MIN look almost like a METAR string but not quite? Just wondering if this would be the right place to support parsing this data?

The only specification documentation I can find is here, ftp://ftp.ncdc.noaa.gov/pub/data/asos-fivemin/td6401b.txt

Thank you for your time.

you have chosen to include only part of this repository in the tar file published on pypi.
However, the included README file refers to the test/all_tests.py file, and that one is missing.
Please provide this file in your next update.
It might be easier to provide the full content of this repository in the tar file published on pypi.

See discussion on #51 that received a bandaid for the 1.6.0 release.

It would be nice to remove the large try: section in the Metar.__init__ that uses a catch all exceptions. We have testing and large archives of real METARs that we can figure out where the bugs are and use defensive programming. This may involve some API changes, so we'll do for a 2.0 release.

There was a larger discussion on this a few years back, but I am struggling to find the issue.

Good evening,

My name is Lawrence Blundo. I am a senior meteorology student at Embry-Riddle Aeronautical University. I am currently working on a senior thesis, and one of my tasks is to read through ten-years of METAR data from Boston, KBOS and find the reports where the 3/6 hourly temperature, 6 hourly precipitation, 24 hour temperature, and 24 hour precipitation. I'm going a little stir crazy as I've been sitting here trying to figure out how the Metar.py package exactly works (I know I can use it to help out with my project but I just can't figure out how it works). I would just like to know how the package scans through a METAR report and decodes it into a report that is readable and easy to understand. If someone could help me out I would be grateful.

Consider this code:

This gives currently (beginning of March) the following error: ValueError: day is out of range for month, e.g. for this record: METAR EDDM 300020Z 06004KT 9999 2000NE BCFG SKC 04/03 Q1005

Because the record's day (30) is greater than today (5), the current month (March / 3) is set to February (2), which has only 29 days, resulting in the error.

I've got two suggestions, one of them would break the API:

1. make month and year a mandatory parameter.
2. if the idea of guessing the month should be retained, always guess a month that has 31 days.

Correct formula is:

a = sin(0.5(lat2 - lat1)) * sin(0.5(lat2 - lat1)) + cos(lat1) * cos(lat2) * sin(0.5 * (long2 - long1)) * sin(0.5 * (long2 - long1))

In the README file you write:

I'm not sure from where you can download the World Meteorological
Organization (WMO) Manual on Codes, vol I.1, Part A (WMO-306 I.i.A)

This manual can be found through the WMO website:
http://www.wmo.int/pages/prog/www/WMOCodes.html
or downloaded directly via
https://library.wmo.int/opac/doc_num.php?explnum_id=3361

Consider the following METAR report:

METAR EBBR 040220Z VRB01KT 0150 R25L/1200N R25R/0600N R02/P1500N FG BKN001 07/06 Q1017 NOSIG=

It says, that RVR for runways 25L is 1200 m, for 25R is 600 m, and for 02 is 1500 m, respectively.
However, the output of the following code gives the same values but with unit feet, which is wrong, since the METAR report gives meters.

from metar import Metar

m = Metar.Metar('METAR EBBR 040220Z VRB01KT 0150 R25L/1200N R25R/0600N R02/P1500N FG BKN001 07/06 Q1017 NOSIG')
print(m.runway_visual_range())

on runway 25L, 1200 feet; on runway 25R, 600 feet; on runway 02, greater than 1500 feet

Similarly, requesting RVR in unit meters explicitly give wrong values:

for name, low, high, unit in m.runway:
    print(f"RVR for runway {name}: {low.value(units='M')} m")

RVR for runway 25L: 365.7599882956804 m
RVR for runway 25R: 182.8799941478402 m
RVR for runway 02: 457.1999853696005 m

Hello,

I am using the Pandas package for my robot framework implementation.
My scenario is to get the data from excel and prepared the below .py file:

import pandas as pd
from pandas import ExcelFile

class excelpd(object):
def init(self, pathtofile, sheetname):
print("Setting up File path and sheet name.")
self.df = pd.read_excel(pathtofile, sheet_name=sheetname)

def get_colw(self,rowname,name):
    if rowname == "Login":
        LoginData = self.df.reindex([1 , 2])
        column = LoginData[name]
        print(column)
        return(column)
    if rowname == "Part":
        PartData = self.df.reindex([4 , 5])
        column = PartData[name]
        print(column)
        return(column)

and Calling the function by passing the parameters as below:
Get Colw Login Username

Giving error message as "KeyError: 'PartName'.

Could you please help me to resolve the issue.

Attached the file using for the test.

Error occured with this metar line: "KCGF 260045Z 25005KY 10SM BKN040 20/10 A3005"

The version on pypi seems to be from 2016 while there are newer commits. Is that version still usable for basic parsing?

Does the parser differentiate between Rain Freezing Drizzle and other precip type start and end times KMHT 131053Z 35011KT 3SM -FZDZ BR BKN007 OVC015 01/M01 A2951 RMK AO2 RAE20DZB20E39FZDZB39 SLP013 P0001 I1000 T00061006

Like in this RAE20DZB20E39FZDZB39
Rain end at 20 minutes past the hour
Drizzle began 20 minutes past the hour
Drizzle end 39 minutes past the hour
Freezing Drizzle began 39 minutes past the hour ?

A NWS collaborator reached out to me wondering if I was parsing the I Group for 1,3 hourly ice accumulation totals. These are now collected from new sensors in Texas and Oklahoma. For example:

KABI 031752Z 30010KT 6SM BR FEW009 OVC036 02/01 A3003 RMK AO2 SLP176 60001 I6003 T00170006 10017 21006 56017

From FMH-1

Ice Accretion. At designated stations (with SPECI capability freezing rain sensor) ice
accretion shall be reported in METAR and SPECI reports when accretion is occurring or
has occurred during the reporting period.

1. Hourly Ice Accretion Amount (I1nnn). At designated automated stations, the hourly
   ice accretion amount shall be coded in the format I1nnn, where I is the ice accretion
   group indicator, 1 indicates an hourly amount, and nnn is the accretion amount since
   the last METAR. The amount shall be coded in hundredths of an inch. For example,
   "I1004" would indicate 4/100 of an inch of ice accretion in the past hour.
2. 3- and 6-Hourly Ice Accretion Amount (I3nnn and I6nnn). At designated stations,
   the 3- and 6-hourly ice accretion group shall be coded in the format I3nnn and I6nnn,
   respectively, where I is the group indicator, 3 and 6 indicate 3- and 6- hourly groups,
   respectively, and nnn is the accretion amount. The amount of ice accretion in the past
   3 hours shall be reported in the 3-hourly report; the amount of ice accretion in the past
   6 hours shall be reported in the 6-hourly report. The amount shall be coded in
   hundredths of an inch. For example, I6023 would indicate 23/100 of an inch of ice
   accretion in the past 6 hours.

Depending on where you look in the source code, python-metar is either at version 1.2, 1.4 or 1.5.0.

On pypi, python-metar is at 1.4.0
conda-forge metar is at 1.5.0
I have various github issues against a 1.5.0 milestone, hehe.

We should at least straighten out how the version is specified. My thought is to define it once in metar/__init__.py and then reference that in setup.py and perhaps in metar/Metar.py (perhaps it should be removed from that file).

Maybe our first formal release should be 1.5.1 ?

Hi!

thanks for providing the METAR python package!

I understand every METAR ends with a "=". I was wondering if one could include an autoremove of this as else an error is reported?

'METAR EGLC 010020Z AUTO 19004KT 150V220 9999 NCD 17/13 Q1022='

Best

Georg

The METAR this resulted from is this

METAR EDHI 180720Z 24004KT 210V270 2500 100NW R05/0300V0800U PRFG BR VV/// 13/13 Q1011

Need to review how this impacts the python-metar library

NOUS41 KWBC 201445
PNSWSH

Service Change Notice 18-71 Update
National Weather Service Headquarters Silver Spring MD
745 AM EDT Fri Jul 20 2018

To:  Subscribers:
  -NOAA Weather Wire Service
  -Emergency Managers Weather Information Network
  -NOAAPort
  Other NWS Partners and NWS Employees

FROM:     Bruce Entwistle
  Chief, Aviation and Space Weather Services Branch

Subject:  Updated: Change in the METAR code for the United States
  regarding hail reporting effective September 13, 2018

Updated to change moderate ice pellets from (IP) to (PL)

Effective September 13, 2018, GR will represent all sizes of hail,
and GS will only represent snow pellets.

Per Federal Aviation Administration (FAA) Notice 8900.275 from
winter 2014-2015, small hail (GS) was determined to be
meteorologically equivalent to moderate ice pellets (PL) for
anti-/de-icing purposes. This change meant new de-icing tables for
the airlines and necessitated a change to the METAR code in the
United
States. Currently, GS is defined as small hail or snow pellets.

Following a safety risk assessment, the FAA decided the best course
of action was to change the coding of the GS (small hail and snow
pellets) and GR (large hail to greater than or equal to 1/4 inch)
to the following:

- GR refers to all hail
- All reports of hail must include hailstone size diameter in the
Remarks (RMK) section of the METAR/SPECI in increments of 1/4 inch
- If no hail size is reported it will be assumed to be small hail
- Small hail will result in the issuance of a SPECI
- GS is used only when snow pellets are observed

A requirements letter was sent to Office of Federal Coordinator for
Meteorology (OFCM) requesting change to Federal Meteorological
Handbook-1 (FMH-1). (Apr 27, 2016). The new FMH-1, with the code
change, went into effect November 2017, but the actual implementation
has been delayed until September 13, 2018. See:

https://www.ofcm.gov/publications/fmh/FMH1/FMH1_2017.pdf

For questions regarding the METAR coding change, please contact:

Michael L. Graf
Meteorologist/International Liaison
NWS Headquarters

Silver Spring MD 20910
Email: [email protected]
Work 301-427-9109
Cell 304-268-0691

National Public Information Statements are online at:

https://www.weather.gov/notification/