From SYNOP to Station Model Symbols on Web Maps: Leveraging Web Technologies to Implement Standardized WMO Symbology for Synoptic Surface Weather Charts

Abstract

Modern web mapping technologies implement web standards that make the visualization of geoscience data on the web possible using various methods, offering a high degree of customizability for creating web maps. In meteorology, synoptic surface weather charts serve as crucial products to communicate observed surface weather at a point in time. To convey such information, these maps implement complex symbology, such as a multi-element surface station model symbol to indicate station data, isobars, and special line symbology to visualize weather fronts. Synoptic messages (SYNOP standard numerical code by WMO) are periodic meteorological reports of weather observations, exchanged by national meteorological services around the globe. This study focuses on visualizing surface weather data decoded from SYNOP reports. The paper introduces an open-source JavaScript module, which handles data decoding and dynamic symbol generation, using a WMO-compliant method for creating station model vector symbols for observational GeoJSON data on the client-side, in an interactive web mapping environment. Its output is compatible with popular, open-source web mapping libraries. It runs Python in the browser with Pyodide and makes use of the Web Workers API for parallelization, speeding up the decoding and visualization process without blocking the user interface thread. The developed module intends to help with easy representation of surface weather observations on web maps used in meteorology, which can also be implemented in a dynamically updated server–client architecture. The code is presented with a ready-to-use wrapper for Leaflet.

1. Introduction

Nowadays, the web offers a prime platform for publishing and visualizing geospatial data using various kinds of web maps, due to its dynamic and interactive nature, and it is facilitated by the power of well-established web technologies and standards. Interactive web mapping has also been increasingly popular over the past decades, and making maps on the web is available to potentially anyone [1]. In earth sciences, the use of thematic cartography is essential to convey scientific results, measurements, and analysis conclusions. Such maps serve as important supplementary resources supporting scientific results [2]. Ref. [3] examined the quality of maps published in journals for each earth science branch. In meteorology, one of the map types presenting meteorological thematic content is the synoptic surface weather chart. These maps serve as crucial products to communicate observed surface weather in a given area at a particular point in time. To convey such information, these maps implement various layers and visualization methods in their symbology, such as multi-element point symbols to indicate observational station data, isobars, and special line symbology to visualize weather fronts.

Focusing on the symbology of these maps, article [4] explores the interesting history and evolution of weather symbols and how scientific inquiry resulted in abstract cloud and weather symbols to represent various parameters of observed ground weather, depicting the human experience of the surrounding atmosphere. As described by the article, over the course of more than two centuries, 27 symbols representing physically distinct cloud types, and 100 symbols depicting weather events were developed. The combination of various cloud- and weather-type symbols and values is plotted in a complex multi-element symbol called the station model. The station model, often called a surface-plotting model, symbolic station model, or station plot, first came into widespread use around the 1920s [4] as one of the ways of improving communication among various nationalities in meteorology. Article [4] also highlights the decline of manual, hand-plotted weather maps since the 1960s, leading to the disuse of such symbols. While the recent increase in automation contributed to the symbols disappearing, the early efforts of scientists Ralph Abercromby, Hugo Hildebrand Hildebrandsson, and William Clement Ley in the late nineteenth century, trying to create symbolic representations of specific cloud types, established the foundation for international coding and mapping of clouds and weather by the International Meteorological Organization (IMO), and later, by the World Meteorological Organization (WMO) [4]. These codes were then used by observers to exchange observed weather information across the stations, and, after receiving and decoding these messages at a central location, plotters created synoptic surface weather charts with the incoming data from multiple weather stations across a larger area of the Earth [4]. Afterwards, analysts interpreted the plotted data, and forecasters formulated prognostication. Article [5] examines the characteristics of meteorological data and analysis tasks, gives an overview the current visualization techniques and tools in meteorological practice such as operational weather forecasting and atmospheric research, and discusses challenges and demands in visualization for meteorological data analysis. It also highlights the many types of observations and data structures used in meteorology. A network of weather stations yields scattered, non-gridded 2D data [5], and this data is then represented by the station model on weather maps.

Volume I.1 of the WMO-No. 306 “Manual on Codes” document, which constitutes Annex II of the WMO Technical Regulations (and therefore, has the status of a technical regulation), contains international codes and regulations for the graphical representation of meteorological data [6]. As illustrated in Figure 1, according to Attachment IV (“Graphical Representation of Data, Analyses and Forecasts”) of the document, the graphical representation of surface observations is accomplished with a surface-plotting model symbol. This symbol positions its subelements on predefined locations in a grid-like layout, around a central station circle. The standard requires the elements to be placed in the relative positions given, while allowing for omission of non-plotted elements. The station model includes both numerical elements with direct values for quantitative data and graphical/symbolic elements primarily for qualitative data. In general, station model symbols can display large amounts of observational surface station data in a concise, visually organized way. With these symbols, meteorological variables like cloud cover, wind direction, wind speed, temperature, pressure, pressure tendency, weather phenomena, cloud types in different altitudes, precipitation, and others can be effectively communicated simultaneously. The central, total cloud cover circle is referenced to the reporting station’s actual location, where the observation was made. In their products, meteorological organizations of countries might apply the WMO coding and representation with slight variation (for example, [7]), and in some cases, they might use their own coloring rules for some elements. The standard also defines a polychromatic method for plotting the station model, which allows some elements to be optionally colored, like the C_H high cloud symbol of code group 8N_hC_LC_MC_H or past weather symbols of code group W₁W₂ being colored red in the case of a report originating from a manned station. While digital static maps showcasing various meteorological variables with isopleths, raster layers, and wind arrows are common, maps containing station model symbols are scarce on the web.

