Work / 02
METAR Parser
Aviation weather parsing
The Experiment
I wanted to see how far I could take a small parser before the format stopped being simple.
METAR looked straightforward at first: a compact string containing weather information in a defined format. But the further I went, the more variations, optional groups, unit systems, and edge cases appeared.
The project became an exercise in parsing, data normalization, and making a strict format usable by something outside the parser itself.
01 / Parsing
Recognize the language before displaying it.
The decoder tokenizes the report and walks through the groups, delegating individual patterns to specialized parsers.
Wind, visibility, RVR, weather, clouds, temperature, pressure, windshear, supplementary information, and other supported groups each have their own parsing rules.
The parser also needs to understand where one part of the report ends and another begins, including report boundaries and the transition into supplementary information.
02 / Normalization
Raw syntax shouldn't leak into the rest of the application.
Once individual groups have been parsed, the normalizer converts them into a consistent structure that the frontend can work with.
That includes unit conversion, temperature and pressure conversion, RVR normalization, weather and cloud descriptions, and human-readable display values.
This also gives the application one place to deal with differences between ICAO conventions and selected FAA representations.
03 / Frontend
The UI stays deliberately simple.
React and TypeScript provide the interface around the decoder: enter a METAR, decode it, and inspect the resulting structured information.
Because parsing and normalization happen before the data reaches the UI, the frontend does not need to understand raw METAR syntax.
04 / Scope
Small by design.
METAR Decoder 1.0 focuses specifically on decoding supported METAR reports.
It does not attempt to encode reports, decode TAFs or NOTAMs, provide live weather feeds, or fully interpret the entire RMK section.
Keeping the scope narrow made it possible to spend more time on the correctness of the formats it did support.
Reflection
A small parser is a surprisingly good lesson in software boundaries.
The project started as an experiment rather than a response to a particular problem. What made it interesting was discovering how quickly a compact specification turns into a collection of edge cases once you try to handle it reliably.
Parsing, normalization, and presentation became separate concerns almost naturally. That separation made the application easier to reason about and gave me a better appreciation for the value of structured intermediate data.
One Last Thing
Aviation software should probably contain at least one stupid aviation meme.
More Work
View all projects