Compared to simple geometrical symbols (e.g., a single shape) that represent point features, station models’ complexity lies in both their structural composition and the technical challenge of implementing them. The station model communicates both qualitative and quantitative data at the same time, compressed in a compact visual space, resulting in high information density for the whole structure. Moreover, the graphical representation of otherwise independent meteorological variables has to be handled on a case-by-case basis, as different rules for positioning and appearance are applied to each. Furthermore, in some cases, these elements are also linked to each other positionally (e.g., the code figure for cloud height above ground must be positioned below the position of the symbol for low clouds). From a technical implementation perspective, as the position of the subelements is also dictated by the WMO document, their positioning is of utmost importance in order to be rapidly and consistently interpretable by all professionals. In addition, the graphical representation of the wind shaft is data-driven, using wind direction data for symbol rotation, while other elements use numeric and symbolic encoding with a static, upright position relative to the whole symbol unit. Symbol diversity can also be a factor in gauging symbology complexity, although, as interpreting this type of symbology requires special prior knowledge of code figures and symbols, which professionals have at their disposal, this aspect is less significant.

1.1. Related Work

1.1.1. Illustrative Examples for Web Maps Implementing Station Models

Meteorological agencies publish a mix of static and interactive maps on their websites to communicate measurements and observations, with differing symbology. While web maps using the station model for visualizing weather observation data are scarce in general, several examples illustrate the implementation of such symbols on static, publicly accessible surface weather maps on the web. The web map examples presented in this section are organized by the means of implementation. All of the examples visualize meteorological variables or implement station models to some degree, although with highly varying methods and with differing media. First, static, digital web maps visualizing data with station models, distributed as pre-rendered raster images, are presented. Then, interactive maps of meteorological organizations are presented, and within this subset, maps employing station models in some way using raster layers. Lastly, an even smaller subset of interactive maps is mentioned, which use vector-based station models.

The Weather Prediction Center (WPC) of the National Oceanic and Atmospheric Administration (NOAA) of the United States publishes various static maps that, among other elements, incorporate station models, like the daily weather map [8] and the “North American Surface Analysis” map [9]. As illustrated in Figure 2, their Leaflet-based “Interactive Surface Analysis Map” product does show station model symbols, but all map layers and elements, including the station models, are part of a pre-rendered image overlay [10]. The “Unified Surface Analysis” product, published on the NOAA Ocean Prediction Center website, also implements such symbols on static maps produced for various regions [11]. As also illustrated in ref. [4], the NSF National Center for Atmospheric Research publishes real-time surface weather maps for subregions across the United States, incorporating station model symbols [12]. The Deutscher Wetterdienst (DWD) regularly publishes static “Analysis- and forecast charts” for Europe on the web, which depict observations with station models, adhering to a somewhat modified version of the station model WMO standard [7]. On the DWD map, the model symbol is plotted differently, as the wind shaft is separated from the central cloud cover circle, as shown in Figure 3. The ECMWF also publishes static “Mean sea level pressure analysis with observations” charts with station models rendered on the map [13]. As shown in the examples provided, most of these web maps are pre-rendered static maps.

On the interactive maps of meteorological organizations, the meteorological variables are often plotted on separate, toggleable layers. In some cases, only one layer can be enabled and seen at a time on the map, as seen on the OpenLayers-based MetEye interactive platform maintained by the Australian Government Bureau of Meteorology [14], and on the interactive maps of the Swiss Federal Office of Meteorology and Climatology MeteoSwiss [15]. In both examples, the method used simplifies data communication and does not allow the map reader to see multiple variables at the same time. These maps often illustrate data with heterogeneous and custom symbology, like in the case of MetEye, a colored rectangle containing the temperature value, or wind speed indicated in a similar rectangle symbol, accompanied by wind arrows to indicate direction. The Swiss web map only operates with two visual variables to represent data: symbol fill color for indicating values in a classified manner and, on the wind layer, shapes for indicating direction. In this example, no exact values can be read from the map itself; however, by clicking on station symbols on the map, interactive charts appear, displaying valuable historical and current data. Compared to the station model, the visualization method in these two examples is more accessible to non-expert users and has a reduced cognitive load for them, information richness on these maps is very limited. Narrowing down to examples implementing elements on interactive maps that resemble the station model, only a limited number of examples are available. In the U.S., the National Weather Service (NWS) Aviation Weather Center maintains an interactive Leaflet web map called the Graphical Forecasts for Aviation (GFA), based on aeronautical meteorological code data, namely the Aerodrome routine meteorological report (METAR, FM 15–XV) [16,17]. This map uses slightly different scalable vector graphics (SVG) symbols for observations, compared to the WMO standard station model. In aviation, weather depiction charts also implement a modified station model that omits some variables and their respective WMO standard symbols and uses additional aviation-specific symbols [18]. The interactive NWS Weather and Hazards Data Viewer, which uses the Esri-leaflet API within the Calcite Maps theme framework, has an overlay for showing surface observations with station model symbols [19]. As illustrated in Figure 4, these symbols seem to be partly WMO-compliant, with some elements, like the wind barb, air temperature, and dew-point temperature, present. The central cloud cover circle, being a simple circle with a black outline and a constant blue fill color, does not convey additional information in addition to the positional reference for the station. Moreover, it has some other differences compared to the WMO regulations, like the relative humidity value element placed northeast of the station circle, which is not part of the displayed elements in the standard. Another difference is the unusual position and unit of the sea level pressure reading. It is shown north–northwest of the central circle, and it depicts the full value in hectopascals, instead of being plotted in tenths of a hectopascal and omitting the thousands digit, as dictated by the WMO-No. 306 document. Although the organizations employ station models on their maps to varying degrees, the examples reveal a lack of uniformity in symbology.

1.1.2. Existing Capabilities for Generating Station Model Symbols

Although some capabilities for generating such symbols are present in existing desktop GIS software, web GIS lacks such features. In desktop GIS, MeteoInfo, a software for meteorological data visualization and analysis, can generate a station model plot containing a point layer that has station model symbols based on station data [20]. In Python, MetPy, a meteorological Python library for data analysis and visualization, can also produce station models [21]. GeoServer supports rendering front lines and wind barbs, making use of the SLD (Styled Layer Descriptor) styling markup schema [22], but the latter is done by transforming the gridded wind raster dataset into a grid of vector points [23], which is slightly different to the way station model symbols visualize wind with the central circle referenced to the station location. It has no support for complex station plot symbols natively. ECMWF’s (European Centre for Medium-Range Weather Forecasts) open-source Metview, a meteorological workstation application, can also plot station model symbols from BUFR observations (Binary Universal Form for data Representation, FM-94) using the standard WMO graphical representation [24,25]. HAWK-3, a meteorological visualization system designed and used internally at the Hungarian Meteorological Service (HungaroMET/OMSZ), is able to plot surface synoptic observations with station models [26]. The aforementioned desktop GIS solutions can generate and render visualizations that, to some extent, can plot station model symbols on static maps, which are then exported and published as static raster images.

1.2. SYNOP Numerical Code

Surface synoptic observations (SYNOPs) use numerical code for reporting surface weather observations, made by both manned and automatic weather stations. WMO differentiates subtypes for surface synoptic observation reports: FM 12 SYNOP is used for reports from fixed land stations, FM 13 SHIP is used for reports from sea stations, and FM 14 SYNOP MOBIL is used for reports from stations that are not at a fixed location. A SYNOP report (or message) has a standardized structure and consists of five-digit numeric groups for predefined types of data. In the report, section 0 contains identification data such as report type, day of the month, and hour of the observation, indicators describing the manner of wind observation and wind speed units, and the station identifier (WMO station ID). Section 1 data begins with indicators for precipitation data inclusion, manner of station operation, cloud base height, horizontal visibility, total cloud cover, wind direction, and speed. After the initial data, section 1 continues with core data groups that have a leading digit defining the type of observation, followed by the actual measurement values or coded types. The exact code form and coded types are defined in code tables in Volume I.1 of the WMO-No. 306 “Manual on Codes” document. The numeric groups may also have “/” slash characters, indicating missing data. The core sections 0 and 1 can optionally be followed by additional sections, such as, for example, section 2 for reporting sea surface temperatures and wave data by coastal station, while various countries also make use of section 5, which allows national code groups to be included in their SYNOP reports as well [6]. Figure 5 illustrates the code form of an FM 12 report as per the WMO document [6], sections 0 and 1 only. The example given in the figure is a synoptic observation made at station Gibraltar North Point (WMO station ID 08495) [27]. The color coding indicates the corresponding code groups in both the syntax and the example in the figure, for illustrative purposes only.

1.3. Research Objectives

As indicated by the heterogeneous examples and existing implementations presented, a lack of an open-source, modern, and web-compatible solution for displaying station models on web maps can be observed. As for shortcomings of existing implementations, overall, the station models produced by current implementations lack uniformity, which should be essential for an exact scientific communication and plotting method of surface observations, especially since a standard is available, governed by a global organization. Given that nations can refine their symbology to a degree, this is partly to be expected; however, a lack of a standardized, uniform solution can be observed across existing digital weather maps. Secondly, the examined implementations produce static symbols, contained by a raster output like an XYZ tile layer or a WMS layer (produced with undisclosed, potentially proprietary or internal software), completely limiting interactivity after being rendered. In a web context, while this is acceptable, restyling and dynamic updating are ruled out in the visualization. Out of the presented web maps and capabilities, there was only one example, the NWS Weather and Hazards Data Viewer, that employed surface observations with vector-based station models on interactive web maps. However, it seemed to be only partly WMO-compliant, with major differences to other examples and the WMO standard itself.

This research aims to tackle the challenge of generating one of the most structurally complex symbols found on such synoptic surface weather charts, the station model, in a web environment using an open-source solution, producing symbology that conforms to the WMO standard as closely as possible. For the purpose of generating station model symbols in this study, SYNOP is regarded as the primary data source and format, as it uses the same coding scheme as the station model, and therefore, it can be decoded and matched directly. The developed JavaScript (JS) tool can dynamically generate WMO-compliant, standardized symbology from SYNOP data, entirely on the client-side. Such a tool is intended to also make developing and hosting interactive surface weather charts on the Web easier and more accessible, so that earth scientists, meteorologists, meteorological organizations, and agencies with limited web development, thematic mapping, and web GIS knowledge can publish and visualize their measurements and data on such maps effortlessly. Due to its dynamically generated nature, its integration into automatic processes, like remote data updates for the client’s map, is possible, to achieve a dynamic and interactive data visualization. Its open-source design enables customization and ensures flexibility and seamless integration within established web services and server infrastructures. The implementation makes use of modern web technologies and is compatible with the most popular web mapping libraries, like Leaflet and OpenLayers.

Presumably, partly due to the previously summarized disappearance of such symbols of late, the recent cartographic literature has not focused on station model symbols and the visualization of weather observations, particularly in a modern, interactive web map environment. This gap in the literature highlights the relevance of this study, contributing to a specific, relatively unexplored domain in cartography and especially in web GIS. As also pointed out by ref. [4], the need to revitalize such symbology in the present era is unclear; however, restoring the human element represented by this refined symbology would be advantageous.

This paper only focuses on developing a workflow that involves generating the station plot symbols from SYNOP data, and therefore, producing other elements that synoptic surface weather charts have is not part of the scope for this research. Furthermore, the developed module only focuses on processing and visualizing data from sections 0 and 1 of the SYNOP code form, as these contain the majority of the data required for plotting the elements of the station model.

2. Materials and Methods

The objective of this research is to develop a straightforward approach involving the generation of WMO-compliant station models from SYNOP data that can also be used on web maps. Since the station model symbols are to be deployed on web maps in an interactive web environment, they are expected to be built in a web-compatible format, using contemporary technologies. The method presented is based on a newly developed JavaScript module that uses an open-source software architecture to ensure flexibility, reproducibility, and compatibility with various web mapping frameworks. The approach was designed as fully client-sided, in order to make the process as straightforward as possible for a developer implementing it on the web, without a server-sided component. Therefore, the rationale behind the design was to provide a method that seamlessly works with SYNOP data to produce a WMO-compliant symbol. This also allows for easy integration with web mapping libraries by applying the produced symbol for each feature in a dataset. As web maps are generally client-sided, a module that was purely client-sided was deemed particularly fitting for the purpose. This approach combines data decoding and visualization without intermediate data processing required by the user. Since the targeted medium is a web environment, JavaScript was used for the core module, and SVG was used for the generated symbols, as it offers infinite lossless scalability and dynamic customizability, widening the range of possible applications, use cases, and subjective or institutional needs.

2.1. Software Architecture and Workflow

To meet the proposed objectives, the method presented consists of two distinct core components:

• A decoder for SYNOP reports;
• A generator for station model symbols.

First, the SYNOP reports must be decoded into a format that can be easily used and interpreted. This intermediate format, produced by the decoder, is expected to be a JSON object that subsequent code logic can work with in JavaScript. Afterwards, this decoded data is to be used in the second component, where, based on this data, the code logic generates and assembles the station models according to the WMO standard. These station models are output in a format that can easily be visualized using web mapping technologies. These two core components are implemented in a top-level wrapper module that outputs the final SVG symbol for a point vector feature, a format also compatible with web mapping frameworks. The workflow is presented in the following subsections. First, in Section 2.1.1 and Section 2.1.2, the SYNOP decoder and the station model symbol assembly are presented. Then, Section 2.1.3 discusses the wrapper module, which, as an abstraction layer, ensures smooth and performant operation by managing the complete process. The flow diagram of the module is illustrated in Figure 6.

The module’s dependencies consist of Pyodide v0.29.0 and module Pymetdecoder v0.1.6 within Python. Pyodide is a CPython distribution based on WebAssembly and Emscripten that allows running Python code inside modern web browser environments and Node.js [28]. Pyodide is licensed under Mozilla Public License Version 2.0. It includes a package manager for loading Python modules. Pyodide offers a great degree of JavaScript–Python interoperability, meaning that there is a two-way binding that allows Python objects to call JS APIs, read input, or even manipulate the Document Object Model (DOM), for example, while JS can call Python functions, pass data, or vice versa. Pymetdecoder is a Python module developed by UK Research and Innovation (UKRI) and the British Antarctic Survey that decodes SYNOP FM 12, FM 13, and FM 14 meteorological reports into a Python dictionary format [29]. The module also supports the encoding of SYNOP reports of such dictionaries. Pymetdecoder is licensed under the terms of the Open Government Licence v3.0.

The need for using Python in the browser arose from the lack of a native SYNOP decoder library in JavaScript at the time of conducting the study. Various repositories, libraries, and packages for parsing these reports exist in other languages and frameworks, such as library Synop in PHP [30], package DecodeSYNOP in R [31], Metaf2xml in Perl [27], package SynopCtl in the now-deprecated ActiveX [32], and the aforementioned Pymetdecoder module in Python [29]. With the goal of the study in mind, which is focusing on the client-side visualization of such symbols, the most straightforward way of achieving the proposed objectives was using the Pymetdecoder module. This approach also resulted in running an as-light-as-possible Python environment in the browser with Pyodide. While developing a native SYNOP decoder in JavaScript would be the most optimal way for the best performance and degree of suitability, it was out of scope for the study to develop one from scratch. It is worth noting that in a properly established client–server architecture, the PHP and Perl packages would be the prime candidates for processing SYNOP data on the server-side, but as the paper focuses on a purely client-side implementation, these are less viable options. Performance and limitations of this implementation are further discussed in Section 3.3.

As for third-party material, the module uses the WorldWeatherSymbols pack, which is a complete set of WMO weather symbols in SVG format, with full metadata [33]. The set consists of symbols used to represent meteorological variables through code figures, like cloud type, total cloud cover, past, and weather from manned or automatic stations, pressure tendency characteristic, wind shaft, barb, and pennant symbols, with some additional symbols like state of the ground, swell direction, pressure centers, and line symbols for fronts. This freely available symbol pack was created by the OGC Meteorology and Oceanography Domain Working Group and is distributed under the CC BY 4.0 license. The pack also contains pre-generated PNG symbols and provides Python scripts for building the PNG equivalent of the symbols, if needed. A subset of the SVG symbols is illustrated in Figure 7.

2.1.1. SYNOP Decoder

The sole purpose of the SYNOP decoder component is to decode the input SYNOP string and return the decoded data in an organized JSON format.

First, a Pyodide instance is initialized within a dedicated, reusable web worker. The Web Workers API allows for running scripts and operations in a background thread, separate from the main execution thread. Web applications’ main thread is usually allocated to handling the user interface (UI). By using worker objects, computationally heavy processing can be offloaded to and performed in a separate thread, without blocking or slowing the main thread down [34]. For interactive web maps, this aspect is of key importance, as any stutters caused by processes that block the user interface while the user is interacting with the map (e.g., panning, zooming) are apparent. As web programs and JavaScript code run single-threaded, another benefit of using web workers is improved performance by performing heavy processes on a separate thread on the central processing unit (CPU). This multithreaded nature is different from the promise-based APIs and asynchronous code (async/await) in JavaScript, as their purpose is to achieve better code sequencing through callbacks; in other words, they are defining a continuous series of tasks in code. Moreover, by running a web worker for the Python environment, this worker can be reused multiple times for decoding multiple SYNOP reports. This is inevitable, as, in order for a synoptic weather chart to be usable for surface analysis, these maps visualize data from multiple weather stations, all of which must be decoded. In a geospatial context, web workers have been used for parallelization in various projects. For example, in 2023, ref. [35] introduced a client-side library for raster processing, making use of the latest web technologies, including the Web Workers API. Using this progressive web application approach, they also concluded a case study for watershed analysis in Iowa. A 2025 study [36] also leveraged the Web Workers API for estimating pedestrian carrying capacity of outdoor spaces.

Since the main JS thread and web workers communicate and exchange data through messages containing payload data, the top-level wrapper module sends messages to the worker with the “postMessage()” method, containing SYNOP data to be encoded. A queue data structure is implemented within the worker to temporarily store incoming encoded SYNOP reports in a queue, allowing for the startup overhead of the Pyodide instance. Once the Pyodide environment is ready, the processing of SYNOP reports begins automatically. In Pyodide, the submodule “synop” of the module Pymetdecoder is imported, which decodes the input string given as an argument. First, the module splits the individual code groups in the report to be processed individually. The first code group of section 0 is especially important, as it has information about the report type (FM 12 land station, FM 13 ship, or FM 14 mobil) that dictates what other sections and code groups the report might contain, whether they are mandatory or optional, whether they are allowed to have “/” slash characters for missing measurements, and how the actual data is interpreted across the whole report. As there are code groups that are only present in very specific cases (e.g., code group (00fff) is only included when indicated wind speed “ff” in group Nddff is 99 or more), the module processes the code groups in a way that keeps track of their order. In addition to validation functions for checking group validity using regular expressions and helper functions for occasional unit conversion, one of the core parts of the module is the classes for meteorological variables that extend a shared class for observations (e.g., “class PressureChange extends Observation”). If needed, these classes also employ custom handling logic for decoding and encoding the given meteorological variable (“_decode” and “_encode” functions). The essential information of resolved values is defined as classes for all individual code tables, which basically function as lookup tables. The module tries to decode as much information as it can, handling invalid codes in malformed reports with warning messages, without crashing. After decoding data, it collects information in a Python dictionary. As per the module documentation, this output contains some commonly seen attributes across various meteorological variables, like the absolute value of the attribute, minimum and maximum limits of a range (e.g., for height of the base of the lowest cloud seen), unit the value is measured in, used code table number, and the code value looked up in said table. This output dictionary is then converted to a JSON-formatted string using the “json” Python module. The returned string is handled by the Pyodide JS API, bringing the variable from the Python environment into the web worker context. Finally, the “postMessage()” method of the worker is called to transfer the decoded data from the worker back to the main thread, as an object type.

As illustrated in Figure 8 on a sample output, the returned object contains easily interpretable data, organized in a clear schema using properties. In its output, for each property, the module also includes the exact code as it was encoded in the SYNOP report, as well as the number of the code table (lookup table) used to interpret the code. This makes debugging easier, as the code tables can be looked up in the WMO document. Several properties consist of subproperties to further particularize data (e.g., property “surface_wind” has two subproperties, direction and speed, for their respective data as objects), while some properties, like cloud cover, genus, and height, are organized into arrays within the core JSON object to distinguish data for the individual cloud layers.

This output object is then further processed by the code responsible for assembling the station model symbol, discussed in Section 2.1.2.

2.1.2. Station Model Symbol Assembly

Once a SYNOP report is decoded and ready to be processed, the module continues with the main component, which assembles the station model symbol for a station point feature. The developed module is designed so that the generated symbol(s) conform to the given requirements and rules. This workflow adheres to Attachment IV of Volume I.1 of the WMO-No. 306 “Manual on Codes” document, implementing as many prescribed rules as possible for the graphical representation.

For each point feature with successfully decoded SYNOP data, a base SVG element is created with a blank canvas. Within this base element, 26 cells are created, each as a “group” type within the SVG namespace, representing the subelements of the station model. As shown in Figure 9, these groups are positioned in a 5 × 5 grid-like structure (with an extra, optional element at the bottom) that conforms to, and is a formalized interpretation of, the standard defined by the WMO document, which requires the elements to be placed in their respective relative positions. To have proper relative positioning, the module makes sure all cells, subelements, and their contents are positioned correctly. To generate the content of each cell in the grid structure, a refined set of code logic is used. As the plotting of every subelement requires a unique set of rules (e.g., some cells can contain two symbols at the same time, in some cases), the cells are numbered 0–25 in code, so precise handling of each can be performed on a case-by-case basis. Some cells do not have predefined content in the WMO standard, such as, for example, cells 4, 5, 9, 15, 20, and 24. The standard also allows any of the elements to be omitted if the data is not available or if the plotter chooses not to include a specific element. For the underlying visualization method and inclusion in the station model symbol itself, the subelements are either symbols, displaying a symbol for the appropriate code figures (e.g., cloud type or weather symbols), or numerical types, showing raw or pre-formatted values (e.g., temperature, pressure, or visibility).

Out of all cells, the central cell (12 in Figure 9, left) is one of the more complex cells to generate content for. In addition to indicating the spatial reference with the central station circle (location of the station where the weather observation report originates from), it also indicates multiple other variables at the same time, with content overflowing into adjacent cells. Firstly, the empty, partial, or full fill of the central circle indicates total cloud cover in oktas, representing the fraction of the sky covered by clouds. Secondly, true wind direction is indicated by the wind shaft pointing to the direction the wind is blowing from. In the station model, this shaft is connected to the central circle, as defined by the WMO document: “The wind shaft in black is directed along the axis of the wind towards the center of the station circle and stops at its circumference.” [6] (p. 442). Thirdly, wind speed is indicated by the barbs and pennants attached to the end of the wind shaft. Moreover, the side on which the barbs and pennants must lie depends on the hemisphere where the observation was made: on the left of the wind shaft when indicating an observation made in the northern hemisphere and on the right for southern hemisphere observations. Calm wind is indicated by a circle around the station circle with no fill. In this case, the wind shaft is not drawn. In cases when the wind speed is missing, a cross symbol “x” appears at the end of the wind shaft instead of barbs and pennants, while direction can still be indicated if data is available. If the wind direction data is missing, wind is not plotted in the station model at all. Furthermore, if the station where the observation was made is an automatic weather station, an equilateral triangle symbol should be plotted around the central circle, pointing towards the position of the medium cloud symbol (C_M).

Content cells plotting symbols, for example, cells 2, 7, 11, 14, and 18, are inserted into the main SVG element as SVG directly. These individual SVG sub-symbols are looked up from the WorldWeatherSymbols pack based on the code number of the given property and are retrieved from the web server through HTTP requests. Since this symbol pack is included with the station model JS module, these sub-symbols can be served from the server directly, wherever the page is hosted. This approach minimizes the required bandwidth and makes sure that the client only receives symbols that are needed for the current visualization, instead of having to transfer the whole symbol pack to the client. This way, the client-side browser can also utilize its local cache for loading cached sub-symbols that have already been used and plotted in a symbol for a different feature, rapidly.

Content cells displaying numerical values, for example, cells 6, 8, 10, 13, are either pre-formatted as per rules or shown as-is. For instance, cell number 8 indicates pressure at mean sea level (PPPP or a₃hhh code groups). According to the WMO document, this value is plotted in tenths of a hectopascal, while omitting the thousands digit of the hectopascal pressure value (i.e., 1013.4 hPa is plotted as 134, while 998.7 hPa is plotted as 987). This requires code logic for processing and formatting the value to be plotted accordingly. Some elements, like horizontal visibility at surface (VV code group, cell 10 in the station model), are plotted with code figures directly, and therefore, they do not need any formatting and can be used directly as raw values from the SYNOP report.

There are some cells that require more complex, rule-based logic to be implemented. For instance, cell number 18 is intended for indicating past weather (code groups W₁W₂ or W_a1W_a2), and based on data availability, it can also be plotted by one or two symbols at the same time. If there is only one of the two available, the symbol is centered within its designated position cell, but in the case of two symbols, they must be shifted along the X axis accordingly. The process must make sure that these two symbols are positioned correctly and minimize overlapping them with each other and the content of neighbouring cells. Another example for a more complex implementation is for cell number 17, which indicates both the low cloud type (C_L), cloud amount (N_h), and height above surface of the base of the lowest cloud seen (h or hh), based on data availability. The module needs to plot both types at the same time: a symbol and two numerical values, all positioned according to the rules. Low cloud type is represented with a symbol, but cloud amount is given and plotted in oktas, while cloud base height is codified (requires a lookup of code Table 1600). Also, the document defines the code figure for N_h to be entered to the right of the position of C_L, while the code for cloud base height must be plotted below the position of the C_L symbol.

After evaluating and creating all subelements properly, the module finishes by returning the final, assembled station model SVG symbol, which is ready to be plotted on a map. Due to their vector format, the assembled station model symbols can easily be scaled on demand, keeping the relative positions and sizes for both symbols and numerical values the same upon scaling. This also applies to the font size of the numerical values within the final symbol.

2.1.3. Wrapper Module

The wrapper module provides an abstraction layer for the two main components. Its main function is called by a GeoJSON iterator (e.g., “L.geoJSON().eachLayer()” in Leaflet, or equivalent), that provides feature attributes and geometry, along with some customizable, user-defined options for the module itself. The point geometries are necessary for determining the hemisphere the station is located in, as they influence the method of plotting the wind shaft symbol. Similar to the queue data structure used in the worker to temporarily store SYNOP reports to be decoded, the wrapper module maintains a queue array of decoded data and handles them once they are available and ready to be processed by the symbol assembly code. This is necessary due to the asynchronous nature of the SYNOP decoder component. The wrapper module also tracks the feature ID (e.g., the “_leaflet_id” attribute of “layer” in Leaflet, or equivalent), making sure that the decoded data and, therefore, the assembled symbol is matched to the correct feature on the map. Among some helper functions, this wrapper module initializes the web worker for the Pyodide environment, given that the browser supports the Web Workers API. The wrapper module outputs the final SVG, ready to be applied to features on the web map, using “layer.setIcon(L.divIcon(html: stationmodel))” in Leaflet, or the equivalent in other web mapping libraries.

The developed, ready-to-use module, its full API documentation, and examples are available on GitHub: https://github.com/balladaniel/station-model-symbology (accessed on 25 March 2026).

3. Results and Discussion

This section presents the developed solution from a practical perspective. First, the module and its user-facing features, functionality, and customization options are summarized. The section introduction also touches on readability, visual clarity, and usability of the proposed approach. Section 3.1 showcases the final station model output with a few examples. Then, Section 3.2 touches on other elements found on synoptic surface weather charts and their possible integration in web maps, in parallel with the newly generated station models. Finally, Section 3.3 discusses the module’s performance, limitations, potential implementations, and future improvements.

Generating such complex symbols in a web environment is particularly justified by the diverse nature of the way national meteorological services might want to customize and apply their own rules for the graphical representation of their data. Making sure that the output of the module can be refined based on map extent, map scale, station density, subjective needs, and national rules was a primary goal. By producing these symbols using web technologies and standards like cascading style sheets (CSS) and SVG, a custom style (use of unique coloring, custom font and font size, and global symbol scaling) can easily be applied either to specific sub-symbols or the whole symbol. As previously discussed in Section 2.1.2, the module constructs the final SVG symbol in a way that allows for great adaptability. The aforementioned polychromatic method defined by the WMO document can also make good use of the customizability of the module, whether the user wishes to use the polychromatic method. Among other options, the user of the module can also specify a list of elements to be omitted from the final station model symbol, regardless of data availability. Since the WMO standard does permit two different methods of air temperature (TTT) and dew-point temperature plotting (T_dT_dT_d), the user can also choose to show these values in degrees and tenths of a degree Celsius, or in whole degrees Celsius after rounding to the nearest degree. As the output format is SVG, the module can be used in conjunction with the most popular open-source web mapping libraries like Leaflet, OpenLayers, MapLibre GL JS, etc.

Naturally, since the generated symbols are intended to be used on web maps, map readability in the visualization must be addressed, including information clarity at different scales and, therefore, the resulting symbol density. When zooming out such maps to smaller scales, the otherwise large-footprint station model symbols will eventually begin to overlap. While this is affected by factors like spatial data density, target map extent, etc., generally, symbol overlapping should be avoided at all times to ensure legibility. Multiscale mapping is fundamental to web mapping research and development efforts [37]. Generalization operators and processes for multiscale maps were synthesized by [37], including the elimination of features, which was called omission by [38,39] in the previous literature. In the context of the paper, the symbols’ layout and style conform to the WMO standard, and therefore, out of the potential generalization operators, only the usage of the elimination content operator is a viable option. While neither the module’s nor the provided wrappers’ goal is to validate symbol overlap, there are existing solutions for implementing such automatic generalization. When paired with plugins that handle automatic generalization of map features, such as [40] for Leaflet, overlapping symbols can be avoided based on a priority order. To ensure visual clarity, minimum dimensions for symbology are another important aspect. According to the review of [41], authors of the cartographic literature on recommendations for minimum graphical element dimensions on both printed and screen-based maps diverge considerably in the types of symbology and dimensions specified. These dimensions are affected by many factors, including screen size and resolution (and therefore, screen pixel density), an individual map reader’s perception abilities and visual capabilities, etc. As highlighted by [41], “For empirical verification of the legibility of symbols, there are currently no standardized methods and settings established.” However, ref. [42] notes that out of the readability measures (amount of information, spatial distribution, object complexity, and graphical resolution), the amount of information displayed was the most important factor, while graphical resolution itself was not useful to gauge map readability. They also concluded that for evaluating map readability, using a composite of readability measures is better than using single measures. Ref. [41] also formulates an open question on weighing the potential exclusion of users who do not have the required visual capabilities to reliably interpret map information against the responsibilities of map designers to mitigate such exclusions. To address this, the developed module provides two means to the map designer in order to ensure map legibility: global symbol scaling and font scaling for numerical values. On top of this, due to the SVG nature of the symbols, custom CSS styling of the internal elements is also an option. While there are no hardcoded limits for symbol dimensions in the module, its default settings are defined so that it produces a legible map for data with moderate density of spatial distribution (i.e., for maps with information densities similar to those of the provided web map examples in the next section).

Compared to the output produced by the sole, publicly available relevant web map example, the NWS Weather and Hazards Data Viewer, the output of the developed module offers a higher degree of widespread usability by rectifying WMO-compliance-related deficiencies observable on the NWS web map, as discussed in Section 1.1.1. Although the symbols of the mentioned example are vector-based, the underlying method of producing them is undisclosed, while the workflow of the developed module is fully transparent and open-source.

Like the well-established station model symbology, the developed module is primarily intended to be used by professionals (meteorologists). From a cartographic perspective and the aspect of usability/interpretability, arguably one of the most pressing issues for the provided web map examples is the lack of a clear explanation using a legend-like element, which affects non-expert users. However, while concisely and clearly explaining all the variables station models can visualize is not feasible, these web maps could be extended with an appropriate panel element containing some version of a supplementary graphic, like in Figure 1. Even with this approach, assuming map readers to be non-experts, they would have to look up the meaning of individual symbols and codes in the WMO documents. In the end, while this could theoretically be implemented in the module (or rather the library-specific wrappers of the module), the scope of the work remained on generating the SVG symbols in an effective and precise way.

3.1. Output Showcase

This section showcases the generated output and demonstrates its use on example web maps, created based on sample datasets containing actual real-world measurements and observations. Figure 10 shows three examples of final, assembled station model symbols based on illustrative test data. This example uses the polychromatic plotting method, which permits some elements to be colored. Here, the symbols for high clouds (C_H), decreasing characteristic of pressure tendency (a), and past weather (W₁W₂) are colored red.

The following examples are web maps based on Leaflet v1.9.4, created with the developed module. They contain multiple station model symbols, representing the observations at each station on the ground. The sample datasets used for the following demonstrations were obtained from Ogimet (https://www.ogimet.com/). Ogimet is a widely used, free repository for meteorological data, collected from the institution in the source country. The free web service provides data such as SYNOP, METAR, terminal aerodrome forecasts (TAF), and pilot reports (PIREP). The usage of the codified meteorological reports available on the web service is regulated by WMO resolution 40, which allows free and unrestricted access to internationally exchanged, essential meteorological data [43]. For all web map examples, the SYNOP data from Ogimet was manually retrieved and transformed into a GeoJSON file as an attribute for point features, representing the locations of the respective weather stations. The examples use a compilation of meteorological data retrieved from Ogimet, for the given timestamp (if available), provided by individual national meteorological services and institutes across Europe. The web map examples can be found on the GitHub project page.

In Figure 11 and Figure 12, surface weather observations for Hungary are presented on a web map, utilizing the developed module to dynamically generate symbology. The two maps visualize data for two specific points in time, 6 September 2025 06 UTC and 17 December 2025 14 UTC, respectively.

Figure 13 showcases a similar example for a compilation of surface weather observations made in Europe on 21 September 2025, 12 UTC.

3.2. Other Elements of Surface Weather Charts

To produce a complete web map that implements a symbology equivalent to the existing synoptic weather charts both visually and data-wise, in addition to the station model plots, other elements should also be implemented. As pointed out earlier in the study, providing a solution for generating these other specialized elements is not part of the scope for this research. For visualization of line features (e.g., front lines), applying styles (or SVG line patterns) to line features is possible, as this is already implemented and straightforward to use in mature web mapping libraries. For front lines specifically, in addition to line stroke color indicating a hot or cold front, the applied line symbology should also include repeated pip symbols (triangles or semicircles) oriented pointing towards the direction in which the front is moving. The latter is especially important when using the monochromatic plotting method, where color can not indicate the qualitative difference between front lines. The symbol for high/low pressure points can easily be achieved with bold characters H and L as the symbol, appropriately colored blue and red, respectively. Isobars, connecting places of equal atmospheric pressure, represented by either lines or polygons, can also be easily styled with a library like Leaflet by applying the appropriate style for a feature in code. For Leaflet specifically, the plugin “leaflet-isolines” can generate isolines based on an array of points in the format [[lat, lng, value], …]. That plugin uses Turf.js in a web worker instance to speed up the calculation [44]. The National Forecast Chart of the NOAA WPC is an interactive, Leaflet-based map that employs vector-based symbology for front-line and high/low pressure point visualization, in a custom implementation [45]. As seen in example [46], with some custom code, the aforementioned MetPy Python library can also generate front lines (warm, cold, occluded, and stationary), pressure points, and isobar lines, although these are accomplished in a desktop, not in a web environment.

3.3. Performance, Limitations, and Potential Further Optimizations

With the newly developed JavaScript module, there are some aspects in terms of performance and limitations that should be noted and discussed. The main concern about the module performance is the technical need to use Pyodide to be able to run Python code and, ultimately, use the Pymetdecoder for decoding SYNOP reports. At the time of conducting this research, we were unable to identify a suitable library written in native JavaScript that decoded SYNOP reports. It is evident that ruling out the need for a Python environment would be the most performant and elegant solution, as the data could be handled in a native format all throughout the workflow. Another negative aspect is the size of the dependencies, which have to be transferred to the client. While Pyodide 0.29.0 used by the current workflow is only 7.8 KB of JavaScript, the subsequently loaded components of Pyodide, namely the Python Standard Library and the WebAssembly half of the main binary code, are 2.4 and 2.7 MB in size, respectively. This means that 5.1 MB of data has to be transferred to the client on every page load, solely for the initialization of the Python environment in the browser. In addition, the initialization overhead of Pyodide also took around 2–2.3 s in the development and test environment (AMD Ryzen 7 5700X3D, 16 GB DDR4-3200 RAM). On computationally weaker computers, this might take even longer. After the initial startup of Pyodide, the decoding of individual SYNOP reports is rapid: they are done in 1–2 ms each. While assembling the symbol for a single feature is quick, porting the symbol assembly code logic from the client to the server could potentially be a more straightforward and optimized approach, depending on specific needs in larger-scale implementations. By decoding SYNOP reports and generating symbols on the server-side (running Python code, running JS in Node.js), only the final SVG symbols for the point features would have to be transferred to the client, saving on the number of requests. Contextualizing the performance of the developed method relative to existing approaches is less feasible due to the absence of established approaches that would address the same problem in the same technical context.

As the wind shaft of the station model represents true wind direction, one has to keep the potential angular distortion in mind when using a custom projection for the visualization. Generally speaking, the Web Mercator cylindrical projection (EPSG:3857) is the de facto standard for web mapping purposes. While this projection is not conformal, it only has minor angular distortions and is usable at a global scale. This also means that North is kept quasi-upwards in the whole map extent, regardless of latitude and longitude. This is not a problem when using Web Mercator, especially for global scales. However, using conformal projections with curved lines of latitude is common in meteorology (e.g., polar stereographic, Lambert conformal conic), and therefore, the wind shaft direction should be adjusted appropriately, based on the angular distortion and location. The module could potentially have an optional parameter for defining the projection formula, based on which the module could calculate the angular distortion at a specific location and adjust the wind shaft symbol accordingly.

All things considered, in order to further strengthen scalability and interoperability with modern meteorological data workflows, future research should focus on exploring native JavaScript decoders for SYNOP reports and support for BUFR format. BUFR was introduced by the WMO to unify the many character-based alphanumeric standards, like SYNOP, TEMP, and CLIMAT. BUFR is defined in Volume I.2 (parts B and C) of the WMO-No. 306 document [47]. Thanks to the module structure, swapping the data decoding workflow should be straightforward for both making it native and providing support for BUFR. Future studies should also explore potential server-side alternatives and projection-related issues, especially regarding the wind shaft direction, and they should conduct systematic testing across various data volumes on various devices.

4. Conclusions

Thematic cartography is a fundamental part of conveying scientific results in earth sciences. In meteorology, among maps utilizing specialized symbology, one type is the surface weather chart. On this map, surface observations are represented with a complex, multi-element symbol called the station model. This symbol effectively communicates multiple meteorological variables simultaneously, presenting a wide range of data to the map reader. While the station model was utilized on hand-plotted weather maps since the 1920s, the usage of such maps began to decline in the 1960s, which also led to the recent disappearance of such symbology. Although digital static maps showcasing various meteorological variables with isopleths, raster layers, and wind arrows are common, maps containing station model symbols are scarce on the web. In this work, examples of web maps utilizing station model symbols were collected. Most of such examples were static raster maps transferred directly to the client. Some examples were interactive, leveraging web mapping libraries, but the actual data layer was loaded as pre-rendered tiles or raster layers, not enabling any client-side alteration of the symbology and ruling out the possibility of dynamically updating the visualization based on remotely updated data. Narrowing down to interactive web maps implementing elements that resemble the station model as vector graphics, only a limited number of examples were found. Although one of the original intentions of introducing common symbology was one of the ways to improve communication among meteorologists of various nations around the world, currently, individual organizations employ station models on their maps to varying degrees, and the displayed examples reveal a lack of uniformity in symbology. Furthermore, existing capabilities for generating station model symbols were studied, most of which were implemented in desktop GIS software. In web GIS, no such capability has been identified. Therefore, a lack of an open-source, web-compatible solution for implementing vector-based station models on web maps can be observed. Recent cartographic literature has not focused on station model symbols and visualization of weather observations, particularly not in a modern, interactive web map environment. This gap in the literature highlights the relevance of this study, which contributes to a specific, relatively unexplored domain in cartography and especially in web GIS.

This study presents an open-source JavaScript module that can generate WMO-compliant station model symbols in SVG vector format on the client-side, which eases the creation and publishing of synoptic surface weather charts in web environments. The introduced module makes use of the Web Workers API and handles both SYNOP data decoding and dynamic generation of symbols, offering a streamlined and customizable experience. Its output is compatible with popular web mapping libraries, like Leaflet and OpenLayers. Due to its client-sided nature, the module can also easily be implemented in a dynamically updated server–client architecture. To address aspects like visual clarity, symbology legibility, and the potential exclusion of users who do not have the required visual capabilities to interpret such dense symbols, the developed module provides two means to the map designer: global symbol scaling and font scaling for numerical values. With well-defined defaults, the station models produced by the module remain legible on maps with a moderate density of spatial distribution. A brief discussion is given on the module’s performance, limitations, and possible further optimizations. After the initialization of the Pyodide environment in 2–2.3 s on the client-side, the module decodes individual SYNOP reports and assembles their respective station model symbols in 1–2 ms. In the future, the primary improvement with the greatest benefits in performance would be utilizing a native JS library to decode SYNOP reports, as such a library was not available at the time of conducting the study. This discussion also touched on adjusting the wind shaft symbol to support commonly used conformal projections with curved lines of latitude to keep true direction. It also mentioned the potential benefits of generating station model symbols entirely on the server-side instead, and supporting the modern, binary BUFR format as data input in the future.

The developed, highly customizable module could benefit professionals in meteorology, with limited or a lack of web development and web GIS knowledge. It intends to help with the easy representation of surface weather observation data on web maps, hopefully increasing the availability of such interactive thematic maps on the web in the future. This work could also serve as an illustrative case study for implementing other highly specialized and multivariate data-encoded symbology used in maps of geosciences to be realized in web environments.