IMPROVED REAL-TIME WEATHER FORECASTING SYSTEM 1 Cross Reference to Related U.S. Patents & Patent Applications

[0001] The present application claims priority from provisional U.S. Patent Application Serial No.

62/609096 (Docket No. CLI-004PR) filed December 21, 2017, which is incorporated herein by reference in its entirety and for all purposes. [0002] The present application also claims priority from non-provisional U.S. Patent Application Serial No. US 16/181137 (Docket No.6748-10) filed November 5, 2018 and non-provisional U.S. Patent Application Serial No. US 16/181148 (Docket No.6748-11) filed November 5, 2018 both of which are incorporated herein by reference in their entirety and for all purposes. 2 Copyright Notice

[0003] A portion of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice shall apply to this document: Copyright © 2017-2018, ClimaCell, Inc. 3 Background 3.1 Field

[0004] The exemplary, illustrative, technology herein relates to systems, software, and methods for the determination of current weather phenomena and the generation of accurate weather and precipitation forecasts, including analysis and prediction of weather based on real-time, high collection rate, and historical sensor reading, microwave network attenuation, and weather events, using automated means of collecting and pipeline processing of the information in accordance with the descriptions provided herein. The technology herein has applications in the areas of signal processing, parallel processing techniques, satellite network operations, transportation operations planning, and precipitation forecasting. 3.2 Related Art

[0005] Radio signal propagation, and in particular, radio signal attenuation, has been associated with weather phenomena for many years. In past decades, attempts have been made to correlate weather and signal attenuation and, more recently, to predict future weather based upon this information. The approaches to date have encountered obstacles. [0006] It is well understood that precipitation, and in particular, heavy precipitation, severely

attenuates microwave signals at frequencies above 5 GHz as illustrated in Figure 1. Radars, terrestrial microwave links, and satellite uplink/downlink signals typically operate in this frequency range and are affected by this attenuation. [0007] Fog events can have notable negative impacts on industry and safety, for example by

impairing visibility at airports, thereby making takeoffs and landings difficult or impossible and causing flight cancellations and delays. Fog events impair visibility on surface roadways, causing surface transportation delays and contributing to motor vehicle accidents. Fog also negatively impacts water-borne shipping and transport. Given the significant impact that fog can have, the known art has attempted to both detect and predict fog events and to quantify potential impacts of fog on visibility, for example fog impacts on transportation systems as exemplified by existing optical runway visible range (RVR) systems deployed at airport locations. Methods in the known art typically detect fog events by direct observation, relying on dedicated fog detection or visibility measurement instruments or on reports from human observers. These known methods are capable of detecting fog where observers and dedicated instruments are located but fail to detect or predict fog beyond an effective instrument or observer range. [0008] The known art has recognized that fog can affect radio frequency (RF) attenuation and models and algorithms have been developed for inferring the presence of fog and estimating liquid water content (LWC) of fog based on measured RF attenuation. Known fog detection systems are limited in their ability to accurately detect fog, and to determine fog-dependent changes in visibility, at locations outside the range of direct observation. [0009] Models and algorithms have been developed for inferring and forecasting fog and for

estimating liquid water content (LWC) of fog. These models and algorithms previously have been incapable of determining whether particular attenuation measurements are caused by fog or by some other type of hydrometer or atmospheric interference. Fog predictive models using machine learning and other predictive modeling techniques have been used to predict fog by ingesting weather parameter measurements or estimates into fog predictive models that have been trained with historic weather data. Fog predictive models have not previously been combined with or incorporated into dynamic, real time, fog inference and LWC estimation based on microwave link attenuation measurements. [0010] Previous weather forecasting systems based upon RF link attenuation are known, but do not support the processing of RF attenuation from static and dynamically changing satellite-based microwave links. In particular, the use of satellite microwave links for both geostationary and low earth orbit satellites is not well understood. The current computational load for calculating the orbital mechanics of dynamically changing earth station– satellite microwave link paths, and the calculations required to reduce this information into usable weather data have not been feasible for short term forecasting needs due to computational loads. [0011] Weather information systems that use terrestrial microwave links are known in the art, as are specific satellite uplink/downlink processing techniques. The current systems do not integrate terrestrial microwave with satellite link microwave in order to gain forecasting accuracy from the increased coverage, nor do they use pipelining techniques to optimize the complex calculations inherent in processing these types of signals. As such, the geographic coverage of combinations of terrestrial microwave links and satellite link weather prediction systems is limited. [0012] Typically, the temporal accuracy of existing weather forecasting systems is approximately 20 minutes, causing low fidelity forecasts that cannot take into account more timely or accurate data collected from vehicles and other high collection rate data sources. Known weather information systems are limited in their ability to process and integrate high sampling frequency data, such as information collected from onboard sensors of millions of vehicles at collection intervals measured in seconds. These large volumes of data overwhelm computational models using the often low precision, high collection rate data. Additionally, prior art approaches collectively demonstrate notable deficiencies when applied to input data that require complex processing in order to transform the data into usable weather data or to input data when incorporating high sampling frequency sensor readings. First, they are hindcast model development techniques, which provide, by definition, a forecast after the event has happened. They are also limited with respect to the data sources used, as these data sources have built in inaccuracies, and are based upon unchanging data sources. Also, current forecasting systems are unable to keep up with the large data rates that can be collected from these high collection rate data sources, causing the forecasting systems to slow down either during data collection as large number of input data points are collected and processes, or during the forecast calculation when millions of real time data points are being applied to the forecast models. Accordingly, they are non-generalizable and are insufficient to support real- time analysis and prediction of weather-related phenomena. [0013] Rapidly changing weather phenomena, including fog and squall lines, disproportionally effect transportation systems due to the transportation systems reliance upon known weather in operational planning. The situation is particularly acute in aviation, where aircraft are moving at hundreds of miles per hour for a destination that may or may not be accessible due to weather conditions at the destination. Weather forecasts that lag real time or are not rapidly updated when the weather rapidly changes further this disruption. Taken together, these challenges mean that existing systems fail from an information handling perspective in their ability to provide real-time prediction of precipitation amounts. What is needed are forecasts that are updated on the order of minutes, if not seconds. [0014] Taken together, these challenges mean that existing systems fail from an information

handling perspective in their ability to provide comprehensive real-time prediction of precipitation types and amounts for classes of inputs include hydrid and satellite microwave link networks and high sampling frequency inputs, and making that information and forecasts derived from that information available in real time for use in weather forecasting. The prior art approaches collectively demonstrate notable deficiencies when applied to current and planned microwave-based network topologies or inputs that use high collection rate weather data sensor readings. New methods of collecting and processing information are needed in order to produce the desired real-time analysis and prediction capabilities. 4 Summary

[0015] In some embodiments, the rate of cadence processing is reduced so that cadence intervals are very short, e.g. less than 5 minutes, less than a minute down, or less than 15 seconds, depending upon the granularity and frequency of collected sensor and microwave link data. [0016] Non-limiting aspects of the technology herein include: [0017] A computerized method of calculating location-specific weather data, the computerized method characterized by: [0018] receiving, by a communications interface in electronic communication with a first data source via at least one radio frequency link, radio frequency link data including a signal level measurement and at least one location identifier or link identifier; [0019] pre-processing the radio frequency link data, thereby producing pre-processed radio

frequency link data having an extracted level measurement corresponding to the signal level measurement and an extracted location corresponding to the at least one location identifier or link identifier; [0020] providing the pre-processed radio frequency link data to a first data store, the first data store storing the pre-processed radio frequency link data; and [0021] processing, on a schedule, the pre-processed radio frequency link data using a predefined data transform, the predefined data transform calculating first location-specific weather data based on the pre-processed radio frequency link data, [0022] wherein pre-processing of the radio frequency link data and processing of the pre- processed radio frequency link data include associating the pre-processed radio frequency link data with a cadence instance Mi of a cadence cycle, the cadence cycle having a time delay between cadence instances.

[0023] The method above wherein the at least one radio frequency link comprises a terrestrial microwave link.

[0024] The method above wherein the at least one radio frequency link comprises a satellite link.

[0025] The method above wherein the at least one radio frequency link comprises a satellite link.

[0026] The method above further characterized by:

[0027] receiving first location-specific weather data;

[0028] receiving from a second data source, second location-specific weather data;

[0029] storing the second location-specific weather data; and

[0030] processing the first location-specific weather data and the second location-specific weather data to produce blended weather data.

[0031] The method above wherein the blended weather data includes at least a precipitation

intensity for a plurality of tiles, each tile corresponding to a geographic region.

[0032] The method above further characterized by:

[0033] receiving the blended weather data; and

[0034] processing the blended weather data to produce processed blended weather data usable by an on-demand information product.

[0035] The method above wherein the processed blended weather data includes map data usable to display a map on a viewing device.

[0036] The method above wherein the on-demand information product comprises a real-time precipitation map. [0037] The method above further characterized by producing forecast data based on the blended weather data.

[0038] The method above further characterized by:

[0039] receiving the first forecast weather data;

[0040] producing, based on the first forecast weather data, second forecast weather data; and

[0041] storing the second forecast weather data.

[0042] The method above further characterized by calculating forecast weather data based upon the blended weather data.

[0043] The method above wherein the radio frequency link data comprises terrestrial wireless network data including wireless network topology information and wireless link information.

[0044] The method of above wherein processing of the pre-processed radio frequency link data is successively performed for multiple cadence instances of the cadence cycle.

[0045] The method above wherein the time delay is less than five minutes.

[0046] The method above wherein the time delay is less than fifteen minutes.

[0047] The method above wherein storing of the pre-processed radio frequency link data occurs successively for multiple cadence instances of the cadence cycle.

[0048] The method of above wherein each cadence instance includes one or more tile layers, at least one tile layer representing pre-processed radio frequency link data.

[0049] The method above further characterized by:

[0050] receiving the first location-specific weather data;

[0051] calculating forecast weather data based upon the first location-specific weather data; and

[0052] storing the forecast weather data. [0053] A computerized system for calculating location-specific weather data, the computerized system characterized by: [0054] at least one processor configured to receive radio frequency link data including a signal level measurement and at least one location identifier or link identifier, the at least one processor pre-processing the radio frequency link data to create pre-processed radio frequency link data having an extracted level measurement corresponding to the signal level measurement and an extracted location corresponding to the at least one location identifier or link identifier; [0055] the at least one processor being further configured to process the pre-processed radio

frequency link data using a predefined data transform, the predefined data transform calculating first location-specific weather data based on the pre-processed radio frequency link data, [0056] wherein pre-processing of the radio frequency link data and processing of the preprocessed radio frequency link data include associating the pre-processed radio frequency link data with a cadence instance Mi of a cadence cycle, the cadence cycle having a time delay between cadence instances. [0057] The system above wherein the at least one processor is further configured to receive the first location-specific weather data and second location-specific weather data and process the first and second location-specific weather data to produce blended weather data. [0058] A method of reducing computational requirements of calculating complex satellite to earth station geometries characterized by: [0059] pre-computing at least some of the calculations, and [0060] reducing the complexity of the calculations by using pro forma microwave link endpoint locations, which enables the use of pre-computed pro forma microwave links, which in turn permit the use of pre-calculated transforms that include satellite to earth station geometries. [0061] The method above wherein the pro forma microwave link endpoint locations include pro forma satellite and ground station locations. [0062] The method above wherein the pro forma microwave link endpoint locations comprise terrestrial satellite mast locations and mobile microwave link endpoint locations. [0063] A high speed weather forecasting system configured to produce transportation forecasts, characterized by: [0064] a data collector that provides at least one of (a) signal attenuation-based weather data and [0065] (b) high collection rate weather data, organized by cadence, [0066] at least one processor connected to receive the provided data, the at least one processor being configured to: [0067] identify a location of interest, [0068] produce a new transportation forecast for the identified location of interest at least in part based upon at least one of the received (a) signal attenuation-based weather data and [0069] (b) high collection rate weather data, organized by cadence, and [0070] make the new transportation forecast of weather data available for use using a publishing operation. [0071] The system above, wherein the transportation forecast includes weather data specific to aviation uses. [0072] The system above, wherein the weather data includes an RVR calculation for the identified location. [0073] The system above further including the processor identifying a further location of interest, producing a new transportation forecast for the identified further location of interest at least in part based upon at least one of the received (a) signal attenuation-based weather data and [0074] (b) high collection rate weather data, organized by cadence, and making the new transportation forecast of weather data available for use using a further publishing operation. [0075] The system above wherein the at least one processor is further configured to infer fog based on weather parameter estimates calculated from microwave attenuation measurements. [0076] The system above wherein the at least one processor infers a presence of fog by inferring that a measured microwave link attenuation is due to one or more microwave links passing through a portion of the atmosphere that includes fog. [0077] The system above wherein the at least one processor is further configured to estimate a fog liquid water content (LWC) indicative of the presence of fog at the identified location of interest. [0078] The system above wherein the at least one processor is configured to calculate fog based on a particular attenuation measurement for a particular microwave link or based on microwave link attenuation aggregated from one or more microwave links at a particular geographic location. [0079] The system above wherein the at least one processor is further configured to confirm the inference of fog based upon at least one past weather parameter information. [0080] The system above wherein confirming comprises performing a time series analysis. [0081] The system above wherein confirming comprises using a trained machine learning model. [0082] A high speed weather forecasting method for producing transportation forecasts,

characterized by: [0083] providing at least one of (a) signal attenuation-based weather data and (b) high collection rate weather data, organized by cadence, [0084] identifying a location of interest, [0085] producing a new transportation forecast for the identified location of interest at least in part based upon at least one of the received (a) signal attenuation-based weather data and (b) high collection rate weather data, organized by cadence, and [0086] making the new transportation forecast of weather data available for use using a publishing operation. [0087] The method above, wherein the transportation forecast includes weather data specific to aviation uses. [0088] The method above, wherein the weather data includes an RVR calculation for the identified location. [0089] The method above further including identifying a further location of interest, producing a new transportation forecast for the identified further location of interest at least in part based upon at least one of the received (a) signal attenuation-based weather data and (b) high collection rate weather data, organized by cadence, and making the new transportation forecast of weather data available for use using a further publishing operation. [0090] The method above further including inferring fog based on weather parameter estimates calculated from microwave attenuation measurements. [0091] The method above further including inferring a presence of fog by inferring that a measured microwave link attenuation is due to one or more microwave links passing through a portion of the atmosphere that includes fog. [0092] The method above further including estimating a fog liquid water content (LWC) indicative of the presence of fog at the identified location of interest. [0093] The method above further including calculating fog based on a particular attenuation

measurement for a particular microwave link or based on microwave link attenuation aggregated from one or more microwave links at a particular geographic location. [0094] The system above further including confirming the inference of fog based upon at least one past weather parameter information. [0095] The system above wherein confirming comprises performing a time series analysis. [0096] The system above wherein confirming comprises using a trained machine learning model. [0097] A high speed weather forecasting system configured to produce rapid forecasts,

characterized by: [0098] a data collector that provides at least one of (a) signal attenuation-based weather data and [0099] (b) high collection rate weather data, organized by cadence, [00100] at least one processor connected to receive the provided data, the at least one processor being configured to: [00101] identify a location of interest, [00102] produce a new forecast for the identified location of interest at least in part based upon at least one of the received (a) signal attenuation-based weather data and [00103] (b) high collection rate weather data, organized by cadence, and [00104] make the new forecast of weather data available for use using a publishing operation. [00105] 4A high speed weather forecasting system as above, where the calculation of a specific cadence forecast is performed based upon the newly collected data and only the portions of the forecast effected by the newly collected data are updated. [00106] A high speed weather forecasting system as above, wherein the time required to update a forecast is < 5 minutes. [00107] A high speed weather forecasting system as above, wherein the time required to update a forecast is < 1 minutes. [00108] A high speed weather forecasting system as above, wherein the time required to update a forecast is < 15 seconds. [00109] A high speed weather forecasting system as above, wherein the accuracy of the collected high collection rate weather data. [00110] A computerized method of calculating location-specific weather data, the computerized method characterized by: [00111] receiving, by a communications interface in electronic communication with a first data source via at least one radio frequency link, radio frequency link data including a signal level measurement and at least one location identifier or link identifier; [00112] pre-processing the radio frequency link data, thereby producing pre-processed radio

frequency link data having an extracted level measurement corresponding to the signal level measurement and an extracted location corresponding to the at least one location identifier or link identifier; [00113] providing the pre-processed radio frequency link data to a first data store, the first data store storing the pre-processed radio frequency link data; and [00114] processing, on a schedule, the pre-processed radio frequency link data using a predefined data transform, the predefined data transform calculating first location-specific weather data based on the pre-processed radio frequency link data, [00115] wherein pre-processing of the radio frequency link data and processing of the preprocessed radio frequency link data include associating the pre-processed radio frequency link data with a cadence instance Mi of a cadence cycle, the cadence cycle having a time delay between cadence instances. [00116] The system as above, wherein the pre-processing of the radio frequency link data includes processing link data from both satellite and terrestrial microwave networks. [00117] The system as above, wherein the pre-processing of the radio frequency link data includes breaking at least one link into sections corresponding to altitude, at least one section terminating at the 0 degree C stratum of the atmosphere. 5 Brief Description of the Drawings

[00118] The features of the present technology will best be understood from a detailed description of the technology and example embodiments thereof selected for the purposes of illustration and shown in the accompanying drawings in which: [00119] Figure 1 illustrates microwave signal attenuation as a function of frequency and

atmospheric moisture. [00120] Figure 2 depicts an exemplary systems diagram of a computing apparatus supporting aspects of the described system, according to an illustrative embodiment. [00121] Figure 3 depicts an illustrative exemplary computer server that supports the described system, according to an illustrative embodiment. [00122] Figure 4 illustrates cadence cycle processing timing, according to an illustrative

embodiment. [00123] Figure 5 illustrates an exemplary improved cadence instance structure, according to an illustrative embodiment. [00124] Figure 6 illustrates data organization of cadence instances after several cadence cycles are processed, according to an illustrative embodiment. [00125] Figure 7 illustrates exemplary information flows during nowcast forecasting, according to an illustrative embodiment. [00126] Figure 8 depicts a process flowchart for an exemplary post-collection forecast blending function, according to an illustrative embodiment. [00127] Figure 9 depicts a perspective view of (one of many) pro forma satellite locations, pro forma satellite links, pro forma satellite link segments, etc. created for one of the satellite/earth station pairs according to an illustrative embodiment. [00128] Figure 10 depicts an illustrative flow chart of an exemplary satellite microwave link snap to grid process for processing satellite microwave signal collected data according to an illustrative embodiment. [00129] Figure 11 depicts a top (plan) view of (one of many) pro forma satellite paths, pro forma satellite locations, pro forma links, etc. created for one of the satellite/earth station pairs according to an illustrative embodiment. [00130] Figure 12 depicts a side (plan) view of a single (of many) pro forma satellite paths, pro forma satellite locations, pro forma links etc. created for one of the satellite/earth station pairs according to an illustrative embodiment. [00131] Figure 13 depicts an illustrative Information collection and normalization server of the described system, according to an illustrative embodiment. [00132] Figure 14 depicts an illustrative offline/background processing server of the described system, according to an illustrative embodiment. [00133] Figure 15 depicts an illustrative flow chart of an exemplary satellite microwave link

transform creation process for building pro forma satellite microwave links and pre- calculating associated filters and transforms according to an illustrative embodiment. [00134] Figure 16 depicts a portion of a satellite microwave network overlapping a portion of a terrestrial microwave network. Both networks are shown overlaying a ground level static microwave grid of grid points according to an illustrative embodiment. [00135] Figure 17 depicts an illustrative flowchart of an exemplary fog transform creation process for building fog transforms, according to an illustrative embodiment. [00136] Figure 18 depicts an illustrative flowchart of an exemplary RVR transform creation process for building RVR transforms, according to an illustrative embodiment. [00137] Figures 19A-C depict illustrative mapping of runways/airports to tiles, according to an illustrative embodiment. [00138] Figure 20 depicts an illustrative modeling and prediction server of the described system, according to an illustrative embodiment. [00139] Figure 21 illustrates an exemplary process flowchart for an exemplary cadence instance recalculation and propagation method for updating the forecast stacks to reflect newly collected data, according to an illustrative embodiment. [00140] Figure 22 depicts a process flowchart for an exemplary post-collection forecast blending function, according to an illustrative embodiment. [00141] Figure 23 depicts an exemplary fog inference method for making fog inference decisions, according to an illustrative embodiment. [00142] Figure 24 depicts an illustrative flow chart of an exemplary method for calculating

microwave precipitation, atmospheric water vapor, and LWC estimates from microwave signal collected data according to an illustrative embodiment. [00143] Figure 25 depicts an illustrative information distribution and alerting server of the described system, according to an illustrative embodiment. [00144] Figure 26 depicts a graphical image of RVR (runway, light, airplane, RVR shown as

distance), according to an illustrative embodiment. [00145] Figure 27 provides an exemplary overview map display indicating user specified locations of interest and detailed display bar for one of the locations of interest, according to an illustrative embodiment. [00146] Figure 28 depicts an illustrative flowchart of an exemplary RVR calculation and forecast report generation method, according to an illustrative embodiment. [00147] Figure 29 provides an illustrative depiction of a dashboard function of the RVR forecasting program (920), according to an illustrative embodiment. 6 Description of Some Embodiments 6.1 Overview

[00148] The systems and methods described herein provide improved mechanisms for collecting and processing information from a diverse suite of sensors and systems, calculating the weather data, including current precipitation, atmospheric water vapor, atmospheric liquid water content, or precipitable water and other rapidly changing atmospheric-based phenomena, for example, the presence and intensity of fog based upon these sensor readings, and predicting future precipitation and atmospheric-based phenomena, and estimating effects of the atmospheric-based phenomena on visibility. An example of this prediction is demonstrated for calculating runway visible range (RVR) estimates and forecasts based on observed and inferred atmospheric-based phenomena. The described system and methods provide improved data collection and augmentation for various types of input data, for faster updates and use of rapidly updated collected data sets, dynamically updated data sets, significant accuracy improvements and improved forecasting accuracy, and real-time projections, and the improved prediction of weather phenomena. [00149] Diverse meteorological phenomena have diverse temporal evolution (e.g., humidity

changes much more slowly than does precipitation intensity). Accordingly the definition of "real time" or“most current data” may depend on the meteorological phenomena being measured and reported.“Real time” meteorology equipment, such as weather radar sensors, provides precipitation maps showing precipitation intensities and locations on a short time interval, e.g., less than a fifteen minute interval, or optionally less than a five minute interval, or optionally a one minute interval or thereabouts. [00150] The system provides improvements over traditional linear processing systems, which break down as data volumes grow and computational complexity increases. These challenges lead to forecasts that substantially lag real time or forecasts performed with lower precision in order to compensation. The described system addresses these problems in several ways. [00151] Pre-computed transforms provide an efficient way to capture and optimize the required computing steps that are performed repeatedly as a single computation, significantly reducing the amount of computation required. For example, by precomputing an attenuation transform for a satellite microwave link network, we are able to calculate the effect of a specific link attenuation value at a number of different map points through which the microwave link travels between a base station or other earth station and the satellite. By combining the complex set of calculations into a single transform, the received attenuation data for a link may be passed through the transform once and precipitation, atmospheric water vapor, and fog-related values for each affected map coordinate obtained from the single calculation. In a similar manner, we are able to pre-compute an attenuation transform through which received attenuation data from a plurality of microwave links, including in some implementations both satellite and terrestrial microwave links, may be passed to obtain, from a single calculation, precipitation, atmospheric liquid water content, and other attenuation-based weather parameter data values, including values based on multiple attenuation measurements at affected map coordinates where microwave links overlap. This type of processing, when combined with the processing architectures described herein, enables the near real-time calculation of weather data and forecast weather data. [00152] The system supports the creation of static and dynamic pre-computed filters, which

eliminate from consideration erroneous or duplicative data from collected data sets. As the computational requirements increase as the number of collected data points increases, these filters provide a mechanism that substantially reduces the computational workload of the system. The system further supports the collection, pipelined processing, and use within forecasts of high collection rate weather sensor data from a plurality of types of weather sensors, such as fixed roadway sensors, and mobile sensors, such as aircraft, drone, vehicle- mounted sensors and mobile or handheld sensing devices. The system further includes processing steps for ongoing accuracy improvement analysis that permit the system to make effective blending selections that integrate one or more measurements of precipitation intensity (and other weather data) in order to improve the accuracy of resulting forecast generated data by between 30 and 70% and to improve forecast speed by more than 95%. This type of processing, when combined with the processing architectures described herein, enables the near real-time calculation of weather data and forecast weather data using high collection rate data. In addition, the system supports the correlation of a first type of“ground truth” weather data with calculated weather data, supporting the automated accuracy improvement of the calculated weather data. [00153] The system described herein supports a dynamically defined network of microwave links, including continually changing microwave link presence, link length, and microwave signal frequency characteristics, with high temporal resolution of microwave link signal attenuation measurements, from a plurality of information sources that asynchronously provide updated microwave signal attenuation measurements and other information to the system. The microwave links supported include terrestrial microwave links (including point-to-point and mobile links), satellite microwave links (for geostationary and LEO satellites), or a combination of these microwave link types. The use of other types of microwave links, particularly those inputs utilizing dynamically defined links, are also anticipated. These microwave link networks are particularly characterized by computational complexity in matching link attenuation to weather phenomena and the large amount of data that they produce. [00154] The system implements a parallel processing pipeline that provides pre-processing of microwave link attributes which support an order of magnitude reduction in the system compute requirements. The pre-processing steps include creating transforms and filters to automate and reduce the computational complexity for the processing steps to convert microwave link collected data into weather data such as precipitation, atmospheric liquid water content, and fog estimates, transforms, and lookup tables that permit static network attenuation analysis to be performed upon dynamically changing microwave link network topologies. [00155] The pre-processing steps also integrate a plurality of types of microwave attenuation-based precipitation estimates, improving on known systems which support only terrestrial microwave links. In particular, the computationally complex problems of calculating microwave-based attenuation-based forecast using a plurality of types of microwave links, and for microwave links where the endpoints are constantly changing, supports a more robust interference field. The result of these calculations is a substantially larger set of precipitation data points, which are used for forecasting. This larger set of data points, in part, has many of the attributes of high collection rate sensor data as described below, and causes many of the same challenges to forecasting systems. [00156] The system further supports the collection and use within forecasts of high collection rate weather sensor data from a plurality of types of weather sensors, such as fixed roadway sensors, and mobile sensors, such as aircraft, drone, vehicle-mounted sensors and mobile or handheld sensing devices. High collection rate data sources produce large amount of data because of their high reporting frequency. [00157] The system also supports the ongoing asynchronous collection of input data, so the forecast modeling cadence is separated from the collection cycles. This permits the asynchronous updates of forecasts with different types and sources of data independent of the forecast cycle. This has the effect of breaking the collection / forecast cycle timing bottleneck, which is particularly acute for high collection rate and large collected data sets. The system further implements a massively parallel forecasting component in order to produce a precipitation (and related weather phenomena) forecast model in near real time for the system users, and to update the forecasting models in real time or near real time with the most recent observation data, thereby improving the ongoing forecasts. [00158] The system implements a parallel processing pipeline that provides for asynchronous pre- processing of input data in ways that support an order of magnitude reduction in the system compute requirements, which in turn supports forecast cycles as short as 1 minute. The pre- processing steps include converting microwave link attenuation measurements) into high confidence precipitation, atmospheric water vapor, atmospheric liquid water content, and fog estimates. [00159] The system as described collects and utilizes processed data generated by weather sensors and information about the weather sensors that generated the processed data in order to rapidly correct and update weather forecasts using real-time weather data collected at high rates of frequency, and use this collected high collection rate weather data to update the weather forecasts generated by the system within one or more cadence instances so as to improve the forecasts generated by the system. High collection frequency data poses several challenges. First, computational complexity increases as the number of data points increase. Second, it is observed that many types of high collection rate collected data tends to cluster geographically, which limits its effects of forecasts. Optimizations to the forecasting mechanism described herein take account of these attributes and support the partial recalculation of forecasts based upon the area of effect of the collected data. [00160] Furthermore, the described systems supports efficiency optimizations in managing

forecasts, and for deriving a second forecast from a first forecast without recalculating the entire forecast. These optimizations can improve the forecast calculation times by up to 95%, reducing a 10 minute forecast cycle to under 30 seconds. This improvement permits near real- time forecast generation. [00161] High frequency forecast updates are most important when forecasts are used in rapidly changing uses, such as aviation, where airplanes are often flying in excess of 500 mph and minute to minute forecast weather condition changes often directly influence operational decisions. In an example aviation forecast usage, the use of the system in forecasting the rapidly changing runway visual range (RVR) is described. The described system determines current and forecast ground level precipitation, atmospheric water vapor, atmospheric liquid water content (LWC), and fog estimates on a granular level on a location-by-location basis, including per airport, per runway, and at RVR sensor locations, and forecasts precipitation, atmospheric water vapor, and fog estimates for various future points in time. The described system uses one or more of these forecast weather parameters (e.g. precipitation, atmospheric water vapor, atmospheric LWC, and fog estimates) to calculate a forecast visibility-based weather parameters at a specific location of interest, for example, RVR estimates for a particular airport. The RVR information is updated in real time as additional high-data rate sensors provide up to the minute collected data to the forecasting system. These forecast visibility estimates can be used by customers, including airports, pilots, passenger airline operators, and air freight operators to make planning and scheduling decisions. [00162] The system as described thus provides significant improvements in the algorithms and processing throughput, as well as providing improvements in accuracy and timeliness of the forecasts and information provided. These and other aspects and advantages will become apparent when the Description below is read in conjunction with the accompanying Drawings. 6.2 Definitions

[00163] The following definitions are used throughout, unless specifically indicated otherwise:

6.3 Exemplary System Architecture

[00164] An illustrative, non-limiting, computing system that implements aspects of the

technology(ies) is structured with four general processing components (exemplary represented as four logical model servers, one per processing component for clarity), based in part upon the nature of the information being processed, and the pipelined manner in which the information is processed in order to enable near real-time determination of the nature of weather conditions of a geographic region and to forecast weather conditions over the geographic region. The logical processing components of the system comprise: [00165] Information collection and data pre-processing, [00166] Offline/background processing, [00167] Modelling and prediction, and [00168] Information distribution and alerting. [00169] This functional organization of components is provided for illustrative purposes; it is

contemplated that other functional organizations may be implemented using the techniques described herein. 6.3.1 Illustrative Computing Architecture

[00170] The four logical servers (e.g., including data processing components), include a first server (including a data processing component) is an information collection and normalization component; a second server (including a data processing component) is an

offline/background processing component; a third server (including a data processing component) is a modelling and prediction component; and a fourth server (including a data processing component), is an information distribution and alerting component. The system as described collects and utilizes weather data sensor information in order to rapidly collect and update weather forecasts using real-time weather data collected at high rates of frequency, and use this collected high collection rate weather data to rapidly correct and update the weather forecasts generated by the system. The system also collect other non-weather data from a variety of data sources and processes this collected non-weather data into weather data, which is then utilized in forecasts generated by the system. This functional organization of components is provided for illustrative purposes; it is contemplated that other functional organizations may be implemented using the techniques described herein. [00171] Figure 2 illustrates, by example, a precipitation modeling and forecasting system (300) comprising four computing servers (310, 330, 360, and 370) performing the data processing tasks appropriate to the server architecture, with each server operating as a different one of the logical processing components. The servers share information directly, or through a system database (320), or external databases (349). The functions of the servers may be combined into fewer servers, or expanded so that there is a plurality of physical servers without deviating from the described system. [00172] Each of the four computing servers (310, 330, 360, and 370) has access to external data sources (340-348) and internal or system data sources from the system database (320) or from databases operating on one or more of the four servers as is required to perform the necessary data collecting, data clean up and pre-processing, precipitation modeling, forecast modeling, forecast generation, or the like. Input and output data is processed and modeled in real time, in a time delayed mode, and in batch mode, respectively, either simultaneously or asynchronously, and shared between system components on various servers using network communications, notifications, messages, common storage, or other means in common use for such purposes. The described architecture segregates programs and processes that have different attributes, including the programs and processes that are periodically performed on a scheduled routine or basis, batch collection and loading of data, computation intensive and parallel processing modeling, and user interface, onto separate servers for purposes of clarity of presentation. Alternatively, or in addition, other processing arrangements may be used to implement the system of the present invention. [00173] A plurality of data inputs or data sources (340-348), having various origins, can be received by the precipitation modeling and forecasting system and a plurality of data and outputs produced and distributed by the precipitation modeling and forecasting system. The precipitation modeling and forecasting system receives the data inputs at various ones of the servers and distributes the data outputs from various ones of the servers in part according to the functionality of each server and in part according to how frequently the data is updated or collected. Accordingly, some data inputs are received and processed in real time, e.g.

processing begins as soon as the data is received and pre-processed (e.g., formatted), while other data inputs are received and/or processed on a scheduled routine (e.g., stored for formatting and processing on a time delayed or batch mode processing schedule). All of the servers and databases are interconnected over a communications network, e.g., a digital network such as a private or public network which may be a local area network (LAN) or a wide area network (WAN). [00174] According to the described technology, each exemplary server may be implemented as an individual computer system, a collection of computer systems, a collection of processors, or the like, either tightly or loosely clustered, a set of interacting computer systems that are not clustered, or other arrangement as deemed appropriate by those with skill in the art.

Computer systems can be implemented using virtual or physical deployments, or by using a combination of these means. In some implementations, the servers may be physically located together, or they may be distributed in remote locations, such as in shared hosting facilities or in virtualized facilities (e.g.“the cloud”). [00175] An exemplary computer server (400) is illustrated in Figure 3. Servers 310, 330, 360, and 370 of Figure 2 have architectures consistent with the exemplary computer server 400. Each exemplary server comprises one or more processors or data processing components (410), operably connected to memories of both persistent (430) and/or transient (440) nature that are used to store information being processed by the system and to additionally store various program instructions (collectively referred to herein as“programs”) (420) that are loaded and executed by the processors in order to perform the process operations described herein. Each of the processors is further operably connected to networking and communications interfaces (450) appropriate to the deployed configuration. Stored within persistent memories of the system may be one or more databases used for the storage of information collected and/or calculated by the servers and read, processed, and written by the processors under control of the program(s). Database 460 is an internal instance of at least a portion of the system database (320). A server may also be operably connected to an external database (470) via one or more network or other interfaces. The external database may be an instance of the system database that is provided on another server, or may be a network connected database that is a commercial or other external source (349). [00176] Persistent memories may include disk, PROM, EEPROM, flash storage, and similar

technologies characterized by their ability to retain their contents between on/off power cycling of the system. Some persistent memories may take the form of a file system for the server, and may be used to store control and operating programs and information that defines the manner in which the server operates, including scheduling of background and foreground processes, as well as periodically performed processes. Persistent memories in the form of Network Attached Storage (NAS) (storage that is accessible over a network interface) may also be used without departing from the scope of the disclosure. Transient memories may include Random Access Memory (RAM) and similar technologies characterized by the contents of the storage not being retained between on/off power cycling of the system. [00177] The network interfaces (450) are operated under control of the processor that they are connected to and the processing instructions contained within the control and operating programs associated with that processor as mentioned above. These interfaces provide a connection to wired and wireless networking products that operably connect the servers, data sources, and network services described herein. [00178] The server supports one or more programs for providing server management information utilizing a web services interface or other dedicated management information reporting systems such as Simple Network Management Protocol (SNMP) for purposes of providing management information useful to report on the operation of the server. For purposes of clarity, each network interface is illustrated as a separate interface, but may be implemented as one or more interfaces if desired. 6.3.1.1 System Database (320)

[00179] The system database (320), as depicted in Figure 2, may include one or more individual databases (e.g. stored on each of the servers of the precipitation modeling and forecasting system (300)), and/or may include a centralized database server, including one or more logical databases, used to store data used to generate precipitation estimates and precipitation forecast models and or maps. The system database may also include an external database server or database service such as a cloud-based data storage service. Individual databases of the system identified throughout this document are part of the system database. These individual logical databases are listed in Table 1 below and are omitted from the drawings for clarity. [00180] One or more databases are stored within at least one persistent memory of the system and are considered as logical parts of the system database. These databases may include local file storage, where the file system comprises the data storage and indexing scheme, a relational database, such as those produced commercially by the Oracle Corporation, or MySQL, an object database, an object relational database, a NOSQL database such as the commercially provided MongoDB, or other database structures such as indexed record structures. The databases may be stored solely within a single persistent memory, or may be stored across one or more persistent memories, or may even be stored in persistent memories on different computers. [00181] The system is illustrated with multiple logical databases for clarity. The system may be deployed using one or more physical databases implemented on one or more servers, for example, server (310, 330, 360, or 370), or may be implemented using clustering techniques so that parts of the data stored in the database is physically stored on two or more servers. In some implementations, the system database or one or more of the logical databases may be implemented on a remote device and accessed over a communications network. [00182] Within system database (320), there are logical databases as listed in Table 1. These logical databases are omitted from the drawings for clarity.

TABLE 1: Logical Databases (within System Database)

[00183] It should be noted that the physical processing and storage system have the data being read and written directly to one or more system databases, and organized within those databases so that the subsequent data access steps are efficient. 6.3.1.2 External Databases (349)

[00184] The system (300) as depicted in Figure 2 may also access and use external databases (349), which are accessed by the information collection and normalization server (310) as appropriate. The information collected by the information collection and normalization server may be processed further by the server, and then written to one or more system databases (320), and the information is then shared with the other servers (330, 360, and 370) in the system, either directly or through the system database(s), for use in various weather related processing steps. 6.4 Cadence 6.4.1 Cadence Cycles and Cadence Instances as Logical Processing Flow and Data Models

[00185] The system described herein operates a cadence cycle, a series of repeating processing steps that perform one or more of the following actions for each iteration: asynchronous collection and filtering of collected data, pre-processing collected data into weather parameter data, generating forecast weather data, and post-forecast processing.. A group of related cadence cycles is called a cadence series. The system manages sequences of cadence instances, one for each cadence cycle of a cadence series that is performed by the system. This is illustrated in Figure 4. The system also provides a series of ad-hoc processing steps related to monitoring the data created as part of these processes and for making created information in a variety of forms. [00186] The data collection and processing for each cadence cycle iteration are represented by a data construct called a cadence instance. Data collection and pre-processing is performed asynchronously to the forecast processing in the cadence cycle, with collected, generated, and processed data being associated with one or more cadence instance(s) at the time the data is written to a system database.. [00187] As the cadence cycle processing progresses and data is generated by one or more programs of the system and stored to the system databases indexed by at least one cadence instance and cadence cycle processing step, the information that is made available by referencing the cadence instance increases. The data that is generated and stored includes collected data, data derived or calculated from the collected data, forecast data generated during the forecast cycles of the cadence instance, and information that is further generated or derived from the forecast data. Collected data, generated data, and forecast generated data are organized by their tile representation in one or more cadence instance tile layer(s). Note that the data management portion of the system expressly supports the addition, modification, and removal of associations, for example, cadence instance and cadence cycle processing step information associations, with data elements stored in the system, as well as the management of one or more sets of these associations. New associations for data elements, or even replacement of previously made associations by new associations with new current, prior, or even future data elements may be made by changing only the associations between cadence instance, cadence cycle processing step, and/or tile layer and one or more data elements. This permits the identification of data elements, addition of new data elements, the deletion of obsolete data elements, the replacement of updated data elements, the movement of data elements from one tile layer to another, the sharing of data elements between two or more tile layers, and the substitution of data elements on an individual, tile layer, or cadence cycle/processing step basis. For example, if a real-time precipitation reading is collected from a weather sensor such as a ground weather station rain gauge in a subsequent cadence cycle, prior forecast calculations may be updated to use the now current weather reading and their nowcast predictions altered to reflect the updates in real time. [00188] For ease of understanding, we refer to a cadence instance by the abbreviation M _i , where (i) is the cadence instance ID. The cadence instance ID can be a unique identifier, or simply a constantly increasing number such as a system clock count or even a monotonically increasing value. In an embodiment, each cadence instance is represented by a cadence instance data structure stored in a system database that serves as a“master control record” for cadence cycle processing. Each cadence instance structure also contains one or more timestamps which identifies (a) when the cadence instance was started, (b) when collection was completed, (c) when each processing step was performed, and (d) when each forecast cycle’s processing was started/completed, and other information useful for tracking and managing the status of a cadence instance. [00189] A cadence instance comprises multiple tile layers, generally one tile layer for each type of data collected during a cadence cycle. A tile layer is a structure for organizing data associated with a cadence instance. Each tile layer has a set of defined characteristics, represented as a series of“tiles.” Tile layers are logically grouped into tile layer stacks, based upon the stage of the cadence cycle that they are created, e.g. a collection data tile stack, a forecast data tile stack, a post-forecast data tile stack. Each tile layer and tile layer stack (and the data comprising those tile layers) includes identifying labels and/or timestamps, as well as an indication of the processing program that created it. The data is tagged with these identifying labels. The cadence timestamp represents the time at which the cadence index was incremented and is used in the cadence cycle process to adjust for collection delays. The forecast timestamp represents the time at which a forecast cycle was started or stopped. [00190] A tile layer is a structure for organizing data associated with a cadence instance. Tile layers may be associated with one or more types of cadence instance data, and are often associated with the collection, forecasting, or post-forecast processing process that created the data, as illustrated in Figure 5. Each tile layer has a set of defined characteristics, represented as a series of“tiles.” Tile layers may be sparse structures, as not all tiles in a tile layer are populated with data. Tiles each roughly correspond to map sections, but are not bound to a particular map or scale. Typically, each tile layer has tiles of a consistent size. In some embodiments, however, a tile layer’s tile sizes are identical. In other embodiments, the tile sizes of diverse tile layers may differ. The processes that access the data associated with a tile layer manage the translation of the tile layer to whatever geographic coordinates are needed. [00191] A tile stack, sometimes more formally called a cadence instance tile stack, is a structure representing a set of one or more logically associated tile layer(s). A tile stack includes one or more tile layer(s) associated with a specific cadence instance, comprising the tile layers associated with the instances collection, forecasting, and processing programs of the system. [00192] The collection data stack is a tile stack associated with the collected data of a cadence instance. The collection data stack includes collected data tile layer(s), which are the organizational representation of collected data, in either raw form, pre-processed form, or post-processed form. The collection data stack Mi includes a collection data tile layer corresponding to each type of weather parameter data generated from collected data during processing, for example the collected data stack Mi includes a tile layer for each type of collected processed data and for each type of generated collected data generated during processing. [00193] The forecast tile stack is a tile stack associated with the forecast information of a cadence instance. The forecast tile stack includes forecast tile layers, which are tile layers comprising data associated with a forecast program. The forecast tile layer is sometimes described by the name of the associated forecast program, e.g. a forecast tile layer associated with an RVR forecasting program is sometimes described as a forecast RVR tile layer and a forecast tile layer associated with a fog forecasting program is sometimes described as a forecast fog tile layer. [00194] The post-forecast processing tile stack is a tile stack associated with post-forecast

processing information of a cadence instance. The post-forecast processing tile stack includes post-forecast processing tile layers, which are tile layers comprising data associated with a post-forecast processing program. A post-forecast tile layer is sometimes described by the name of the associated post-forecast processing program. [00195] An example cadence instance logical structure (2000) is depicted in Figure 5. The cadence instance logical structure illustrates two tile stacks: collection data tile stack Mi (2020) and forecast stack (2030). Other tile stacks, such as the post-forecast processing tile stack and weather product tile stack are not shown for clarity, but have similar structures and tile layers to the collection data and forecast tile stacks. Each tile stack (2020, 2030) includes a set of tile layers (collection tile layers (2021-2025, 2047-2048) and forecast tile layers (2031- 2036)). Tile layers are typically organized by the process that creates them, e.g. a forecast precipitation tile layer (2031) is associated with precipitation forecasting program (915). Alternatively, tile layers may be organized by the presence or absence of one or more specific attributes, by the value or value range of one or more specific attributes, information source or processing steps performed on the data. These alternative organizations are useful for some data representations, for example, to bin multi-dimensional data such as collected weather sensor data binned by geographic location or geographic feature and to associate satellite microwave precipitation and LWC estimates with tile layers organized by altitude. [00196] Each tile layer stack (2020, 2030) includes identifying labels and/or timestamps, as well as an indication of the processing program that created it. The cadence timestamp represents the time at which the cadence index was incremented and is used in the cadence cycle process to adjust for collection delays. The forecast timestamp represents the time at which a forecast cycle was started or stopped. Each collected data stack M _i (2020) includes cadence timestamp (2027), cadence instance number (2028) (i.e. the i of M _i ) and cycle timestamp (2029). Each forecast stack includes forecast cycle timestamp (2039) and is identified by cadence instance (Mi) and forecast cycle number (2037) (i.e. the j of MiFj). [00197] This structure permits the extension of the system by adding additional processing

programs and adding one or more additional tile layer(s) associated with each added additional processing program without changing the data organization of cadence instances. The non-limiting exemplary tile layers (2021-2025 and 2031-2036, 2017=2048) illustrated in Figure 5 are not meant to represent all possible tile layer types usable by the technology disclosed herein. For example collected data stack M _i (2020) can include additional tile layers such as a cloud water content tile layer and a radar reflectivity data tile layer, and forecast stack MiFj (2030) can include additional tile layers such as a LWC forecast tile layer or cloud water content forecast tile layer. Additionally, one or more tile layers illustrated in Figure 5 can be replaced by alternative tile layers. In some cases, a tile layer may be constructed, in whole or in part, from previously collected data instead of current collected data. This may occur when a data source has a very low frequency of collection relative to the cadence frequency, or when the data is of a type that only varies over long time cycles, such as humidity. In these cases, the system may collect new data periodically and each cadence instance created between collections will reference the most recently collected data previously stored. This may be done by associating the previously collected data with an additional cadence ID of the current collection cycle so that the collected data is shared between two or more cadence instances. [00198] Similarly, if it is subsequently determined that aspects of two or more cadence structures (or parts of cadence structures) are functionally identical (or are identical within a defined threshold), the system may“prune” some or all of a duplicate structure by replacing the data from the pruned structure with references to the duplicated data. This reduces the amount of data that must be stored in the system and supports the elimination of additional processing if two or more cadences are producing similar calculated and forecast generated data. Aspects of cadence structures may be compared using tile comparison program (910), as described below. [00199] Each cadence instance comprises one or more of collected data, processed collected data, generated collected data, and forecast generated data. [00200] Collected data comprises information collected from data sources including, for example, ground weather stations, terrestrial and satellite microwave links, and weather sensors.

Collected data is collected by one or more collection processes of the information collection and normalization server (310 of Figure 2) that are in communication with at least one data source and that process the collected data and then store the collected data into one or more data stores (e.g., one or more source specific databases). Collected data may be filtered and transformed in order to produce processed collected data, or used to calculate or derive generated collected data. Collected data is represented as part of one or more cadence instance(s) as a set of one or more collection tile layers, typically with one tile layer per input data source. Each collected data is associated with one or more collection-time current cadence instance(s). Collection processes operate asynchronously and may be

computationally complex, so a plurality of collection processes may be simultaneously operating and writing to individual databases without interfering with each other. The ability to asynchronously collect and process input data from a plurality of sources permits the parallelization of the collection process, greatly reducing the effect of the collection processes on overall cadence cycle times. In addition, because each collection process writes to an individual data type specific database, inter-process contention for database resources is avoided. These selections enable the processing of large amounts of data on an asynchronous basis, and enable part of the performance improvements exhibited by the system when compared to its predecessors. Collected data is associated with a one or more cadence instance(s) using a cadence index value (the (i) of Mi). Making this association is referred to as“tagging”, and the any tile data may be tagged with one or more tags (e.g., cadence instance IDs, tile layer names), and additional tags may be added or removed during subsequent processing. [00201] Processed collected data comprises collected data that is pre-processed using one or more preprocessing programs that may use predefined filters and data transforms in order to speed pre-processing. These predefined filters and data transforms automatically convert the collected data into a format usable by the system (i.e. removing erroneous or invalid data values, converting location information to tile form, either 2D or 3D), and store the data into a database associated with the collection input. This stored data, organized by data type, cadence, and tile layer, comprise the collected data tile stack, and may be referenced as a data type specific collected data tile layer of M _i as described above. Data that is not associated with one or more cadence instances is ignored by the system, and is subsequently removed from the databases by automated or manual processes. [00202] Generated collected data comprises new data derived or calculated from the collected data (such as calculating rainfall from attenuation data) and stored in a system database by one or more programs of the system. [00203] Forecast generated data comprises data generated during the forecast cycles of the cadence instance and stored in a system database. Forecast generated data is typically represented as a set of one or more tile layers (typically one tile layer for each forecast data type, each tile, and each tile layer associated with a timestamp) for each forecast cycle. The timestamp corresponds to increments in the forecast time (e.g. tied to the time of each forecast cycle). Thus, forecast generated data set (and timestamp) F ₀ is the current time at which collection completes for the cadence instance (e.g. the time that the cadence index is incremented), F1 is current time + forecast interval, F2 is current time + 2 * forecast interval, etc.), repeating out to the forecast limit. Forecast limits are tunable for the system; typical values are between 2 - 6 hours for short term, high resolution (NowCast) forecasts, and 1-10 days for long term, lower resolution forecasts. [00204] Processed data comprises data that has been previously associated with a cadence instance and has been further processed by one or more data processing programs of the system, with results of that processing stored in a system database. Processed data may include additional refinements to collected data, derivation of additional information from collected or forecast generated data, or data that is calculated by other systems and associated with one or more cadence instances. A data instance further comprises post-processed data which is data derived from processed data. An example of post-processed data is runway visual range (RVR) or more generally visibility, which is derived from processed data including precipitation, atmospheric water vapor, and fog or liquid water content of the atmosphere. [00205] Cadence instances may use references to previously defined (either forecast or collected) tile layers (or subset of tile layers) to substitute for slow-update collection processes and to speed processing by referencing previously processed data that has not significantly changed. If collected data is not available for a parameter at a location when M _i is populated with data, collected data from older models is used, i.e. from the set bounded by M ₀ through M _(i-1), corresponding to the location. Historical information can include collection tile stack information retrieved from cadence instances that are older than model Mi, or may include information from historical models that correspond to the requested location and time. This form of updating of the forecast to include the most current collected, processed, or post- processed data improves the forecast accuracy by 30-70%. [00206] Cadence instances may include information generated by internal processes, such as

machine learning models that are generated by the modelling and prediction server, and are then used to process collected data and produce new tile layers of data based, at least in part, upon the predictions. For example, For example, trained machine learning model, for example a neural network, may be used to calculate a probability of a forecast event being rain, mist, or fog based upon past historical weather data combined with current collected and forecast generated data. In an exemplary embodiment, the probability of rain, mist, or fog may be used by future processing steps, such as NowCasting and/or RVR calculations to determine the contribution of rain and/or fog to the precipitation and visibility forecasts. [00207] One aspect of the cadence structure is that forecast processing may reference future

collected data and future processed or post-processed data that is part of a future cadence instance. This is useful in two ways; it permits the integration of uncollected or unprocessed data into existing models, and it permits portions of the system to be updated with more recent collected or forecast generated data as it is generated. For example, if a forecast model predicts rain will arrive at a location at 13:00, but a rain gauge records the rain actually arrived at the location at 13:30, the forecast model is clearly inaccurate and may require reprocessing. One way the system handles this is to run a new cadence cycle and generate a new forecast. Alternatively, the updated data may be selectively updated within one or more tile layers, and the forecast models rerun for only the updated data (and any subsequently affected data). [00208] Each cadence instance of a cadence cycle progresses through a series of processing stages, which are partially controlled by timing parameters. Cadence cycle timing (e.g., instance to instance within a cycle, forecast cycle to forecast cycle within an instance, and inter-cadence cycle delay) may vary, based upon the length of time required to complete each stage of processing and the frequency of system data collection activities. The system may also enforce an interstitial delay between cadence cycles if desired. Cadence cycle timing may vary based upon weather or upon the results of one or more previous cadence cycle processing steps. For example, cadence cycle length and collection interval length may be increased during clear weather and decreased during stormy weather. [00209] Several parameters control the processing of the cadence cycle for a cadence series, as described in the table below:

TABLE 2: Cadence Series Processing Control Parameters

[00210] In some embodiments, the cadence cycles execute asynchronously and the cadence

instances are separated by the interstitial delay. In other instances, the cadence instances are performed synchronously, with each cadence instance started at a particular clock interval from a previous cadence instance. [00211] Aspects of a first cadence instance, such as an entire tile layer of the first cadence instance, may be compared to other equivalent aspects of a second cadence instance, and if the aspects are sufficiently similar, the duplicate aspects of the first or second cadence instance may be replaced with a reference to the other aspect. Thus, for example, if a temperature tile layer of a first cadence instance is equivalent to the temperature tile layer of a second cadence instance, the temperature tile layer data references of the second cadence instance may be replaced with references to the temperature tile layer of the first cadence instance (and the second cadence instance data deleted). All or part of a tile layer may be replaced in this manner. Similarly, portions of a first tile layer may be compared to equivalent portions of a second tile layer to determine if they match. If they match, either the first or second portion of the tile layer may be replaced with references to the alternative tile layer. In this way, changes to a tile layer (for example, as would occur by updating with current sensor data, or by reprocessing one or more portions of a forecast) may be immediately identified for further processing without requiring the reprocessing of the entire tile layer. [00212] One method of comparing cadence instance tile layers is to encode all or some of the

respective tile layer(s) into graphical formats and then use image comparison techniques to compare the respective graphical images. The encoding function may encode only those parts of the cadence instance structure, for example, encoding only specific data elements from a tile layer, a region (part) of a tile layer, a complete tile layer, a set of tile layers, or a combination of these. [00213] Figure 4 illustrates an exemplary cadence cycle processing for several cadence instances operating synchronously with a cadence instance start interval of 10 minutes and a forecast cycle time increment of 15 minutes. Each cadence instance includes data collection, initial tile calculation that includes processing of collected data followed by post-processing to calculate generated collected data, such as RVR, from processed data, and forecasting calculation. Cadence cycles may be classified as short or long. Short cadence cycles capture near term weather information and support real time and near real time weather forecasting. Similarly, short cadence cycle start intervals of 1, 2, 5, or 15 minutes, with data collection times of 1, 2, 5, 10, or even 20 minutes, and have interstitial delays of 0, 2, 5, 10, or 15 minutes. Long cadence cycles capture longer term weather information and provide for forecasts and models that typically are several days in duration. Typical long cadence cycles have interstitial delays of 6 hours, 12 hours, 24 hours, or two days for longer cycle cadences. In some cases, the cadence cycles are operated from a clock-based system such a cron on a Unix-based computer, which causes a cadence cycle to start at a specific time of day (e.g.12 noon, 6pm, 7pm, 7:10pm). In an exemplary embodiment, the cadence cycle length may be updated in accordance with other aspects of the forecast which are refined over time. [00214] In some embodiments, the cadence cycle definitions may be altered by a post-processing program based upon the observed and forecast weather phenomena. For example, a rapid cadence cycle is desirable when tracking and forecasting a thunderstorm moving across an geographic area at 30 mph. Alternatively, a longer cadence cycle may be used if the weather phenomena in a geographic area are for clear weather or stratiform cloud layers, as these later conditions cause infrequent changes to the resulting forecast. [00215] After several cadence cycles are completed, the cadence instance may be represented as a grid of collected and forecast tile stacks as illustrated in Figure 6. Since the collected and forecast generated data may be represented as a grid, individual and sets of logically related data elements can be identified as shown in the table below:

TABLE 3: General Processing

[00216] Figure 6 illustrates cadence collection cycle (5000) as a grid of collected and forecast tile stacks. Each column of the grid includes collected and forecast tile stacks of a cadence instance (5010– 5310). Each cadence instance (5010– 5310) includes a collected data stack (5020– 5320), each of which is substantially similar to Collections Data stack (2020) of Figure 5. For example, cadence instance M0 (5010) includes collected data stack M0 (5020) which includes data collection tile layers (e.g.2021– 2025). [00217] Each cadence instance (5010– 5310) includes a forecast stack set (5040– 5340). Each forecast stack set includes one or more forecast stacks M _i F _j , each of which is substantially similar to forecast stack (2030) and each of which includes one or more forecast tile layers (e.g.2031– 2036). For example, forecast stack set (5040) of M0 cadence instance (5010) includes a forecast stacks (5030– 5033). [00218] Each forecast stack set (5040 - 5340) includes forecast stacks MiF0 (5030– 5330) which each include forecast tile layers containing data produced by initial tile calculations. Forecast stacks M _i F ₀ (5030– 5330) include data for the time at which the corresponding cadence instance collection interval was completed, t = 10 min. For example forecast stacks (5030- 5330) can each include a forecast precipitation tile layer (2031) that includes initial precipitation data produced by, for example, a microwave link precipitation program (654a,b) or precipitation blending program (918). [00219] Each forecast stack set (5040– 5340) includes a forecast stacks MiF1 (5031– 5331)

containing forecast generated data calculated by one or more forecasting processes for a first forecast time point (t = 25 minutes) of each forecast stack set. For example, forecast stack set (5040) includes forecast stack M1F1 (5031) which includes one or more forecast tile layers, for example forecast precipitation tile layer (2031) containing forecast generated data for t = 25 minutes calculated by precipitation forecasting program (915). Each forecast stack set (5040– 5340) includes forecast stacks for each forecast time point of the corresponding cadence instance including forecast stacks MiF2 (5032– 5332) containing forecast generated data calculated for t= 40 minutes through forecast stacks M _i F _n (5033– 5333) for the final forecast time period of the corresponding forecast stack set (t = 55 minutes). [00220] The forecast generated data set (and timestamp) F0 is the current time at which collection completes for the cadence instance (e.g. the time that the cadence index is incremented), F ₁ is current time + forecast interval, F ₂ is current time + 2 * forecast interval, etc.), repeating out to the forecast limit. Forecast limits are tunable for the system; typical values are between 2 - 6 hours for short term, high resolution (NowCast) forecasts, and 1-10 days for long term, lower resolution forecasts. [00221] The table below identifies the pre-, post- and forecast processing programs and the tile layers that their output data are associated with.

n ^u _u ^{n c} y  ^{p a} n ^u n ⁿ  

o ^o _{o u} ^d _c ^{y p}

  ^{s r} _{a r}   ^{y io e}

r ^a _t ^a   c

r _r ^{c g} _g ^u _{c r} ^o _{n h}

e ^t c _{d i} ^t

a ^{g r}

t _{t     s}   ^{u p r a}  _a

t ^t  _{g o}

o  ^A _{A   c} ⁿ

r

.  ^{a   n} _{e u}

. s ^{. t} _F ^A _r ^s _u

o ^c _d ^y

a _i ^{t     G c} _{r s}

N     _.   ^m

a _{b c v n}  

i _d ^.       _{. A}

a _b ^. _c. ^t   _a ^{.   n}

a _d ^. s ^t _e

v _in                              

   

                       

                      

   

                   

               

 

   

               

   

   

         

         

     

 

     

 

     

       

             

 

     

                    7

  ₄        

   

 

 

                     

   

             

               

             

   

                 

             

   

         

   

   

             

 

     

     

           

   

         

   

     

             

   

       

   

         

^e n  

o u ^o _s ^t

r ^{d d s} m

h y   d  

n ^d    

n ^d _n ^d d ^a

d   ^{a d f} _l ^e e ^d      

s ^p _{c t} ⁱ

c ^r  

g _e ^x _{e e} ^h _n d 

d ^d d   ^{a s} m o ^ra   _{e n} d  

u _u ⁿ _n

h ^{v e} _r ^{t u n d} d  

n ^{n d}

n _n ^{n e d   a d}

  ^e m ^t _o ^{o u} _u ^{o u} _n ^{u n e}  

o _{u  b e}

r _o ^u

r _{o r} ^{ro n i}   _{n   a o u} ^u _{u n}

n   ^{r e u u} _{u e} ^x _e

e _o ^r _{a r} ^ro _{o or ro} ^o  _b

u ^{r n iv} _e c ^F _u ^o _{a r} ^r _o

e ^G _r

  _G    ^{G G} _a m ^t   _G   ^G _r

  ^{G   c F}  _t ^d _{a w}   ^G _r ^{o u}

r _ro

    _G  ^G  _G  ^G

     ^G  _G ^C _a

   ^G  _G ^C _{a e} ^r _n

  ^c _o  

  ^F _t        

                                                       

                         

           

     

                                       

 

   

   

                           

         

           

                         

         

 

                                       

   

 

   

     

 

 

 

    ₄ 8        

             

   

       

     

     

     

  _l ^e e   ^d _h ⁿ d _h ^{e   d e} d ^e t v  

a ^{e e d e} d ^{e d}   o o ^{b b b}  

f ^{h e}

t _n   ^l _h ⁿ _{u h n} ^{b b} _a  ^{le   b} _a ^e

d _{n    a n} ^d _h d ^e   n _h ^p _{a h} ^{d e} r _e   ^u _u ^{o p}

  ^u _{a a  a}

  _{n h} r _a ^{s m}

a ^e _o ^{p u p n} _h

r _o ^{r s} _u ^{o p}

o _ro ^{s r s} _{r   h}

o ^{n sp u p}

r ^{s or} _o ^s _o  

r ^{m   m   p} _u ⁿ o _o ^{0 l   m  e  m l   m}  _o ^{u s} _{or o} ^{s d} _w

a ^{r   G} t ^m _{G o o l}

  t ^mG t  ^G 

  ₃ ³ _{1 e 0} ^{l   s} _o ^{o p u p r s} t _G   ^m _e ^o _{u o}

  ^m t ^{v r} t ^mG  t ^m  _G ^{m     v  1 v} _{e t 0}

a    ¹ _e ^{0 l}

1 _r

v   ^v _e  ^G t ^m _Go

  t ^m G t ^m      

       

           

     

                 

               

                                                                     

                 

 

 

                             

   

     

               

         

       

                           

                 

 

       

     

   

 

 

 

 

 

 

     

   

           

                       

   

   

   

     

       

         

 

   

 

 

     

   

   

       

d ^{e   d   i}

h ^{e   d e} n _t

n _n ^d _{h n h} d ^{u n} y   ^o a n

p ⁿ _h ^{e p}

o _u ^{o c}      

r _v ^a _s ^{e io} p _t ⁱ

a ^p     _n ⁱ 8 h _n ^{e (}

n   ^e

t  ^s _f ^e _i ^o

u ^{o s} _o ^{u sp u p p} _u ^p _r ^r _{ra r} ^a

y

o _{c d R} ^{e t} t     m ⁱ _r ^c , i ^{d ty a} _t  

c ^{a d}

n   _t

u ^b c a     r _{o r o o} ^s _o ^{u s  g} _g ^{t n} d ^a _{i e}

  ^u _e

c ^r   c _i t _{e s} ⁱ

: _e ^p _{e i o} d _{s   i} ^oi _r t G _{r o r o} ^{s ro} _{o t} ^{t a} _s ^{n i  p} _w ^t

o _a ⁿ _i

.   t ^mG _.   ^{m m   a} _s ^k r _{e n} ^{n h in}

c ^p _t ^p _{s r d a e} t _. ^G

a   t  ^Gm 

f _{a g.} t _G ^{. m} _{A h}

  _{c r t}

  _e ^m _{u  g}

t _c ^{n t} _{t a h} t ^A

a _{a. b} ^.   _. ^.

c s ⁱ _i ^k _t  ^{s i}

o _{d c}

e _{i c} ⁱ _{b c} ^{o i   e e} v _{in fu} n _c

i  

l _m ^s _F

e _d ^. _li n   _N ^{n e}

a _p ^{r l t} _e ^{e n}   _{mc a c b n} ^h

i _w ^{r m}

p _{co fu} ^{r er} _{t r o p} ^{a u} d _o ^r S _fu    

 

     

       

   

 

           

     

         

 

 

   

   

           

   

 

             

   

             

 

 

     

   

     

 

   

 

 

     

         

     

         

           

     

         

 

       

 

     

         

 

   

 

 

_t ^{i  o   c} t

a _e ^ta _r

a ^{u al} _t ^{i c}

t ^a _e ⁱ

a

i ⁿ _u ^r _t

it

p _o

i _o  ^d o

  ^lc _{f i} t

c  

m _{P S a} ^{ip p}

t _a ^C _c  

  _mc ⁱ

   

 

 

 

   

       

 

     

       

 

       

 

       

   

   

 

   

    ₅ 1    

       

   

       

   

 

 

       

       

              

               

             

 

     

         

           

     

         

     

 

 

   

 

 

 

           

             

 

                 

   

       

   

   

   

     

 

     

 

             

       

         

     

     

         

         

       

   

           

   

     

 

       

   

           

   

         

         

   

           

   

       

 

   

                           

     

                                   

      

           

 

 

 

   

 

     

a   d  ^{d a} n ⁱ

    _t   ^a

   

 

 

   

     

   

   

       

     

   

 

    

   

 

 

   

 

 

     

     

 

   

             

           

   

         

   

         

   

     

       

 

 

 

       

                     

   

                       

     

 

       

               

                   

             

 

   

   

   

 

 

[00222] Some collection processes do not organize the information collected by cadence. Often this data is configuration data that is used in the generation of pre-stored transforms. Examples are shown in the table below:

TABLE 5: Configuration Data

[00223] Once the collected data is collected, filtered, pre-processed, and organized, the

asynchronous collection cycle can repeat, optionally storing additional data in a cadence instance, or overwriting any previously collected data. [00224] At the end of a collection cycle, the cadence index is incremented. Collection processes continue writing their newly collected data associated with the new cadence index.

Processing of recently collected data will be completed using the previous (un-incremented) cadence index that it was assigned when collected. Subsequent data collected will be stored using the incremented cadence index. The time at which the cadence index was incremented is called the cadence timestamp, and is used in the forecasting process to adjust for collection delays. 6.4.2 Collection post-processing programs

[00225] Once a cadence instance has all of its collected data fully processed and written to the databases, one or more collection post-processing programs are executed by one or more processors of the system. These post-processing programs are sequenced by the system configuration so that data dependencies are honored and parallel processing pipelines are correctly configured. Specifically, the system does not start the execution of collection post- processing programs until the data that they need becomes available from other processes (collection processed or other post-processing processes). As each piece of data is made available, the system starts any programs that can be run against that data. This has particular importance for parallel processing programs that break up a processing task into many tasks that are executed independently on a plurality of computer processors. The collection post processing programs operate on the collected data of the current cadence instance and upon the collected and forecast generated data of previous cadence instances. Collection post- processing operates by executing programs that read the data associated with one or more cadence instance tile layers, performing calculations on this data, and storing the data in a data type specific database so as to create one or more tile layers in the F ₀ data stack of the current cadence instance. A notification may be sent when a post-processing program (or parallel portion) completes or when the entire post-processing stage is completed. These notifications permit the system to start the next process in a processing pipeline, or to transition to a new processing stage (e.g. post-processing to forecast). An example of this type of post-processing is the program that computes the conversion of microwave link attenuation data into a microwave precipitation estimate layer by applying a pre-computed transform to the collected data. [00226] Pre-processing of collected data into weather parameter data includes extrapolating

collected data from native coordinate systems to the coordinate system of a tile layer of collection data tile stack Mi. Pre-processing includes, for example, extrapolating data collected from a radar data source from a coordinate system used by the radar data source to the coordinate system and scale of the forecasting system. Pre-processing further includes generating weather parameter data based on collected data, for example by transforming collected microwave attenuation data to precipitation estimates mapped to a system tile layer. For example, a collection data stack Mi can include a weather sensor tile layer comprising sensor data collected during the Mi cadence cycle processed to create processed collected weather sensor data mapped to system tile. Each collected processed or collected generated data tile layer, and data mapped to the tile layer, is tagged with the cadence identifier Mi and Mi cadence time stamp and is saved to a database specific for the type of data. For example, processed collected weather sensor data is mapped to Mi weather sensor tile layer, tagged with the Mi identifier and with the Mi cadence time stamp, and saved to a weather sensor data database. [00227] One notable post-collection processing program is the precipitation blending program

(918). This program takes one or more precipitation layers from the collection tile stack and blends them together to produce an initial forecast precipitation tile layer (e.g. the MiF0- forecast precipitation tile layer). An exemplary precipitation layer blending program operates as detailed in Figure 8. In step 30010, the blending program determines if a microwave link precipitation tile layer tile is available for the tiles to be blended. If so, in step 30020, the microwave link precipitation data is copied to the output forecast tile and the process ends. In step 30030, if the program determines that the microwave link precipitation tile layer tile is not available, then the program checks if a second precipitation data source’s tile layer is available. If so, in step 30040, the program copies the second tile to the output forecast tile and the process ends. As long as there are additional precipitation tile layers to check, the program checks each one in turn (step 30050), copying the tile when one is found. This process iterates for each tile in the output tile layer (step 30060). [00228] An alternative exemplary blending process uses pre-computed accuracy improvement metrics from transform and filter database (393) to govern the blending operations. The program functions generally as described above, but accesses accuracy improvement data from the accuracy improvement database for the tile under consideration, and uses the accuracy improvement data for the current tile to select the source tile layer(s) based upon the highest available accuracy. Thus, if microwave link attenuation based precipitation estimates are more accurate than radar-based precipitation estimates for a particular location, the blending program will select the microwave link attenuation-based precipitation estimate. Alternatively, if the radar-based precipitation estimate is more accurate for a particular location, the blending program will select the radar-based precipitation estimate instead. [00229] The precipitation layer blending program may optionally perform blending functions for wind vector forecasts. 6.4.3 Forecast processing programs

[00230] Once the collection post processing stage is complete, the system then starts to process the forecasting stage, starting with the forecast pre-processing stage. The forecast pre-processing stage executes the configured forecast pre-processing programs in a configuration dependent order. These programs may be sequenced by system configuration so that dependencies are honored and parallel processing pipelines are correctly configured. The pre-processing stage reads information stored in the current cadence instance’s F0 tile stack and, optionally, collected information for the current cadence instances or collection or forecast generated data of prior cadence instances, performs calculations that produce new data as a result of those calculations, and writes the resulting data to a data type specific database in order to create a new data type tile layer of the F0 tile stack. A notification may be sent when a post- processing program completes or when the entire post-processing stage is completed. These notifications permit the system to start the next process in a processing pipeline, or to transition to a new processing stage (forecast pre-processing to forecast cycle processing). [00231] Once all of the forecast pre-processing is complete, the system begins an iterative process of calculating the forecasts for multiple points in future time. The first cycle, F ₀ , is associated with the cadence timestamp, as described above. The initial forecast index is set to zero (0). [00232] The forecast cycle operates by selecting a forecasting program such as precipitation

forecasting program (915) of the modeling and prediction server (360) and executing the program. The forecasting program operates upon one or more of the current cadence instance’s forecast current cycle tile data (e.g. MiFforecast index forecast tile data (and optionally upon the current cadence instance collected data and/or past cadence instances collection and forecast generated data)), reading that data into the processor memory, performing calculations upon that data, creating new forecast generated data, and writing the resulting data to a data type specific database in order to create a new forecast generated data type tile layer associated with M _i F _forecast index. [00233] After each forecast cycle completes, and forecast end count has not been reached, the

system iterates to perform the next forecast cycle. Each iterative forecast cycle increments the forecast index by 1 and generates a new forecast cycle timestamp. Processing then proceeds as above, with the iterative generation of MiF _forecast index data type specific tile layers. [00234] By appropriate sequencing of forecast program executions, the system can be configured, for example, to first process the current forecast precipitation, and then to execute additional extension programs such as post-forecast processing programs and weather product creation programs (both not described further) calculate additional forecast or computed results, such as a forecast post-processing extension program that provides hydrology forecasting based upon forecast post-processing calculations to generate forecast precipitation accumulation calculated from forecast precipitation rates and to generate forecast RVR calculated from one or more of forecast precipitation rates and forecast fog estimates. [00235] The system can determine accumulation amounts by retrieving parameter values from

collection tile stacks of multiple cadence instances M _i and from multiple forecast layers of multiple cadence instances MiFj having time stamps covering a desired accumulation time span. The retrieved parameter values are summed to generate an accumulated amount. Thus, accumulated precipitation from a first time x to a second time y is the sum across model and forecast layers spanning time x to time y. To determine an accumulated parameter for an area for time x to time y, the server retrieves parameter values for the area from for the selected layers, calculates an average for the area for each layer, and sums the averages for all selected layer. The average for an area is the arithmetic sum of the data elements within the selected tiles, divided by the number of tiles. 6.5 Overview of methods of reducing computational requirements of the system

[00236] Computational loads on weather forecasting systems are high. This high computational load prevents traditional linear processing of real time data. The techniques described in this section, when combined an optimized processing pipeline that removes processing bottlenecks, substantially reduce the real time processing loads on the system. 6.5.1 Pre-calculated filters and transforms

[00237] Pre-calculated and pre-stored filters and transforms, stored in transform and filter database (393) permit the efficient processing of collected data by pre-calculating aspects of the variable portions of the complex mapping and forecasting equations, which in turn simplifies the post-collection processing required. This has the effect of significantly speeding up the processing of the collected data. Some filters and transforms are provided with the system, others as calculated by information collection and normalization server (310 of Figure 3) or offline/background processing server (330 of Figure 2) in response to collected data, or are stored (cached) after they are computed (such as with radar transforms). Offline/background processing server (330) can periodically, for example in response to collected data, recalculate one or more filters or transforms and replace a pre-stored filter or transform with the recalculated filter or transform. The system suspends cadence post-collection processing and forecasting when offline/background processing server (330) is updating a filter or transform. A transform T can include a clipping transform, mapping transform, coordinate mapping transform, etc.

TABLE 6: Pre-Stored Filters and Transforms

[00238] A partial list of exemplary filters and transforms is included in Table 6. Additional filters used to process vehicle weather sensor data are listed in Table 9. 6.5.2 Pro forma microwave link segment endpoint

and weather sensor location grid and Pro Forma Links

[00239] The system described herein operates in ways to reduce the time and computational

requirements for the calculating weather parameter data based upon satellite-to-earth station microwave link attenuation. One way the system achieves this outcome is to reduce the computational requirements of calculating complex satellite to earth station geometries by pre-computing as much of the calculations as possible, and reducing the complexity of the calculations by using computational shortcuts. One such computational shortcut is the use of pro forma microwave link endpoint locations, which enables the use of pre-computed pro forma microwave links, which in turn permit the use of pre-calculated transforms that include all the necessary satellite to earth station geometries. [00240] In an exemplary embodiment the pro forma microwave link endpoint locations include pro forma satellite and ground station locations, i.e. endpoints of pro-forma microwave satellite links. In additional embodiments, pro forma microwave link endpoint locations include pro locations of other microwave link endpoints, for example terrestrial satellite mast locations and mobile microwave link endpoint locations. Pairs of pro forma microwave link endpoint locations serve as endpoints of one or more additional types of microwave links, for example a microwave link between an antenna mast to mobile microwave link endpoint such as a vehicle mounted microwave transceiver. In still further embodiments, pro forma locations include weather sensor locations, for example vehicle-mounted weather sensor locations. In some exemplary embodiments, a weather sensor data collection or processing program (e.g., 513 or 612) maps a location of a weather sensor indicated in a location field of a collected data point to a nearby pro-forma weather sensor location. [00241] Traditional satellite-to-earth station microwave links provide link-based attenuation data, which can be used to calculate attenuation-based weather parameter data values, for example the amount of water vapor or rainfall along the length of the link in a manner substantially similar to that used for known tower-based microwave links. Note that a satellite to earth station microwave link may be transmitted from the satellite and received by the earth station, or may be transmitted by the earth station and received by the satellite, or there may be two or more microwave links the satellite and earth station, with at least one microwave link in each direction. Unlike tower-based microwave links, satellite-to-earth station microwave links may have a moving satellite or earth station endpoint, and thus have varying link lengths (and thus varying distance-related baseline attenuation). The system uses some computational shortcuts in order to pre-compute most of the complex geometry required to determine the link length and attenuation contribution of the portion of the atmosphere through which it passes. [00242] In an exemplary embodiment, the system generates a pro forma grid across the sky, for example at an elevation corresponding to a satellite orbit, and a pro forma earth station location grid across the earth at ground level, and identifies a number of strata of interest between the pro forma grids. The size of cells comprising pro forma location grids may vary. The grid cell size is chosen to minimize subsequent mapping to tile layers and so that the spatial geometry of a microwave link traversing from any location within a sky grid cell to any location within an earth grid cell does not significantly vary the length of the computed microwave link segments within the earth’s atmosphere. The center of each grid cell (of both satellite and earth station pro forma location grids) is chosen as a pro forma location. The system pre-computes the spatial geometry between pairs of pro forma satellite location and pro forma ground station locations. This calculation is replicated for each pro forma earth station location and pro forma satellite location pair to produce a lookup table of pro forma microwave links. The system pre-computes baseline attenuation and link segmentation information and stores the data in the system database. This pre-computed link data is used during processing of the satellite-to-earth station microwave link attenuation values in lieu of calculating the complex geometries and attenuation allocations each time a link attenuation value is received by the system. This approach substantially reduces the compute resources required. This section outlines how the system generates pre-calculated transforms that include the pre-computed attenuation and link segmentation data. [00243] As mentioned above, the system pre-computes pro forma grid locations of satellite and earth station satellite microwave link endpoints and stores these grid locations in a database. It also precomputes pro forma satellite-to-earth station microwave links between all pairs of the pro forma link endpoint locations and stores this information in a database as well. Pre- computed filters and geometric transforms are calculated for each pro forma satellite-to-earth station microwave link. The filters and geometric transforms are used by the system to convert, using sets of equations encoded in the transforms, a collected microwave link attenuation measurement value into a set of attenuation-based weather parameter data estimates in regions of a plane onto which the link, or a section of the link, is projected and to transform the measurement values to system tiles and tile layers corresponding to the plane.By mapping satellite and ground station locations to pro forma endpoint locations, obtaining the geometry and baseline attenuation of the satellite-to-earth station microwave link between pro-forma endpoint locations becomes a simple table lookup from a pro forma link database. The precomputed transforms and filters associated with the pro forma satellite- to-earth station microwave link enables real time processing of the received attenuation data into a set of microwave link segments mapped to ground-level or atmospheric altitude level planes with a portion of the baselined attenuation allocated to each segment. [00244] The system combines a complex set of location mapping, microwave link segmentation, and attenuation-to-weather parameter estimates and estimates to tile layer calculations required to into a single transform. This enables the system to pass collected attenuation data for a satellite-to-earth station link through the precomputed transform once and obtain attenuation-based weather parameter data estimates, for example precipitation, atmospheric water vapor, or LWC estimates, for each affected tile of each affected tile layer may be obtained by processing a single set of equations with the received attenuation as the variable. This approach provides a large improvement over known methods that require approximately four dozen discrete operations and calculations normally. This approach is also flexible, as the pro forma microwave link endpoints, pro forma microwave link data, and the associated transforms are all pre-computed and stored in a database. They may be updated as needs dictate. [00245] This type of processing optimization, when combined with the processing architectures described herein, enable the real-time calculation of weather parameter data based upon satellite microwave link signal attenuation. 6.5.2.1 Exemplary pro forma satellite link grids

[00246] Figure 9 illustrates a pro forma satellite location grid (80100) configured to divide a region of the atmosphere into grid cells to which the orbital location of a satellite, for example, a low earth orbit (LEO) or mid-earth orbit (MEO) satellite, can be mapped. In the illustrated embodiment grid cells as planar cells. In additional exemplary embodiments, grid cells are curved, curvilinear, or spherical without loss of functionality. In an embodiment, the pro forma satellite location grid divides the atmosphere into multiple roughly square cells, each comprising two degrees of latitude on one side and two degrees of longitude on a second side that is disposed normal to the first side. Other cell sizes and shapes may be used when desired. In an embodiment, pro forma satellite locations are spaced such that a satellite to earth station microwave link has at least 1/2 ^o angle resolution, i.e. that a change of link angle of greater than 1/2 ^o will result in change of pro forma satellite location. A pro forma satellite location, indicated by a black dot (e.g.80110), is located at the center of each grid cell. Each pro forma satellite location can comprise a satellite endpoint of a satellite-to-earth station pro forma link. [00247] In additional embodiments (not shown), a plurality of pro forma satellite location grids, each substantially similar to grid (80100) are each located at a one of a plurality of elevations including, for example, a first pro forma satellite location grid at a LEO elevation and a second pro forma satellite location grid at a MEO elevation. In some embodiments, spacing between pro forma locations can be different in each grid. In general, grid spacing is selected such that as few pro forma locations as possible are defined while maintaining an acceptable level of error in the resulting geometry due to satellite location and pro forma location mismatch. In some embodiments, a satellite location grid is constructed to map pro forma satellite locations for a group of earth stations, e.g., for all earth stations within a geographic region. In another embodiment, the system constructs a separate pro forma satellite location grid for each of multiple earth stations. [00248] A lower grid (80200) is located at ground level, and includes a plurality of pro forma earth station locations (e.g.80211, 80212), each represented by a black dot in the center of a tile or cell of lower grid (80200). Each pro forma earth station location comprises an earth station end of a pro forma satellite-to-earth station link. [00249] Upper tile grid (80300) is located at 0 ^o C isotherm. The altitude of the upper tile grid may vary depending upon the time of year or other factors. Additional tile grids may be used, and their altitude chosen in order to isolate particular atmospheric characteristics important for atmospheric modelling. For example, a fixed altitude such as 500 meters above ground may be used instead of or in addition to the temperature altitude grid depicted. Grids (80200, 80300) may be chosen to represent satellite microwave precipitation and atmospheric water vapor tile layers of a tile stack, or an independent grid may be used and the resulting data mapped to one or more tile layers as needed. Lower grid (80200) corresponds to a satellite microwave precipitation and atmospheric water vapor tile layer for satellite microwave precipitation or atmospheric water estimates near ground level, for example, for a ground level to 500m atmospheric layer. Upper grid (80300) corresponds to a satellite microwave precipitation and atmospheric water vapor tile layer for satellite microwave precipitation or atmospheric water estimates of an atmospheric layer bounded by the 0 ^o C isotherm and the upper limit of the troposphere, located at the tropopause. [00250] As mentioned above, the pro forma microwave satellite links are precomputed by the system between each pro forma satellite location and each pro forma earth station location. For example, a pro forma satellite microwave link (e.g., 80600) is precomputed between each pro forma satellite location (e.g., 80110) and pro forma earth station location (e.g., 80212). [00251] Because the link length from satellite to earth is relatively long, the satellite-to-earth station link geometries are similar for a locus of points around the pro forma satellite and earth station locations, and thus the length of the microwave link is therefore similar. The baseline attenuation for a microwave link is related to its length, so all links between a specific pair of earth and sky grid cells have approximately the same baseline attenuation due to the length. A pro forma location that is the average of the actual satellite and earth station location thus can be used in lieu of the current actual location without loss of precision in the link attenuation baselining. [00252] Pro forma satellite microwave links are divided into satellite link segments at intersection points with altitude strata. For example, pro forma satellite microwave link (80600) is divided into satellite link segments (80615, 80125, 80135) at intersection point (80610) with 0 ^o C isotherm and intersection point (80620) with the tropopause. A limited number of strata are shown for clarity. The system can be configured to use any number of strata without loss of functionality, resulting in more or fewer satellite link segments. [00253] Satellite link segments are 3D structures, so they are projected onto planar grids, for

elevations corresponding to the atmospheric layer that the satellite link segment traverses. As shown in Figure 9, the first satellite link segment (80615) is projected onto lower grid (80200) as a projected satellite link segment (80715) and the second satellite link segment (80125) is projected onto upper grid (80300) as projected satellite link segment (80725). 6.5.3 Snap to grid

6.5.3.1 Microwave link snap to grid

[00254] The system also implements a“snap-to-grid” method for estimating satellite and earth station locations in order to reduce the number of computations required for calculating the satellite-earth station link geometry. As has been previously described, the system can predetermine sets of pro forma microwave link endpoints at ground level and at one or more atmospheric levels (i.e. determine potential endpoints of sender-to-receiver links before measurement data from an actual“live” link is received) as well as the associated geometries, baseline attenuation, and transforms required to convert received attenuation values to precipitation or water vapor values. The microwave signal attenuation measurements are processed, using the predefined transforms and filters associated with the microwave link, to determine precipitation and atmospheric water vapor estimates at specific locations and to map precipitation and atmospheric water estimates to specific one or more tile layers. [00255] When a satellite microwave signal attenuation measurement is received, a location of the associated satellite at the time the signal was received or transmitted by the satellite is determined or estimated from ephemeris data. The satellite location is mapped to the nearest pre-computed pro forma satellite grid location. The earth station location is similarly determined from a lookup table (for fixed location earth stations) or by GPS coordinates (for either a mobile earth station or a fixed location earth station) and is mapped to the nearest pro forma ground level grid location. The pro forma microwave link and pre-calculated transforms associated with these two pro forma endpoints is used to process the received attenuation values. Received satellite signal measurements can be associated with pre- computed link geometries even when incomplete satellite location information is received. This allows the system to rapidly process satellite measurement signals and calculate atmospheric weather information from signal measurements without requiring precise satellite location or timing information. [00256] In a similar manner, the technology described herein can be used to snap one or both

endpoint transceivers and/or receivers of any microwave signal for which attenuation collected data is received to pre-determined pro forma locations, associate the collected data with a pre-computed pro forma link extending between the two pro forma endpoints and rapidly process the received collected data using transforms and filters that have been pre- calculated for and associated with the pro forma link. 6.5.3.1.1 Exemplary satellite microwave link snap to grid process

[00257] Figure 10 includes a flowchart depicting an exemplary satellite microwave link snap to grid process (40000) which the satellite microwave link data processing program (615a), implements to process satellite link data including signal attenuation information (525a) to generate satellite microwave link processed attenuation data (625a). The satellite microwave link data processing program implements the microwave link snap to grid process to satellite microwave link endpoints to pro forma locations and to select a pro-forma link as associated pre-calculated satellite microwave link transform for use in processing satellite microwave link attenuation data. [00258] At step (40010) the satellite microwave link data processing program begins processing a satellite microwave link attenuation measurement. If, at step (40020), the satellite microwave link data processing program determines that an identification of a subject satellite corresponding to the collected data is known, for example the collected data includes a data field indicating the subject satellite ID, satellite microwave link data processing program looks up subject satellite ephemeris data by satellite ID (40100). At step (40110), satellite microwave link data processing program selects the nearest pro forma satellite location (e.g., pro forma location (10100) on pro forma path (10010) or pro forma location (80110) on atmospheric grid (80100)). The nearest pro forma location is selected in relation to a satellite position determined from ephemeris data based on subject satellite ID and a timestamp indicating signal transmission time. If signal transmission timestamp is not available, satellite microwave link data processing (915) program can use a signal reception time stamp to estimate satellite position, optionally including a correction factor to account for satellite movement during an estimated period of time for the signal to travel from the satellite to a receiving earth station. [00259] If, at step (40020), the identification of a satellite associated with the satellite microwave link attenuation measurement is not known, the satellite microwave link data processing program determines at step (40200) if an azimuth (e.g., 10029 of Figure 11) associated with the measurement is known. If an azimuth is not known, the satellite microwave link data processing program determines, at step (40210), whether elevation is greater than 80 ^o . If elevation is not greater than 80 ^o , the measurement is discarded (40220). If elevation is greater than 80 ^o , the satellite microwave link data processing program assumes that the satellite is substantially directly overhead and sets elevation to 85 ^o . [00260] At step (40240), the satellite microwave link data processing program calculates geometry of the satellite-to-earth station link using known or assumed (85 ^o ) elevation angle of the link. For example, the satellite microwave link data processing program calculates geometry of link (10025) using elevation (10027) and azimuth (10029). [00261] At step (40250), satellite microwave link data processing program (615a) queries atmospheric grid (80100) or pro forma satellite path (10010) for pro forma satellite location points that correspond to calculated link geometry. If, at step (40260), the calculated link geometry matches more than one pro forma satellite location point, the measurement is discarded (40270). If the calculated link geometry matches a single pro forma satellite location, the matching pro forma satellite location is selected (40280). [00262] At step (40300), the satellite microwave link data processing program determines an earth station location, either exact (e.g. location of 10003 of Figure 12) or pro forma (e.g.80211, 80212 of Figure 9), of the satellite microwave attenuation measurement being processed and then selects a pro forma link that extends between the pro forma satellite location determined in either of steps (40110) or (40280) and the earth station location. When processing mobile dynamic satellite microwave links (i.e. links between a satellite and mobile earth station) satellite microwave link data processing program can select a pro forma earth station location closest to the position of the mobile earth station at the time of the attenuation measurement timestamp (or, alternatively signal receive time). Snapping a mobile earth station measurement to a pro forma earth station location requires that position information of the mobile earth station (i.e. latitude and longitude) is associated with the measurement. If position information is not available, the measurement is discarded. At the completion of step (40300), the satellite microwave precipitation program has snapped both ends of the microwave satellite link being processed to a selected pro forma link. [00263] At step (40400), the satellite microwave precipitation program retrieves, from the transform and filter database (393), pre-calculated transforms and filters associated with the selected pro forma link and uses the transforms and filters to process the satellite microwave link attenuation measurement. Processing of the attenuation measurements can include applying pre-calculated filters to eliminate measurements from links with link characteristics that indicated erroneous or out of band measurements or that are otherwise not useful for calculating satellite microwave precipitation or atmospheric water estimates. Processing of the attenuation measurement further includes using pre-calculated transforms to determine wet attenuation and assign percentage of the calculated wet attenuation is assigned to each satellite link segment that traverses a wet atmosphere layer. Satellite microwave link processed attenuation data (625a) is saved to satellite microwave link attenuation database (352a) and the satellite microwave link snap to grid process (40000) ends. [00264] In an alternative exemplary embodiment, satellite microwave data collection program

(510a), operating on information collection and normalization server (310), performs one or more of the satellite microwave link data pre-processing operations described in this section. 6.5.3.1.2 Mobile weather sensor snap to grid

[00265] The technology described herein can also snap collected data corresponding to a point location (i.e. measurements at a discrete location such as mobile weather sensor collected data) to nearby pro forma locations and process the collected data with transforms and filters associates with the pro forma location or with sets of pro forma locations such as, for example, filters to exclude possibly erroneous or extraneous measurements and transforms to bin, average, map-to-tiles, and perform other data processing operations on the

measurements. 6.5.4 Illustrative pro forma satellite microwave links, satellite link segments,

satellite link segment endpoints and wet atmospheric layers

[00266] Referring to Figures 11 and 12, multiple pro forma satellite microwave links (10200– 10218) are shown extending between earth station (10030) and pro forma satellite location points (10100– 10118) along pro forma satellite path (10010). Each pro forma satellite location point represents a predicted location of a particular satellite along the pro forma satellite path. The system determines earth station locations and creates pro forma satellite paths using satellite microwave link infrastructure data. For example, the system determines satellite location points for a particular satellite based on ephemeris data corresponding to the satellite when the ephemeris data is available. The pro forma satellite path and pro forma satellite location points can be updated to reflect changes in the satellite orbital path derived from updates to satellite microwave link infrastructure data, for example from updated ephemeris data provided by a satellite microwave network data supplier. Each pro forma satellite microwave link is defined by an elevation angle, azimuth, and path length. For example, pro forma satellite microwave link (10200) is defined by elevation angle (10207) and azimuth (10209). Length of each pro forma satellite microwave link can be calculated using satellite microwave link infrastructure data including the earth station receiver altitude (10032), altitude of the satellite (which can be determined from ephemeris data), and the elevation angle of the pro forma satellite microwave link. [00267] Each pro forma satellite microwave link is subdivided into multiple satellite link segments by intersection points with predetermined atmospheric strata (e.g. the 0 ^o C temperature strata or the tropopause boundary). Each satellite link segment generally corresponds to an atmospheric layer and each atmospheric layer is associated with a relative amount of atmospheric water contained within that layer. Thus, each satellite link segment may have a pre-calculated relative amount of atmospheric water (water vapor or liquid water content) by attributing a portion of link attenuation for the whole link to each link segment. Spatial distribution of atmospheric water vapor along a pro forma satellite microwave link, and granular satellite microwave precipitation or atmospheric water estimates, can thus be determined. This differs from conventional methods which assign all attenuation to a single link or to a single portion of a link. [00268] Similarly, intersections of the pro forma satellite microwave link with interesting

atmospheric strata such as the 0 ^o C temperature strata can also be pre-calculated, and the resulting 3D line segment projected to a 2D plane as part of a single unitary calculation solving the well-known intersection of a line with a plane equations combined with 3D to 2D projection of the line segment to the base of the strata. In the same equation, the link attenuation can be transformed (based upon link segment length) to an estimated atmospheric water or precipitation value. [00269] The atmosphere is divided by one or more altitude strata (e.g.10930, 10940, 10950) into multiple atmospheric layers (10935, 10945, 10935), each of which includes an associated proportion of atmospheric water. Although three atmospheric layers are illustrated in Figure 12, the atmosphere can be divided into more layers or into fewer layers as is appropriate to model atmospheric conditions at a desired resolution. [00270] In an embodiment, all atmospheric water is assumed to be contained below an upper altitude stratum (10930) and the remaining atmosphere above the upper altitude strata is assumed to be dry and not contribute to the link attenuation. All atmospheric water is assumed to be contained in atmospheric layer (10900), which is subdivided by altitude strata (10940, 10950) into atmospheric layers (10935, 10945, 10955). In an embodiment, atmospheric layer (10900) includes the troposphere, which may include the majority of atmospheric water, and upper altitude strata (10930) is located at the height of the tropopause (boundary between troposphere and stratosphere) corresponding to the location of earth station (10030). For example upper altitude strata (10930) can be located at an altitude of 17 – 20 km of an earth station located in the mid latitudes. [00271] In some exemplary embodiments, altitude strata (10940, 10950) are located at altitudes corresponding to relevant atmospheric conditions local to earth station (10030). For example in an exemplary configuration in a geographic location where 90% of water vapor is typically located within 7 km of ground level and 50% of water vapor is typically located within 4 km of ground level, altitude strata (10940, 10950) are located at 7 km and 4 km, respectively. In some embodiments, at least one of the altitude strata (10940, 10950) are located at an elevation of an isotherm or isobar such as, for example, at the estimated, calculated, or actual elevation of a 0 ^o C isotherm. [00272] Altitude strata (10940, 10950) are determined based on measurements of ground

temperature and pressure combined with interpolation of stratification of atmospheric pressure and temperature within a column of air above the location of the ground temperature and pressure measurement. Atmospheric pressure, saturation vapor pressure, atmospheric water vapor pressure or partial pressure, and dew point vary with temperature and in some embodiments are used to determine altitude strata (10940, 10950) such that atmospheric layers (10935, 10945, 10955) correspond to water vapor content based on these values. [00273] Referring to Figure 12, each pro forma satellite microwave link (10200– 10218) intersects the altitude strata at intersection points that divide each link into multiple satellite link segments. For example, pro forma satellite link (10200) intersects the altitude strata at intersection points (10300– 10500) which divide it into multiple satellite link segments (10150, 10350, 10450, 10550). Each intersection point is projected vertically onto ground level (10020), as represented by projection lines (10301, 10401, 10501). Referring to Figure 11, which is a top view of the geometry illustrated in Figure 12, the intersection points (10500– 10518, 10400-10418, and 10300-10318) are projected onto ground location coordinates, i.e. each intersection point is mapped to an X, Y location corresponding ground level elevation. Intersection points can be projected onto planes at ground level and onto planes at elevations corresponding to the atmospheric strata that define the intersection points. Pro forma satellite link segments (e.g. satellite link segments 10550, 10450, 10350, 10150) are also mapped to X, Y ground coordinates. [00274] Each satellite link segment is projected to a plane at a vertical height corresponding to atmospheric layers which the satellite link segment traverses. Pro forma satellite microwave links and satellite link segments can be projected to ground level and atmospheric elevation level planes using projection techniques such as perspective projection or a graphical clipping method such as viewport clipping. A collected satellite microwave precipitation and atmospheric water vapor tile layer (2022a) is associated with each plane onto which satellite link segments are projected. Each measured satellite microwave precipitation and atmospheric water vapor tile layer is populated with data from a corresponding atmospheric layer. For example, as shown in Figure 12, satellite link segment (10550) is projected as first satellite link projection (10610) onto a plane at ground level corresponding to atmosphere layer (10955) and generated collected data from the satellite link segment collected in a satellite microwave precipitation and atmospheric water vapor tile layer corresponding to atmospheric layer (10955). In a similar manner, satellite link segments (10450 and 10350) are projected as second and third satellite link projections (10620 and 10630) and weather parameter data from the satellite link segments are transformed to satellite microwave precipitation and atmospheric water vapor tile layers associated with the atmospheric layer through which each satellite link segment traverses. [00275] Satellite microwave link attenuation collected data is used to calculate precipitation and atmospheric water values corresponding to each satellite link segment. Because each satellite link segment corresponds to a particular altitude layer, atmospheric water estimates at a particular X, Y ground coordinate include estimates of atmospheric water at the

corresponding altitude layer above the X, Y ground coordinate. The disclosed system can map multiple satellite links and constituent satellite link segments to a particular ground location. Each satellite link segment can correspond to a different altitude layer. This enables the system to rapidly map atmospheric water in three dimensions (X, Y ground coordinates plus altitude) without requiring use of computationally expensive and time consuming tomographic reconstruction techniques. Satellite microwave link attenuation measurement data can be used to determine additional or other atmospheric conditions including, for example, precipitation rate and cloud water content, without departing from the disclosed technology. 6.6 Information Collection and Normalization Server (310)

[00276] Referring again to Figure 2, the first server (including a data processing component) is an information collection and normalization component (310) that interacts with external data sources (340-348) and collects relevant information from these data sources for use by the precipitation modeling and forecasting system (300). The Information Collection and Normalization Server (310) provides asynchronous data collection processes involving communicating with the data sources, pre-processing the collected data, and making the collected and processed data available for the forecasting and modelling components of the system. In some embodiments, additional processing to produce generated data from the collected and processed data is performed on the server. The asynchronous collected and pre- processing of the collected data permits the high-frequency collection and pre-processing of data without direct effects to the forecasting the forecasting cycles. [00277] The Information Collection and Normalization Server (310) pre-processes the collected data in order to change the data into a format that is usable by other processes of the precipitation modeling and forecasting system (300) by filtering, error-correcting, reducing redundancy, improving the accuracy of, and normalizing the collected data, for example by reconciling different data source reporting formats, e.g. measurement units and reporting intervals, to common system formats, thereby creating processed collected data. [00278] The information collection and normalization server programs implement the first part of the processing pipeline using a series of data collection, data cleaning, and data normalization programs. One aspect of these programs this that they may use one or more pre-calculated filters, pre-calculated data transforms, and trained machine learning (ML) models in order to convert the raw collected data into processed data or weather data that is usable by the modelling and forecasting portions of the system in order to eliminate much of the compute requirement of traditional system architectures. Similarly, the information collection server programs may apply pre-calculated filters to collected data to remove data that is extraneous, erroneous, distorted, or otherwise unreliable in order to improve accuracy of the processed results. Pre-calculated filters may also be used bin collected data of similar type and location in order to increase the confidence of the collected data. Processing is carried out by one or more processors of the server using one or more programs and pre-defined filters and transforms (Table 6) specific to the type of information being processed. The programs are stored in or executed in transient or persistent memory of the server, and carry out the processing required on data stored in or executed in transient or persistent memory and/or system database (320). Data located in a persistent memory or a system database are said to be in a data store of the described system. [00279] The information collection and normalization server stores the collected data and processed collected data into one or more databases tagged in ways that automatically associate the stored data with the cadence and tile layer structures used by the forecasting components. In this way, the stored data is identified and formatted in a manner that allows more efficient further processing of the stored data and provision of a more accurate precipitation, atmospheric water vapor, and fog model and forecast model. [00280] Processes for ingesting a first type of information can be performed independently of other processes for ingesting other types of information. Alternatively, these processes may be performed at the same time without loss of functionality. Either approach may involve reading additional data that is simultaneously or previously acquired from the same or other sources, or may include other data stored in one or more databases of the system. 6.6.1 Data Sources of the Information Collection and Normalization Server

[00281] The information collection and normalization server (310) interacts with external data sources (340-348) and collects relevant information from these sources for use by the precipitation modeling and forecasting system (300). [00282] Data from Terrestrial Microwave Network data sources (e.g. point-to-point microwave and cellular networks), including terrestrial microwave link infrastructure data and microwave link attenuation collected data, is received and processed from a terrestrial wireless network data source (340b), using one or more microwave data collection programs (510b), writing terrestrial microwave link data (525b) to a database of the system database. Exemplary additional data sources that are processed in addition to, and the results merged into the previously described processing streams to improve weather forecasting are described below. [00283] Terrestrial Microwave Network data sources (e.g. point-to-point microwave and cellular networks) are received and processed from a microwave network data source (340b), using one or more microwave data collection programs (510b), writing terrestrial microwave link data (525b) to a database of the system database. [00284] The satellite network data source (340a) is an interface to one or more satellite network data sources each providing satellite-based microwave link infrastructure data including wireless network topology information relating to one or more satellite-terminated microwave links. Satellite network data sources are typically provided by satellite network operators, such as Verizon, Comsat, Intelsat, and Inmarsat. [00285] Satellite network data sources typically provide satellite microwave link infrastructure data regarding satellite uplink/downlink networks including: link information associated with satellite-to-earth station microwave links; whether uplink (from earth station to satellite), downlink (satellite to earth station), or bi-directional satellite links. The microwave link infrastructure data provided by satellite communication providers includes link frequencies and polarization, earth station locations and earth station antenna characteristics, satellite IDs, satellite ephemeris data, and transmit and receive signal levels. [00286] According to the present invention, satellite microwave link infrastructure data may be received from a plurality of locations and a plurality of network providers over large geographic regions, such as from satellite network operators operating a plurality of separate earth stations (either mobile or stationary). Each satellite network data source can provide individual sets of data from a single earth station (including the location of the earth station), data from a plurality of earth stations, or a combination of data from several network operators. [00287] The satellite microwave link infrastructure data provided may optionally include identity and location of stationary (geosynchronous) and low earth orbit (LEO) satellites and identify these connections as dynamic or static links each having a satellite link ID and an activity indication, such as the last time the satellite communicated with the earth station. The operating information included in the microwave link infrastructure data may include information regarding both static and dynamic satellite microwave links, as shown in Table 7. The data source may also provide additional information related to the satellite network, the earth station topology, and its operations. The satellite microwave link infrastructure data can be provided in the form of one or more CSV files (or in other formats) and may include static network topology information, such as the location and altitude of earth stations. [00288] Data collected from satellite network data sources (340a) are typically acquired by

communicating with a management server of one or more satellite networks or by communicating directly with one or more earth stations. An information collection and normalization server (310) can send requests for data or receive pushed data from one or more earth stations and network management servers. The information collection and normalization server includes an alerting function wherein a satellite network data source is notified if data reporting errors occur; for example if an earth station or network management server stops reporting data or if received data includes missing information, as compared to previous data, or zero value measurement reports. [00289] A non-limiting example of the types of information provided by a satellite network data source (340a) is provided in the table below:

TABLE 7: Microwave Link Infrastructure Data Types

Provided by a Satellite Network Data Source

[00290] Weather sensor data sources (346) provide data from individual static weather sensors operating at ground weather stations located at or near ground level at various geolocations such as land and sea based weather stations, at airports and sea ports, on top of buildings and mountains at various altitudes as well as weather stations proximally located to one or more microwave links. Ground stations can include ground stations located at or near airports, and ground stations operated by airports, that measure weather parameters that are particularly useful for aviation and as such can include RVR and fog sensors, humidity sensors, and temperature sensors. Weather sensor data (522) from ground weather stations and other static weather sensors may be provided by one or more networks of weather stations and weather sensors such as those provided commercially by the Weather Company. [00291] Weather sensor data sources operating at ground weather stations may include rain or snow gauges for measuring actual rain and snow accumulation on the ground, fog or visibility detectors for detecting fog and measuring visibility, barometers for measuring local atmospheric pressure, thermometers for measuring temperature, speed and direction sensors for measuring wind, and hydrometers for measuring relative humidity or dew point. [00292] A partial list of static weather sensors and related weather sensor data that may be obtained from various external data sources is provided in the table below.

TABLE 8: Static Weather Sensors and Related Weather Sensor Data

[00293] Weather sensor data sources may also include individual weather sensors mounted to

mobile platforms, or other types of sensors from which weather data can be inferred. Weather sensor data sources that provide weather sensor data from mobile weather sensors include data sources that collect, package, and distribute weather-related data generated by sensors mounted on one or more mobile platforms, typically manned or unmanned vehicles. These sensors are characterized by their mobility (e.g. a changing geolocation) , and small temporal resolution (very high data rate). As such, they provide particular challenges for integrating their data with weather forecast models. Mobile weather sensors can be mounted on ground vehicles such as cars, trucks, buses, and trains, on ocean or freight and passenger ships, and air vehicles including, for example, airplanes, UAVs, and balloons. Vehicle-based weather data sources can include interfaces to data from individual vehicles or the data source may aggregate data from multiple vehicles, for example, to anonymize the data received from one or more vehicles or to systems and/or networks that collect this data from vehicles. [00294] Data from vehicle-mounted weather data sources can include the current vehicle location (latitude, longitude, and altitude), directly measured weather parameter data such as outside temperature, atmospheric humidity, or moisture measured by vehicle-mounted moisture sensors, or from engine control sensors that measure conditioned air flowing to an engine. Mobile weather sensor data includes derived or estimated weather data calculated from vehicle-mounted sensors (or data used to derive or estimate weather sensor data taken from these sensors). Note that many of the mobile sensors are of low fidelity or accuracy. The accuracy of the estimated weather sensor data may be improved by combining several low fidelity or accuracy sensor readings for the same location and time. [00295] A partial list of mobile weather sensors and related weather sensor data that may be obtained from various external weather sensor data sources, such as aircraft data collected from flying vehicles (e.g. aircraft, UAV, balloons), ground vehicle data collected from various types of ground vehicles (e.g. cars, trucks) is provided in the table below.

TABLE 9: Mobile Weather Sensors

[00296] RVR ancillary data sources (343) include airports and data sources located at or near

airports or other locations where RVR is calculated or forecast. RVR ancillary data sources provide data that are used, in combination with rain rate or other precipitation estimates, to estimate and predict RVR. RVR ancillary data (529) can include Koschmieder visibility (Vk) measured by RVR sensors located at an airport, airport runway light intensity (I), and temperature and humidity at RVR reporting location. [00297] Numerical Weather Prediction (NWP) model data sources (341) include sources of weather data derived from numerical modeling programs, for example, for example the National Oceanic and Atmospheric Administration (NOAA), which is a source of NWP data (526) including, for example, high resolution rapid refresh (HRRR) forecast data. [00298] Weather radar data sources (344) include, for example, the National Oceanic and Atmospheric Administration (NOAA) data sources, which provide NEXRAD radar data including pre-processed Level III radar data, including base reflectivity in dBz. Additional exemplary radar data sources include the National Severe Storms Laboratory (NSSL) data sources, which provides data generated by the Multi-Radar Multi-Sensor (MRMS) project including mosaicked data composited from multiple data sources including multiple individual radar sensors. [00299] Map data sources (348) are providers of map and Geographic Information System (GIS) data, which includes geo-information such as topographic and general reference map information related to the shape and geolocation of ground landmarks such as hills, mountains, shorelines, or the like, and may further provide data, e.g. geolocation of roadways, railways, airports, seaports, levies, retaining walls, dams, and any other manmade structures as may be required. [00300] Other info data sources (347) are any sources of data that do not fall into any of the other data categories (e.g., 340-348) and can include, for example, weather satellite data sources and weather radar data sources. 6.6.2 Interface Programs of the Information Collection and Normalization Server

[00301] Each information source that is utilized by the information collection and normalization server typically has a dedicated interface program present on the information collection and normalization server that operates to (a) connect to the information sources over a network, (b) interact with the information source using well defined interfaces, (c) retrieve selected data from the information source, (d) process that retrieved data in accordance with information source specific algorithms, and (e) write the processed data to one or more persistent memories of the system. Different programs are used depending upon the type of information source accessed, its defined interface, and the nature of the processing required. [00302] Data collection programs may include features of the corresponding data processing

programs of the offline/background processing server when these features do not slow the processing pipeline. For example, a data collection program may be extended to use a pre- computed filter or pre-computed transform to completely process collected data at the time of collection instead of incurring the costs of saving the interim results to the system database and then starting a second program that reads the data and performs the filtering and/or transforms. 6.6.2.1 Satellite Microwave data collection program (510a)

[00303] The satellite microwave data collection program (510a), operating on the information

collection and normalization server (310), receives collected data from one or more satellite network data sources (340a) through network interface (530f) and processes and stores the received microwave link data including signal attenuation data to a satellite microwave link attenuation database (352a) as satellite microwave link raw data. The collected data includes satellite link data from multiple satellite-ground station microwave links. Alternatively, the satellite microwave data collection program receives continuously updated satellite link data. In some embodiments, the satellite microwave data collection program may receive reports that include aggregate measurements over a period of time, for example over 15 minute, 30 minute, or one hour intervals. Received data includes TSL and RSL measurements, and signal polarization information for each of the multiple microwave links. In some embodiments, the satellite microwave data collection program receives reports that include updated satellite microwave link infrastructure data, for example satellite and ground station configuration or status changes. Collected data can include information including information listed in Table 5. [00304] The satellite microwave data collection program parses the collected data to extract TSL and RSL values, metadata, and ancillary data. Parsed data includes at least TSL and RSL values indexed with link endpoint identification. Parsed data is then associated with the current cadence instance Mi, as previously discussed.. In an exemplary embodiment, the satellite microwave data collection program applies one or more pre-configured filters, for example a microwave link frequency or received signal strength filter listed in Table 6, to exclude collected data points below a threshold frequency or having an attenuation measurement value below a threshold amount, from further processing. Parsed and filtered data is then associated with the current cadence instance Mi, and tagged. Parsed and filtered satellite microwave link data is stored in satellite microwave link attenuation database (352a). Satellite ephemeris data and other satellite microwave link location and characteristics data can be stored in satellite microwave link ephemeris information database (390). [00305] In some embodiments, the link precipitation calculations are included in the link attenuation processing, further reducing the computing overhead. In these cases, the terrestrial microwave data collection program (510b) and the satellite microwave data collection program (510a) perform the function of various microwave link data processing programs (e.g.654a) and uses pre-calculated transforms and filters to calculate satellite microwave precipitation and atmospheric water estimate data (626a) from satellite microwave link processed attenuation data (625a) and to transform the collected data directly to satellite microwave precipitation and atmospheric water vapor tiles or to LWC tiles. For example, in some embodiments the satellite microwave data collection program performs satellite microwave link snap to grid process (40000) to associate collected TSL and RSL values with satellite microwave pro forma links. 6.6.2.2 Microwave Data collection program (510b)

[00306] In a similar manner, terrestrial microwave data collection program (510b) collects, parses, and filters collected terrestrial microwave link attenuation data, tags the data, and stores it as terrestrial microwave link raw data (525b) in microwave link attenuation database (352b). 6.6.2.3 NWP Data Collection Program (532)

[00307] NWP data collection program (532) receives data generated by NWP models and programs from NWP model data source (341). The NWP data collection program parses NWP model data, associates it with the current cadence instance Mi, tags the data, and stores the parsed data as NWP data (526) to NWP ground weather database (353) and NWP model atmospheric database (329). 6.6.2.4 Map Data Collection Program (517)

[00308] Map data collection program (517) receives map from map data source (e.g.348). Map data received by the map data collection program may include elevation data as well as GIS and topographic map data. The map data collection program parses received GIS, elevation, and topographic map files in order to extract specific map data, such as, for example, elevation, ground cover such as vegetation and vegetation types, water features, and building or other structures at map coordinate locations, for example at specific latitude and longitude locations. Parsed map data is stored as map data (528) in map database (880). 6.6.2.5 Weather radar data collection program (512)

[00309] Weather radar data collection program (512) receives data files containing weather radar data from a weather radar data source (344), parses the received data files to extract collected data, for example reflectivity readings at discrete location points, associates the collected data with the current cadence instance M _i , for example by tagging the data with the cadence instance identifier Mi and with the cadence time stamp, and saves the measurements as radar raw data (521) to radar database (321). Data collected from radar data sources and saved to the radar database includes, for example, Composite Reflectivity, Reflectivity at Lowest Altitude, Base Reflectivity, Echo Tops (at multiple dBZ levels), Storm Relative Helicity, Probability of Severe Hal, Maximum Expected Hail Size, Lightning Density, Vertically Integrated Liquid, and Bright Band Top/Bottom. 6.6.2.6 Radar data processing program (611)

[00310] The radar data processing program (611) processes raw radar data (521), including

transforming the collected radar data to a radar tile layer of collection data tile stack Mi, to generate radar processed data (621). The radar data processing program transforms radar data from radar source grid coordinates to system tile layer coordinates, including interpolating or morphing the data to tile coordinates if radar and tile coordinates are not the same. For example, the radar data processing program transforms radar reflectivity data to a M _i radar reflectivity tile layer. The radar processed data is tagged with its own native time stamp, i.e. with a time stamp associated with the data by a weather radar time stamp. If more than one set of a particular type of radar data, for example two or more composite reflectivity data sets, in some exemplary embodiments the weather radar processing program processes the collected data set with a native time stamp closest in time to the cadence time stamp, including transforming the data to a radar tile layer, and discards older collected data sets. The radar processing program tags the processed collected radar data with the cadence identifier M _i and saves it as radar processed data (621) to radar database (322). In some exemplary embodiments, the radar data processing program performs additional pre- processing on the radar processed data, for example to extract storm objects or precipitation fields from reflectivity data. In a particular example, the radar data processing program generates storm object data from radar reflectivity data, e.g. using an image processing technique, tags the storm objects data with cadence identifier Mi and saves it as storm objects database (350). 6.6.2.7 Weather sensor data collection program (513)

[00311] The weather sensor data collection program (513) receives weather sensor data from one or more weather sensor data sources (346), which includes providers of weather-related collected data measured or otherwise gathered by an external weather sensor. External weather sensors can include weather sensors such as, for example, those listed in Tables 8 amd 9. Exemplary weather sensor data sources include ground weather stations, aggregators of ground weather station data, connected vehicle fleet data collection and management systems, commercial airlines, and any other aggregator and/or supplier of data from external weather sensors. Additionally, or alternatively, the weather sensor data collection program collects weather sensor data directly from a plurality of ground stations or from other stand- alone external weather sensor data sources. The weather sensor data collection program parses received weather sensor data to extract weather sensor collected data. , for example collected data including temperature or humidity values generated by weather sensors. In some embodiments the weather sensor data collection program uses snap to grid to normalize one or more weather sensor locations to a pro forma location. The weather sensor data collection program applies pre- calculated filters and transforms, for example one or more filters listed in Table 6, to collected weather sensor data in order to reduce volumes of data that are saved to system databases. In this way, the weather sensor data collection program filters out collected data points that are not required for further processing and aggregates large volumes of collected data points into statistical representations. These data set size reductions significantly reduce the amount of calculations required in subsequent forecasting by permitting forecast optimizations to be used. The parsed and filtered data is associated with the current cadence instance Mi, tagged, and stored as weather sensor data (522) to the weather sensor database (323). 6.6.2.8 RVR ancillary data collection program (519)

[00312] RVR ancillary data collection program (519) collects RVR ancillary data including

location-specific values of parameters that are used for calculating Va and Vk such current runway light luminosity (I), current and historical Vk measured by RVR sensors at the airport, and background light intensity (BL), and stores the data and RVR ancillary data (529) to the RVR location and ancillary data database (997). 6.6.2.9 Additional data collection programs

[00313] In addition to the exemplary types of data collected from exemplary data sources discussed herein, the system can collect and process data from any data source, referred herein as other info data source (347), that is configured to provide data. Other info data collection program (514) receives other information from other info data source, parses the collected data, associates it with the current cadence instance Mi, tags the data, and stores the parsed data as other info data (523) to other info database (324). 6.7 Offline/Background Processing Server (330)

[00314] Continuing to refer to Figure 2, a second server (including a data processing component) is an offline/background processing component that retrieves updates from the information collection and normalization server (310), from the system database (320), and from external databases (349). The offline/background processing server (330), as illustrated in Figure 14, comprises one or more computer systems similar to the exemplary server illustrated in Figure 2. The offline/background processing server executes processes and programs to generate transforms, filters, time series rule ML models, and other trained predictive models that other servers implement to calculate and forecast weather data. The offline/background processing server also executes a series of background and scheduled programs that recalculate and/or update information related to the transforms, filters, precipitation, fog, and RVR machine learning models and the underlying reference tables that these models rely upon. [00315] The offline/background processing server executes processes and programs to generate, pre-calculate, and update filters and filter parameters that the server and other servers use to filter out erroneous, redundant, or otherwise unneeded collected data points, to aggregate collected data points to reduce data volumes saved to the databases and improve the confidence in the stored data, and for translating collected information into formats usable by other servers and programs of the system. [00316] The offline/background processing server also pre-calculates and updates pre-calculated filters and pre-calculated transforms for translating collected information into formats usable by other servers and programs of the system; the process of generating transforms and filters is discussed below. The server also calculates, trains, and updates the machine learning models used by other servers to generate weather parameter data. For example, the server produces trained ML model(s) for inferring whether combinations of collected and generated data imply that atmospheric moisture will be present as water vapor, rain, snow, or fog. [00317] The server performs non-time critical processing of collected data and non-time critical updating of low-temporal resolution calculations and modeling, as well as non-time-sensitive data processing on collected information, and periodic processing to update longer term models and the fog inference rules (921). [00318] Processing is carried out by one or more processors (605) running specialized programs as described below. The programs are stored in or executed in transient or persistent memory (600). The data generated by these executing programs are written back to the system database and are shared with the other servers in the system either directly or through the database. 6.7.1 Programs of the offline/background processing server

[00319] Programs operating on the offline/background server pre-calculate filters and transforms used by programs operating on the same and other servers to rapidly process collected data to filter data, transform data to system coordinates and tiles, map microwave link endpoint locations and mobile weather sensor locations to pro forma location, locations to pro-forma locations, map microwave links to pre-calculated pro forma links, and calculate generated collected data, for example precipitation and atmospheric water vapor estimates. [00320] Other programs process collected data into other forms, as described herein. These

processing programs may be integrated into the data collection programs of the information collection and normalization server (310), may be executed as stand-alone programs on the offline/background processing server (330), or may be executed as part of the cadence pre- processing on the modelling and forecasting server (360). [00321] One or more data processing programs may be executed on at least one of the servers (e.g. server 310 during collection processes, server 330, or server 360 during post-collection processing of a cadence cycle) . These programs perform many functions, some of which are to apply the pre-calculated filters to collected information to remove data that is extraneous, erroneous, distorted, or otherwise unreliable in order to improve accuracy of the processed results. Additionally, these programs may apply pre-calculated transforms in order to generate data in a new or converted form from previously collected and/or processed data, and may further apply the trained ML models to generate new and inferred data from the collected and processed data. Alternatively, the functions of these data processing programs may be incorporated into one or more collection or forecasting programs. [00322] The data generated by each of these executing programs, on which ever server they are executed, are written back to the system database and are shared with the other servers in the system either directly or through the database. 6.7.1.1 Weather sensor data processing program (612)

[00323] The weather sensor data processing program (612) reads collected weather sensor data (522) from weather sensor database (323) and pre-processes the data to produce weather sensor processed data (622). The weather sensor data processing program pre-processes weather sensor data to associate the collected data with metadata and ancillary data, for example weather sensor location or a pro forma grid location. [00324] The weather sensor data processing program uses pre-calculated weather sensor data

transform to transform data from weather sensor locations to system-derived tiles.

Transforming the data to tiles can include snapping weather sensor measurements to nearest ground level microwave grid points, binning measurements at locations, and interpolating location-specific measurement data to tile locations, or associating collected weather data with one or more microwave link area of effects. [00325] In an embodiment, the weather sensor data processing program filters out possibly

erroneous mobile weather sensor data by comparing weather parameter data collected from vehicle mounted weather sensors to current predicted weather parameter data and excluding weather data measurements from vehicle-mounted weather sensors that are out of phase or inconsistent with collected or predicted data. This filtering reduces the amount of data that must be subsequently processed, thereby reducing the computational complexity in the modelling and forecast server. [00326] In an embodiment, the weather sensor data processing program filters out erroneous data by excluding weather parameter data collected from vehicle-mounted weather sensors under conditions that are known to produce unreliable or potentially erroneous measurement results. For example, if a vehicle-mounted outside temperature sensor is inaccurate when the vehicle is traveling at less than 25 mph, the weather sensor data processing program filters out measurements from the sensor that were recorded when the vehicle was moving at less than 25 mph. In further embodiments, the weather sensor data processing program filters out other erroneous or distorted vehicle weather sensor data measurements, based upon the operational characteristics of one or more of current vehicle-mounted sensor readings, past vehicle- mounted sensor readings, collected weather data from other sources, and forecast weather data from the forecasting algorithms of the system. [00327] In an embodiment, the weather sensor data processing program can use one or more trained ML models as filters to identify for filtering out of normal range data. [00328] A partial list of filters that can be used by the weather sensor data processing program to filter vehicle weather sensor data that may be obtained from various external data sources is provided in the table below and Table 6. The filters are pre-configured or calculated, and in some embodiments re-calculated, by the weather sensor data processing program (612).

TABLE 10: Filters Used by Weather Sensor Data Processing Program

[00329] The weather sensor data processing program (612) completes processing of the weather sensor data (346) by transforming the filtered, corrected, and location-binned data to tiles of one or more weather sensor collected data tile layers. The weather sensor data processing program uses mobile weather sensor data transforms, for example a vehicle weather data to tile transform, to transform data from mobile sensor data measurement locations to system- derived tiles. In a particular exemplary embodiment, the weather sensor data processing program transforms mobile sensor data to tiles using a mobile weather sensor data transform that encodes multiple pro-forma locations. In this embodiment, the weather sensor data processing program replaces the geographic location of the weather sensor data with a pro forma geographic location in order to bin the data by geographic location. Binning of weather sensor measurements to tiles can include pruning measurements to retain only as many measurements as are needed to achieve a specified level of confidence in a parameter value for each tile and discarding unneeded measurements, thereby reducing the amount of information that is saved and further processed. [00330] Weather sensor processed data (622) and associated metadata and ancillary data are stored to weather sensor database (323). This information is then made available to weather prediction and forecasting system, as well as statistical, regression, and correlation components of the various processing, modelling, forecast, and prediction programs of the system. [00331] In an alternative exemplary embodiment, one or more of the weather sensor filtering and processing operations described in this section in relation to the weather sensor data processing program are carried out by the weather sensor data collection program prior to saving collected weather sensor data to the weather sensor database (323). 6.7.1.2 Other information data processing program (613)

[00332] Other info data processing program (613) pre-processes other info data and stores processed data as other info processed data (623) to other info database (324). Pre-processing of other info data can include using a pre-calculated transform to transform data from other info data coordinates to system-determined tile locations including determining averaged or interpolated tile data values from other info data coordinate values if tile resolution is different (either lower or higher) than the other info data coordinate resolution. 6.7.1.3 Satellite Microwave Link Data processing program (615a)

[00333] The satellite microwave link data processing program pre-processes satellite link collected data (525a), which includes signal attenuation values, to produce satellite microwave link processed attenuation data (625a). The satellite microwave link data processing program preprocesses the satellite microwave link collected data to associate attenuation values with any missing metadata and/or ancillary microwave link infrastructure data including satellite antenna IDs, ground station IDs, ground station locations including latitude and longitude, and satellite microwave signal transmit frequency, bandwidth, and polarization. Any required microwave link infrastructure data, e.g., ancillary data or metadata, that was not included in data received from a satellite network data source (340a) is requested from the source by the information collection and normalization server (310), or is obtained from one or more system databases (320). The satellite microwave link data processing program carries out satellite microwave link snap to grid process (40000) to map satellite microwave link endpoints with pro forma locations and a pre-calculated pro forma satellite microwave link and to associate link TSL and RSL values with the pro forma link. The satellite microwave link data processing program also normalizes collected data to reconcile disparate TSL and RSL measurement reporting formats used by the data suppliers. [00334] The satellite microwave link data processing program error checks satellite microwave link collected data to remove invalid or inconsistent information, and to filter link information that is not usable in subsequent processing. For example, the satellite microwave link data processing program retrieves a satellite microwave link frequency filter from the transform and filter database (393) and uses it to filter out collected data from links that are transmitting on a frequency channel that is not a microwave channel. In another example , the satellite microwave link data processing program retrieves a satellite microwave link received signal strength filter from the transform and filter database and uses the filter to filter out satellite microwave link collected data with received signal strength below a specified threshold. This filter removes inactive links and links for which the signal strength was not properly measured. In another example, the missing data or data including received signal strength below the specified threshold is replaced with historical data. An expiration time period is associated with historical data and data that is older than a specified time interval, for example, data that is older than 5 minutes or data that is older than ten minutes is considered expired and is not used to substitute missing data. [00335] The satellite microwave link data processing program (615a) carries out a baseline creation process to pre-calculated baseline transforms that can be applied to satellite microwave link attenuation data (625a) to calculate the dry attenuation for the link. The satellite microwave link data processing program periodically performs satellite microwave link transform creation process (30000), described below, to generate satellite microwave link transforms that include equations to calculate and map satellite microwave link attenuation-based atmospheric weather parameter data, for example one or more of precipitation, LWC, and atmospheric water vapor estimate data to tiles using satellite microwave link processed attenuation data (625a). In some embodiments the satellite microwave link data processing program carries out combined terrestrial and satellite microwave link transform creation process to pre-calculate transforms that include equations to calculated weather parameter data using both satellite and terrestrial processed microwave link attenuation data (625a, 625b). In some embodiments, the satellite microwave link data processing program also pre- calculates transforms and filters for pruning erroneous or non-useful measurements. In some embodiments the satellite microwave link data processing program carries out fog transform creation process (4000) to pre-calculate transforms and filters useful for converting microwave attenuation collected data to weather parameter data including, for example, atmospheric water vapor and LWC estimates on or more system tile layers. [00336] The satellite microwave link data processing program optionally performs additional pre- processing to isolate non-baseline attenuation in link attenuation collected data using the pre- calculated baseline transforms. In an exemplary embodiment, the satellite microwave link data processing program loads a pre-calculated satellite microwave link baseline transform and uses the baseline transform to determine non-baseline or wet attenuation (i.e. attenuation caused by atmospheric water vapor, precipitation, some other hydrometer, or other interference). In a particular embodiment the satellite microwave link data processing program compares wet attenuation to a wet attenuation threshold, encoded in a wet attenuation filter, and discards a collected data point if wet attenuation of that data point is below the threshold. In this manner, the satellite microwave link data processing program removes links with insufficient wet attenuation to be useful for predicting atmospheric water vapor or precipitation intensity values. Filtered and transformed data is stored as satellite microwave link processed attenuation data (625a) in the satellite microwave link attenuation database (352a). [00337] In some exemplary embodiments, the satellite microwave link data processing program carries out microwave precipitation, atmospheric water vapor, and LWC estimate calculation method to calculate microwave precipitation, atmospheric water vapor, and LWC estimates. 6.7.1.3.1 Exemplary methods for pre-calculating transforms and filters

6.7.1.3.1.1 Illustrative satellite microwave link transform creation process

[00338] Figure 15 depicts a flowchart illustrating an exemplary satellite microwave link transform creation process (30000) performed by the satellite microwave link data processing program (615a) to create and store, in transform and filter database (393), pre-calculated filters and transforms for use in processing satellite link data including signal attenuation values in satellite microwave raw data (525a). The satellite microwave link data processing program performs this process prior to receiving satellite link collected data including signal attenuation information for processing. In an alternate embodiment, a filter and transform program (not shown), distinct from the satellite microwave link data processing program and operating on the background/processing server, executes satellite microwave link transform creation process to create and store the filters and transforms. The pre-computed filters and transforms are stored in in transform and filter database (393). The process steps are repeated for each satellite and earth station location pair in a geographic region within which satellite microwave atmospheric precipitation and water vapor estimates are calculated. [00339] Satellite microwave link transform creation process (30000) begins at step (31000) with the satellite microwave link data processing program dividing a representation of the atmosphere into layers by one or more altitude strata. For example, referring to Figure 12, the satellite microwave link data processing program calculates wet layer (10900) and dry layer (10990) and wet sub-layers (10935, 10945, 10955) divided by altitude strata such as altitude strata (10930, 10940, 10950). [00340] The wet sub-layers can each include a different proportion of the water vapor contained in the wet layer. Measured or estimated altitude strata such as the 0 ^o C isotherm, the tropopause, and altitude strata (10930, 10940, 10950) can be selected by the satellite microwave link data processing program to divide wet layer (10900) into sub-layers that correspond to atmospheric conditions local to earth station (10030) or local to a geographic region covered by a ground level grid (80200) and atmospheric grid (80100). Atmospheric conditions used to select altitude strata can include, for example, historic data including vertical distribution of water vapor in the atmosphere for a location or usual cloud density and height for a location, and NWP collected processed data or weather sensor weather parameter data including atmospheric pressure and temperature variation by altitude and modeled or predicted local cloud cover. [00341] In an exemplary embodiment, the satellite microwave link data processing program assigns each wet sublayer a percentage amount of satellite microwave link wet attenuation. In an illustrative example, if the wet layer (10900) represents the troposphere, 90% of atmospheric water vapor is located below altitude strata (10940), and 50% of atmospheric water is located below the first altitude strata (10950), then 50% of wet attenuation is assigned to the first wet sub-layer (10955), 40% of wet attenuation is assigned to the second wet sub-layer (10945), and 10% of wet attenuation is assigned to the third wet sub-layer (10935). Assigning proportional attenuation amounts to atmospheric layers enables the precipitation modeling and forecasting system to estimate atmospheric water in each atmospheric layer that a satellite microwave link passes through. [00342] Referring to Figure 9, in another example embodiment the satellite microwave link data processing program can divide the atmosphere into layers bounded by ground level, 0 ^o C isotherm, and the tropopause.. In this example, the atmosphere is divided into a first, 500 meter, layer (80500) between ground level and a 0 ^o C isotherm, a second, isotherm, layer (80520) between the 0 ^o C isotherm and tropopause, and a third, upper atmosphere, layer (80540) between the tropopause and a satellite. In this example, the 500 meter and isotherm layers are wet sub-layers and the upper atmosphere layer is dry. In an exemplary embodiment the satellite microwave link data processing program assumes that the majority of wet attenuation, for example 90% of wet attenuation, is caused by 500 meter layer, the remainder of wet attenuation, for example 10%, is caused by the isotherm layer, and that the remainder of the atmosphere between the tropopause and the satellite does not cause any wet attenuation. [00343] At step (30200) the satellite microwave link data processing program retrieves satellite microwave link infrastructure data including, from the satellite microwave link ephemeris information database, ephemeris data including data defining satellite path (10010) and fixed earth station locations (latitude, latitude, altitude). If, as depicted in Figure 9, pro forma satellite locations are defined relative to an atmospheric grid (80100) rather than a pro forma satellite path (10100), the satellite microwave link data processing program does not retrieve satellite ephemeris data and step (30200) is skipped. [00344] At step (30300) the satellite microwave link data processing program determines satellite pro forma locations (e.g., 10100–10118, 80110) and pro forma earth station locations (e.g., 80211, 80212). Referring to Figure 9, the satellite microwave link data processing program subdivides a ground level area of a geographic region into cells of a ground level grid (80200) with pro forma earth station locations located within each cell. In a similar manner, the satellite microwave link data processing program divides an atmospheric area above the ground level grid into an atmospheric grid (80100), located at a typical satellite orbit elevation (e.g. at about 500 miles for a LEO satellite orbit), and populates the atmospheric grid (80100) with a plurality of satellite pro forma locations (e.g. pro forma location (80110)). The satellite microwave link data processing program can create multiple atmospheric grids, for example atmospheric grids located at both LEO and MEO elevations (not shown). [00345] Referring to Figures 11 and 12, in an alternate embodiment, the satellite microwave link data processing program subdivides a pro forma satellite path (10010) by multiple pro forma satellite locations (10100–10118), wherein each pro forma satellite location corresponds to a location of the subject satellite at an incremental point in time. In an embodiment, pro forma satellite locations are separated by 1 minute time intervals. In other words, a distance between pro forma location (10100) and pro forma location (10110) is a distance that the subject satellite travels in one minute’s time. The satellite microwave link data processing program can also populate a ground level grid (not shown) with pro forma earth station locations (e.g., 80211, 80212). [00346] At step (30400) the satellite microwave link data processing program pre-calculates the 3D geometry of each of multiple pro forma satellite microwave links (e.g., 10200– 10218, 80600). Each pro forma satellite microwave link extends between a known earth station location (e.g., 10030, 80510) or a pro forma earth station location and one of the multiple pro forma satellite locations (e.g., 10100– 10118, 80110). [00347] At step (30500) the satellite microwave link data processing program subdivides each pro forma satellite microwave link into multiple satellite link segments at atmospheric strata intersection points. For example, satellite microwave link data processing program (615a) subdivides pro forma link (80600) into satellite link segments (80615, 80625, and 80635) at intersection points (80605, 80610, and 80110). [00348] At step (30600) the satellite microwave link data processing program calculates a baseline, or dry, attenuation for each pro forma satellite microwave link and satellite link segment as previously discussed in relation to Figure 14. In an embodiment, a baseline attenuation is calculated for each satellite link segment. The satellite microwave link data processing program creates baseline attenuation transforms, using calculated baseline attenuations, for each pro forma satellite microwave link and/or satellite link segment and stores the baseline transforms in the transform and filter database (393). [00349] At step (30700) the satellite microwave link data processing program precomputes

additional filters and transforms that can be used by the satellite microwave data collection program (510a) to associate microwave link characteristics to pro forma links. The satellite microwave link data processing program creates filters that can be used by the satellite microwave data collection program to exclude measurement data based on selected criteria. For example, a filter can exclude attenuation measurements from satellite to earth station links with an elevation angle of 5 degrees or lower and measurements that include less than a threshold amount of attenuation or wet attenuation. Filters can also exclude measurements from satellite to earth station links where the earth station is located greater than a threshold distance from the center of a satellite signal footprint. Filters can exclude measurements based on additional criteria. The satellite microwave link data processing program stores satellite microwave link filters are in the transform and filter database (393). [00350] The satellite microwave link data processing program calculates satellite network link-to- grid transforms and satellite network grid-to-tile transforms for use by satellite microwave link precipitation program (654a) when calculating satellite microwave weather parameter data, for example precipitation, LWC, or atmospheric water estimates from wet attenuation, i.e. from baselined attenuations, and when mapping the calculated transforms to tiles of one or more satellite microwave precipitation and atmospheric water vapor tile layers (2022a) and LWC tile layers (2048). In an exemplary embodiment, the satellite microwave link precipitation program generates a link-to-grid and grid-to-tile transform that includes each pro forma satellite microwave link in a geographic region. In an exemplary method, wet attenuation is assumed to be due to effects of the wet atmosphere layer (10900) and the link- to-grid and grid-to-tile transform transforms are determined for each satellite link segment that passes through the wet atmosphere layer. Link-to-grid transforms include attenuation-to- weather parameter equations with variables that are dependent on one or more microwave link characteristics, for example one more of: microwave link signal frequency, microwave link transmit power, and microwave link polarization; satellite link segment path length through atmosphere layer; and atmospheric temperature. [00351] Link-to- grid transforms include graphical clipping or projection transforms to project each satellite link segment to a corresponding plane. For example, and referring to Figure 9, satellite link segment (80615), which traverses the 500 meter atmospheric layer, is projected to a 500 meter plane, which is co-located with lower grid (80200) and satellite link segment (80625), which traverses the 0 ^o C isotherm layer, is projected onto a 0 ^o C isotherm plane, which is co-located with upper grid (80300). The satellite microwave link data processing program pre-calculates transforms to project satellite link segment (80615) onto the 500 meter plane and satellite link segment (80625) onto the 0 ^o C isotherm plane. [00352] In an embodiment, the satellite microwave data processing program generates link-to-grid transforms for use in satellite microwave link precipitation attenuation-based weather parameter data calculations in a manner similar to that described for antenna mast based link to grid transforms. A typical length of a satellite microwave link segment, or segments, that traverse wet atmosphere layers (e.g. satellite link segments 80615, 80625) are substantially similar to lengths of terrestrial satellite network backhaul microwave link and can be used to subdivide each satellite microwave link or link segment into multiple equal length segments, each segment with a link point at each end of the segment, and determine an area of influence for each link point. Precipitation estimates for each satellite link segment can be transformed to a ground level static microwave grid based on determining grid points of the static microwave grid that are located with areas of influence of one or more satellite link segment link points. [00353] The described method is used to generate equations to transform attenuation associated with each satellite link segment one or more of precipitation, atmospheric water content, and LWC on a static microwave grid corresponding to the plane onto which the satellite link segment is projected. [00354] The satellite microwave link data processing program pre-calculates equations to associate a portion of the satellite link attenuation with each of the satellite link segments. The satellite microwave link data proceessing program then subdivides each satellite microwave link or link segment into multiple equal length sub-segments, with a link point at each end of the sub-segment. The satellite microwave link processing program associates a portion of the link segment attenuation with each link point, and pre-calculates an area of influence for each link point. The satellite microwave link data processing program pre-calculates equations to transform pre-processed attenuation measurements to grid points of a static microwave grid associated with the plane on which the link segment has been projected. The equations transform microwave attenuation measurement values for each atmospheric link segment to weather parameter data at static microwave grid points covered by the area of influence of the link point. For example, the satellite microwave precipitation program pre-calculates equation to transform an attenuation measurement for satellite link segment (80615) to precipitation, atmospheric water vapor, and fog LWC estimates on a 500 meter static microwave grid, or alternatively on a ground level static microwave grid, based on determining grid points of the static microwave grid that are located with areas of influence of one or more satellite link segment link points. Similarly, attenuation collected data for satellite link segment (80625) can be transformed to precipitation, atmospheric water vapor, and LWC estimates on a 0 ^o C isotherm static microwave grid. The satellite microwave link data processing program pre-calculates, for all pro forma link segments and for all wet atmospheric layers, link-to-grid transforms that are used by the satellite microwave precipitation program to generate precipitation, LWC, and atmospheric water vapor estimates at grid points of static microwave grids corresponding to each atmospheric wet sub-layer. [00355] In an additional exemplary embodiment, the transforms are configured to generate gridded microwave attenuation measurements as well as gridded estimates calculate based on precipitation. In an embodiment the gridded microwave attenuation is used by other processing programs to generate atmospheric weather parameter data, for example by the fog inference program to generate atmospheric fog LWC. [00356] The satellite microwave link data processing program pre-calculates grid-to-tile transforms to transform gridded precipitation, atmospheric water vapor, and fog LWC estimates to satellite microwave precipitation and atmospheric water vapor collected data tile layers. A collected data tile layer is associated with each static microwave grid and equations to transform gridded estimates to tiles the associated collected data tile layer are pre-calculated. For example, grid-to-tile transforms include pre-calculated equations to transform measurements from the 0 ^o C isotherm grid to a 0oC isotherm collected data tile layer and pre- calculated equations to transform measurements from the 500 meter gird to a 500 meter collected data tile layer. [00357] The satellite microwave link data processing program can calculate multiple transforms for each pro forma microwave satellite link and satellite link segment including, for example, transforms that each include one of multiple possible downlink signal frequencies and signal polarizations. This enables the system to calculate precipitation, atmospheric water vapor, and LWC estimates when and attenuation measurement and signal characteristics data including, for example signal polarization, is received without requiring advance knowledge of the transmitted signal characteristics. If a satellite changes signal transmit frequency or polarization, for example, the system can retrieve transforms that correspond to the new frequency and/or polarization. [00358] At step (30750), the satellite microwave link data processing program saves transforms and filters to transform and filter database (393) following which, at (30800) the satellite microwave link transform creation program ends. [00359] An alternative exemplary processes (not shown), substantially similar to process (30000), can be used to calculate satellite microwave attenuation-to-cloud water content transforms useful, for example, for determining atmospheric cloud water content estimates. [00360] The satellite microwave link data processing program also performs consistency checking of microwave link information in the databases. For example, if a microwave link is added or removed from the database, but the precipitation models rely on microwave link information from that link, the link coverage models need to be updated for the new link topology. The consistency checking component performs these updates. Similarly, if a microwave link is not reporting link attenuation information for a period of time, or is reporting clearly erroneous information, the satellite microwave link data processing program identifies this link for investigation, and optionally removes the link from the link topology models until the problem can be identified and fixed. Similarly, if a microwave link frequency or polarization changes, the link topology models are updated as necessary. These changes to the underlying link topology models are made on an as-needed basis. 6.7.1.3.2 Pre-processing satellite microwave link data

[00361] Referring to Figure 14, the satellite microwave link data processing program pre-processes satellite link data including signal attenuation information (525a) to produce pre-processed satellite microwave link processed attenuation data (625a). The satellite microwave link data processing program preprocesses satellite link data including signal attenuation information to associate the measurement data with any missing metadata and/or ancillary data including satellite antenna IDs, ground station IDs, ground station locations including latitude and longitude, and satellite microwave signal transmit frequency, bandwidth, and polarization. Any required ancillary data or metadata that was not included in data received from a satellite network data source (340a) is requested from the source by the information collection and normalization server (310), or is obtained from one or more system databases (320). The satellite microwave link data processing program calculates any missing link geometry including link length and atmospheric vector using ground station locations, elevation, and satellite ephemeris data or satellite inferred or calculated location and associates the calculated link geometry with link measurement data. The satellite microwave link data processing program also normalizes measurement data to reconcile disparate TSL and RSL measurement reporting formats used by the data suppliers. [00362] The satellite microwave link data processing program error checks satellite microwave link data to remove invalid or inconsistent information, and to filter link information that is not usable in subsequent processing. For example, the satellite microwave link data processing program retrieves a satellite microwave link frequency filter from the transform and filter database (393) and uses it to filter out measurements from links that are transmitting on a frequency channel that is not a microwave channel. In another example , the satellite microwave link data processing program retrieves a satellite microwave link received signal strength filter from the transform and filter database and uses the filter to filter out satellite microwave link measurements with received signal strength below a specified threshold. This filter removes inactive links and links for which the signal strength was not properly measured. In another example, missing data or data including received signal strength below the specified threshold can be replaced with historical data. An expiration time period is associated with historical data and data that is older than a specified time interval, for example, data that is older than 5 minutes or data that is older than ten minutes is considered expired and is not used to substitute missing data. [00363] The satellite microwave link data processing program optionally performs additional pre- processing to isolate non-baseline attenuation in link measurement data. The satellite microwave link data processing program can load a previously pre-calculated satellite microwave link baseline transform, associated with each link, and use the baseline transform to determine non-baseline or wet attenuation which is a measure of attenuation caused by atmospheric water vapor, precipitation, some other hydrometer, or other interference. The satellite microwave link data processing program can compare wet attenuation to a wet attenuation threshold, encoded in a wet attenuation filter, discarding a measurement if wet attenuation is below the threshold. In this manner, the satellite microwave link data processing program removes links with insufficient wet attenuation to be useful for predicting atmospheric water vapor or precipitation intensity values. Filtered and transformed data is stored as satellite microwave link processed attenuation data (625a) in the satellite microwave link attenuation database (352a). 6.7.1.4 Terrestrial Microwave Link Data processing program (615b)

[00364] The terrestrial microwave link data processing program (615b) provides a series of non- time critical processes related to the microwave link information collected by the system and updates the underlying model maps for the microwave link coverage. Additional calculations are performed by several independent processes that are executed independently on the server on an as needed basis. In some embodiments, the Terrestrial Microwave Link Data processing program carries out a combined terrestrial and satellite microwave link transform creation process to pre-calculate transforms for generating weather parameter data from a combination of satellite and terrestrial processed attenuation data (625a,b), as described herein. In some embodiments the terrestrial microwave link data processing program carries out fog transform creation process (4000) to pre-calculate transforms and filters useful for converting microwave attenuation collected data to weather parameter data including, for example, atmospheric water vapor and LWC estimates on or more system tile layers. [00365] In some exemplary embodiments, the terrestrial microwave link data processing program carries out the microwave precipitation, atmospheric water vapor, and LWC estimate calculations in order to determine microwave precipitation, atmospheric water vapor, and LWC estimates associated with microwave links. 6.7.1.4.1 Illustrative combined terrestrial and satellite microwave link transform creation process

[00366] In an exemplary embodiment, the system implements a combined satellite and terrestrial microwave link transform creation process substantially similar to satellite microwave link transform creation process (30000) to pre-calculate transforms for calculating weather parameter data based on combined microwave link attenuation measurements from two or more microwave network data sources. By combining microwave link attenuation measurements from multiple types of networks, for example from a terrestrial microwave data source and from a satellite microwave data source, the system can achieve greater coverage than it would with any particular microwave link network or network type alone. This provides additional accuracy improvement in area where a single microwave link network is sparse. Embodiments of the system described herein dramatically increase geographic coverage by combining terrestrial microwave link collected data with satellite microwave link collected data, thereby enabling generation of weather parameter data - estimates in regions not covered by terrestrial microwave links. In additions, combining satellite and terrestrial microwave link data increases the number of overlapping links, for example satellite microwave links overlapping terrestrial microwave links, providing the system with increased information about attenuation conditions and thereby enabling the system to generate precipitation estimates with increases associated confidence metrics. [00367] Referring to Figure 16, portions of four types of overlapping microwave networks are shown: a portion of a terrestrial point-to-point microwave network (S210); a portion of a dynamic terrestrial microwave network (S220); a portion of a mobile satellite microwave network (S230); and a portion of a stationary satellite network (S240). The microwave networks are shown overlaying a ground level static microwave grid (S100) of grid points, each grid point represented by a solid circle. Ground level static microwave grid (S100) includes, for example, grid points (S101, S102, S103, and S104). [00368] Each satellite microwave network includes multiple microwave links and link segments, for example terrestrial point-to-point link (S018b) and stationary satellite microwave link segment (S048a). Each microwave link is illustrated as a dash or dash-dot formatted straight line surrounded by a similarly formatted oblong shape that represents an area of influence of each microwave link or link segment. Weather parameter data values, for example one or more of precipitation, atmospheric water vapor, and LWC estimates, calculated based on measured attenuation of a particular microwave link, are mapped to static microwave grid points that are enclosed by the microwave link’s area of influence. For example, weather data parameter values, e.g. atmospheric water vapor estimates, calculate from attenuation of microwave link (S018b) are mapped to static microwave grid cells within the area of influence of the link, for example grid cell (S104). [00369] Stationary satellite microwave link segments and mobile satellite microwave link segments (e.g.S038a) each represent a lower atmosphere portion of a satellite microwave link projected onto ground level. For example, referring to Figure 12, each satellite microwave link segment is similar to satellite link projection (10610) of satellite link segment (10550) passing through first wet sub-layer (10955) and projected onto ground level. In additional embodiments, satellite microwave link segments can represent projections of different segments of satellite microwave links projected to ground level. For example, a ground level satellite microwave link segment can represent a portion of a satellite microwave link passing through the first and second wet sublayers (10955, 10945) or through the entire wet layer (10900). [00370] The terrestrial point-to-point microwave network (S210) includes antenna masts (S010a, S010b, and S010c) which are interconnected via terrestrial microwave links (S018a, S018b). Terrestrial dynamic microwave network (S220) includes mobile microwave link endpoints (S020a, S020b, S020c) each with at least one terrestrial microwave link (S028a, S028b, S028c) with antenna mast (S010b). Each mobile microwave link endpoint can represent, for example, a person or vehicle carried mobile microwave transceiver. In additional embodiments, not shown, the terrestrial dynamic microwave network includes additional mobile microwave link endpoints and mobile microwave link endpoints with microwave links to one or more additional antenna masts. Terrestrial microwave networks can include many more mobile microwave link endpoints and/or antenna masts. By way of example and not limitation, the networks can include hundreds of antenna masts and mobile microwave link endpoints, and can further include additional network elements, for example small- cell/base stations and CPE routers. [00371] The mobile satellite microwave network includes earth station (S030) and three ground level mobile satellite microwave link segments (S038a, S038b, and S038c) which are projections of low atmosphere segments of microwave satellite links between the ground station and mobile satellite locations (S035a, S035b, S035c). Mobile satellite locations can represent locations of different mobile satellites or different locations of a single mobile satellite as it moves. For clarity only a limited number of ground level mobile satellite microwave links are illustrated. A mobile satellite microwave network can include many more earth stations and many more ground level satellite microwave links. By way of example and not limitation, the network can include hundreds of ground stations. [00372] The stationary satellite microwave network includes earth stations (S042 and S044) and two ground level stationary satellite link segments (S048a, S048b) which are projections of low atmosphere segments of microwave satellite links between the ground stations and stationary satellite location (S045). A stationary satellite microwave network can include many more earth stations and many more ground level satellite microwave links. By way of example and not limitation, the network can include hundreds of ground stations. [00373] In a first exemplary embodiment, a microwave link data processing program (615a,b) carries out the combined satellite and terrestrial microwave link transform creation process. The microwave link data processing program pre-calculates link-to-grid transforms that map attenuation-based weather parameter data estimates from terrestrial microwave links and from ground level satellite microwave link to grid points of the ground level static microwave grid. The link-to-grid transforms include equations to aggregate weather parameter data values from two of more overlapping microwave links at individual static microwave grid points. In an exemplary embodiment, the microwave link data processing program determines that two or more microwave links overlap a particular ground level static microwave grid point if areas of influence associated with each of the two or more microwave links encompass the grid point. For example, static microwave grid point (S103) is located within areas of influence of terrestrial point-to-point microwave link segment (S018b), stationary satellite ground level microwave link segment (S048a), and mobile satellite ground level microwave link segment (S038a). The microwave link data processing calculates equations to aggregate weather parameter data values based on each of these links at grid point (S103). [00374] In an embodiment, the microwave link data processing program constructs a combined link- to-grid transforms that include microwave links from all networks that overlay a particular geographic area. For example, the microwave link data processing program can construct a link-to-grid transform that includes all microwave links and link segments illustrated in Figure 16. In an alternative embodiment, the microwave link processing program selects some available microwave links and link segments for inclusion in a combined link-to-grid transform while excluding. The microwave link data processing program can select microwave links for inclusion based on, for example, one or more of microwave network type and individual or group microwave link characteristics. For example, the microwave link processing program can construct a link-to-grid transform using only links with stationary link endpoints, for example using links of terrestrial point-to-point microwave network (S210) and stationary satellite microwave network (S240). [00375] Weather parameter values based on attenuation of multiple microwave links are aggregated at a static microwave grid point, for example by calculating an average value, e.g. an average weighted by confidence metrics associated with microwave link data sources or based on characteristics of individual microwave links. For example, in an exemplary embodiment static terrestrial microwave links are associated with a higher confidence than satellite microwave links and confidence is increased for shorter distance microwave links as compared to longer microwave links. In another exemplary embodiments, link-to-grid transforms encode one or more additional or alternative weather parameter data value aggregation schemes, for example selecting a most common value or selecting a value corresponding to the source associated with the highest confidence level. In some embodiments, the link-to-grid transforms include equations for calculating a confidence metric associated with a calculated weather parameter data value, for example a confidence in a precipitation estimate value, based on one or more criteria including, for example, a number of overlapping microwave links at a static microwave grid point and confidence metrics associated with each overlapping microwave link. The program calculates grid-to-tile transforms to transform attenuation-based weather parameter data at static microwave grid points to system tiles, for example to a ground level precipitation tile layer (2022a,b) and LWC tile layer (2048). In an exemplary embodiment the grid-to-tile transforms include equations to calculate a confidence metric associated with a weather parameter data value of each tile based on confidence metrics associated with weather parameter data values that are transformed from one or more static microwave grid points to that tile. [00376] In a second exemplary embodiment, a microwave link processing program pre-calculates a link-to-grid transform that maps attenuation-based weather parameter estimates to separate terrestrial static microwave and satellite ground level static microwave grids. The program pre-calculates grid-to-tile transforms to transform weather parameter data values to system tiles. In some exemplary embodiments the link-to-grid transforms include equations to compute confidence metrics associated with weather parameter data values at each static microwave grid point and the grid-to-tile transforms include equations to calculate a confidence metric associated with each tile based on confidence gridded weather parameter value confidence metrics. 6.7.1.5 Analysis Programs

[00377] Analysis programs are independent programs that process one or more sets of data (e.g., satellite microwave link, terrestrial microwave links, vehicle sensor data, and/or map data) in order to enhance the accuracy of the subsequent weather parameter modelling. These programs are executed on the offline/background processing server (330) against information stored in the system database (320) in order to adjust collected data. The results are stored back to the system database when the analysis processes are complete. 6.7.1.5.1 Accuracy Improvement Analysis Program (640)

[00378] A first such independent process is the accuracy improvement analysis program

(640).Radar precipitation estimates have known limitations and often predict precipitation that does not reach the ground. Typical radar precipitation estimate accuracy can be as low as 50% when compared to ground truth precipitation measurements from rain gauges.

Precipitation estimates based upon microwave link attenuation measurements from terrestrial and satellite microwave links have an accuracy of approximately 90%. Terrestrial microwave links are close to the ground and provide diverse (spatial and temporal) measurement data but do not have complete coverage. The segment of a satellite link that is closest to the ground has similar characteristics. The accuracy of precipitation forecasts is improved when microwave link attenuation precipitation estimates are combined with other precipitation estimates from different precipitation estimating systems using different data sources (and in particular, weather radar), and this accuracy can be improved even more by correlation to known“ground truth” weather data from weather sensors in an area of influence of a microwave link. Accuracy improvements in precipitation estimates can be estimated by correlating the estimates made using remote sensing systems (such as radar estimated precipitation rates) with the estimated precipitation data based upon terrestrial and satellite microwave link attenuation data. Combining microwave link precipitation estimates (either one of terrestrial, satellite, or both) with radar precipitation estimates can improve the accuracy of the combined estimates by 40% as compared to radar precipitation estimates alone. The accuracy improvement estimates may be used to improve the accuracy of the subsequent precipitation or atmospheric water vapor modelling and to improve the accuracy of modelling of other phenomena or parameters, such as RVR or fog prediction, that is derived from precipitation and atmospheric water vapor modelling. [00379] In an embodiment, the accuracy improvement calculations of the present technology are based using terrain-type information collected by the system, radar-based precipitation estimates, terrestrial microwave link coverage, and satellite microwave link coverage, and identifying a pre-set improvement metric based upon the available precipitation estimates and their inherent accuracy under the data collection conditions (e.g. distance from the radar site, number of microwave links in the area) and the terrain types. The accuracy improvement analysis program is executed on a periodic basis to update a database of accuracy improvement scores associated with specific blending techniques. 6.7.1.6 Baseline attenuation determination program (641)

[00380] The Baseline Attenuation Determination program can carry out a baseline attenuation determination method to pre-calculate satellite microwave link baseline attenuation, as described herein. [00381] The baseline attenuation determination program (641), which determines“clear air”

attenuation adjustments for microwave links in order to calibrate the attenuation for each link based upon the power law equation and general weather conditions. The baseline transforms include equations to generate baselined attenuation values for calculating precipitation estimates from measured attenuation. In a similar manner, baseline attenuation determination program (641) and satellite microwave link data processing program (615a) are configured to determine a baseline or“dry air” attenuation for use in calculations related to fog inference, e.g., for fog LWC calculations.. A fog baseline attenuation includes attenuation when no fog and no precipitation is present. The programs encode the baseline“dry air” attenuation in fog baseline transforms and save the transforms to the transform and filter database. [00382] The process obtains each link’s attributes and then calculates the amount of attenuation that would normally be expected if there were no precipitation attenuation. These baseline attenuations may be determined, for example, by using link and local weather information such as link length, frequency, polarization, bandwidth, terrain characteristics, and other potential effectors of multipath, and slowly changing weather phenomena such as temperature and humidity. Alternatively, the baseline attenuation may be based upon historical information about the link or by a combination of current and historic

measurements. A baseline attenuation can be determined for each microwave link known to the system, written to one or more baseline attenuation transforms, and stored in a transform database. The baseline attenuation transforms can be applied to attenuation measurements, and the baseline attenuation subtracted from the reported measured attenuation, to isolate the measured attenuation due to precipitation. The result of this adjustment is that, before calibration, precipitation intensity values calculated based on the link’s measured attenuation, and thus the precipitation accumulations calculated from these precipitation intensity values, may be different than those recorded by rain gauges. They have the same trends, but the amplitudes are different, and the zero level may vary. There are many reasons for this phenomenon, such as changes in the environmental conditions (humidity, fog, water vapor, and atmospheric gasses), steady water bodies (rivers and lakes) in the space between the antennas, and more, such as for example changing the modulation state of the system. The baseline calibration is performed periodically. Adjusting the reported attenuation for microwave links by the baseline amount reduces the effects of these non-precipitation factors, and helps the system to more accurately measure precipitation. [00383] For example, the baseline attenuation value for one or more microwave links may be calculated using the following process: [00384] A) Determine baseline“clear” weather conditions in the area of the microwave link by obtaining humidity data from one or more ground weather sources. This data may be current and/or historical in nature. Optionally, several relevant humidity readings may be obtained and averaged. [00385] B) Calculate the baseline attenuation per unit distance (e.g. dB of attenuation per kilometer) in the area of the microwave link. Store this value in the system database as a baseline adjustment to be applied to new microwave link readings. [00386] C) Repeat the calculation of baseline amounts for other microwave links identified by the system until a zero value is determined for each area near a microwave link. [00387] In a similar manner, baseline attenuation determination program (641) and satellite

microwave link data processing program (615a) can determine a baseline or“dry air” attenuation for use in fog inference calculations. A fog inference baseline attenuation includes attenuation when no fog and no precipitation is present. [00388] In a similar manner, satellite microwave link data processing program (615a) can determine a baseline signal propagation for a microwave link, including an expected propagation due to ionosphere and dry troposphere. The baseline signal propagation can be used to determine an expected“dry delay” between a signal transmission time and signal reception time which. The“dry delay” can be used to determine, from a particular satellite microwave link propagation measurement, a“wet delay” that can be caused by an atmospheric hydrometer including, for example, atmospheric water vapor, atmospheric liquid water or fog, or precipitation. 6.7.1.7 NWP Data processing program (616)

[00389] The NWP data processing program (616) pre-processes NWP data and stores ground level processed data as NWP processed ground level data (619b) to NWP ground weather database (353) and NWP model processed atmospheric data (619a) to NWP model atmospheric database (329). Pre-processing of NWP data can also include creating and using a pre- calculated transform to transform data from NWP data coordinates to system-determined tile locations including determining averaged or interpolated tile data values from NWP data coordinate values if tile resolution is different (either lower or higher) than the NWP data coordinate resolution. NWP data processing program stores ground level data as NWP processed ground level data to the ground weather database and NWP model processed atmospheric data to the NWP model atmospheric database. 6.7.1.8 Map data processing program (618)

[00390] The map data processing program (618) pre-processes map data (528) to associate the map data with metadata and ancillary data, applies one or more pre-calculated transforms in order to convert data from map coordinates to system-determined tiles. The transformed and converted data, called map processed data (628) along with any associated metadata and ancillary data are stored to a database such as map database (880). 6.7.1.8.1 Coverage Maps

[00391] While the following discusses precipitation intensity, similar methods can be used to

recognize and compensate for inaccuracies in other parameters calculated by the precipitation modelling and forecasting system (300) such as, for example, atmospheric water vapor, fog intensity, and RVR. Given the characteristics of the (combined sources) satellite and terrestrial microwave links (e.g., topology, frequencies, link locations, polarization), the precipitation modelling and forecasting system identifies blind locations for each source, where precipitation intensities below specific precipitation intensities are inaccurate due to limitations of the collection method (e.g. radar occultation), and adjusts the precipitation intensity in those blind locations using additional information in the system. The microwave link data processing programs (615a,b) create a single coverage map per precipitation intensity value level, in which the areas of detectable precipitation at a specific intensity are identified (i.e. "for this network, this is our coverage for rain intensity at 5mm/hour, and this is our coverage when the rain intensity is 10 mm/hour"). [00392] The system creates a coverage map in a three stage process: [00393] Stage 1– define the satellite earth station map area. [00394] (a) Sort all participating earth stations according to geographical locations (longitude / latitude on a UTM grid). [00395] (b) Select a set of earth station end points of pro forma satellite-to-earth station links to define map area corners. Select the earth station located furthest to the north and to the west (earth station 1). Determine the pro forma link mapped to earth station 1 that extends furthest to the north and to the west (pro forma link 1). Select the earth station located furthest to the south and to the east (earth station 2). Determine the pro forma link mapped to earth station 2 that extends furthest to the south and to the east (pro forma link 1). Select the earth station located furthest to the north and the east (earth station 3). Determine the pro forma link mapped to earth station 3 that extends furthest to the north and to the east (pro forma link 3). Select the earth station located furthest to the south and the west (earth station 4). Determine the pro forma link mapped to earth station 4 that extends furthest to the south and to the west (pro forma link 4). [00396] (c) Define a rectangular zone that covers pro forma satellite-to-earth station links 1, 2, 3, and 4. [00397] Note: If other wireless network microwave links (e.g. cellular, point-to-point) are present in the map area, these links optionally may be added to the rectangular zone (and the zone size adjusted if necessary). [00398] (d) Expand this rectangular zone to cover the "area of influence" (see below) of all the satellite-to-earth station pro forma links within it. The defined and expanded rectangular zone encloses the earth station map area. [00399] Note that the map area can be duplicated at one or more vertical elevations above ground level to define a map volume that includes one or more atmospheric layers. For example, the map area can be duplicated on a plane corresponding one or more atmospheric layers including, a zero degree Celsius isotherm, one or more other isotherms or isobars, and one or more additional troposphere delineation layers. Each satellite-to-earth station pro forma link can be sub-divided into multiple satellite link segments, each of which includes endpoints defined by intersection of the pro forma satellite-to-earth station link with strata that separate atmospheric layers. [00400] Stage 2– segment microwave links into segments and points. [00401] (a) For each pro forma satellite-to-earth station link or satellite link segment in the defined map area or map volume, a recursive division is conducted to subdivide the link or satellite link segment into very small sub-segments that are equal in length, each sub-segment defined by 2 discrete points. [00402] This division is accomplished by going through the following process iteratively, until the length of each sub-segment is smaller or equal to a predefined distance. In an embodiment, a plot of attenuation along the length of a pro forma satellite-to-earth station link or satellite link segment is generated and the predefined distance is determined by finding the shortest sub-segment wherein a difference in attenuation greater than a threshold amount is observed between a start point and an end point of the segment. [00403] (i) Divide the pro forma satellite-to-earth station or satellite link segment into two equal sub-segments and define a middle point of the link or satellite link segment. After this step there are two sub-segments and three equally distributed points:

* Beginning point (antenna“a”, pro forma satellite or earth station location, or satellite link segment first endpoint),

* Ending point (antenna“b”, pro forma satellite or earth station location, satellite link segment second endpoint),

* Middle point. [00404] (ii) Divide each of the two new sub-segments in two and define a middle point for each sub-segment.

After this step we have four sub-segments and five equally distributed points. [00405] (iii) Iterate step ii) until all pro forma satellite-to-earth station links and satellite link segments are processed and the sub-segment sizes are below the predefined distance. [00406] Stage 3– determine coverage for different precipitation intensities. [00407] (a) The basic assumption of this stage is that the precipitation intensity is uniform for the entire area, and the coverage map identifies "blind spots" where the precipitation intensity below a specific precipitation intensity is undetectable. [00408] This approach allows a "threshold" precipitation intensity value to be defined, so that it can be understood what the area is in which precipitation at this intensity or higher is detectable. The real-time precipitation map enabled by the modelling and forecasting system (300) differentiates between different levels of intensity and enables precipitation at all levels of intensity above the threshold level to be seen. [00409] Area of influence calculations. [00410] The satellite microwave link data processing program divides the map area into a grid. The grid is a matrix of discrete points, and the distance between two points is defined by the lowest resolution obtainable. This resolution is defined based on the density of the network. [00411] For each grid point, the algorithm checks whether or not it is within the area of influence of at least one reference point of one pro forma satellite-to-earth station link or satellite link segment. [00412] - Each of the reference points on every pro forma satellite-to-earth station and

satellite link segment has an area of influence, which is defined by the formula: area of influence = Rain / {[(Q/(a*L)] ^ (1/b)}, where: [00413] - Area of influence is the radius in kilometers around this point in which

precipitation at a given level is "sensed" by that pro forma satellite-to-earth station or satellite link segment (i.e., if there is rain at that intensity or above within that circle, the pro forma satellite-to-earth station or satellite link segment to which this reference belongs will be attenuated). [00414] o Q - a given quantization level in the specific pro forma satellite-to-earth station or satellite link segment. [00415] o Rain - The precipitation intensity we want to measure. [00416] o a and b - pre-set parameters which depend on a pro forma satellite-to-earth station link's or satellite link segment’s frequency and polarization, and on the drop size distribution typical to the area (e.g., taken from the open literature). [00417] o L- link length (distance between the pro forma satellite-to-earth station link or satellite link segment endpoints). [00418] If a grid point is within the range (area of influence) of at least one pro forma

satellite-to-earth station link or satellite link segment, this grid point is considered to be detectable (or "covered"). [00419] Since the area of influence of each reference point depends on the precipitation intensity (see the area of influence formula), the algorithm performs stage two for a series of different precipitation intensities, with intervals between intensities set at 0.1 mm/hr. For each precipitation intensity, the satellite microwave link data processing program calculates a different set of grid points that are within the area of influence of one or more discrete microwave link points. The satellite microwave link data processing program saves the different coverage maps for the different intensities separately and permits an evaluation of the network's coverage for a wide range of intensities. 6.7.1.9 Fog time series analysis program (982)

[00420] The fog time series analysis program (982) is executed out of phase with fog prediction and forecasting (i.e. as an offline process that creates the time series rules ML models prior to fog forecasting) to produce time series rules ML models. In a particular exemplary embodiment, referring to Figure 14, the fog time series analysis program includes a machine learning model training module (678) which is configured to process machine learning training data including, for example historical fog detection data and historical microwave link attenuation data, and produce one or more fog time series rules ML models. In an exemplary embodiment, the fog time series analysis program communicates with the system database to retrieve historical fog detection data, for example weather sensor processed data (622) including fog detection indications of confirmed fog events generated by a fog detection sensor. In an exemplary embodiment, the fog time series analysis program retrieves historical microwave attenuation data from one or more microwave link attenuation databases (352a,b). The fog time series analysis program causes the machine learning training module to apply time series analysis to the retrieved training data (e.g. to retrieved historical fog detection data and historical weather parameter data) to determine trends or patterns in the time varying characteristics of, for example, measured attenuation that correspond to either confirmed fog or precipitation events. In an alternative embodiment, fog time series analysis program causes the machine learning training module to use time series analysis to determine trends or patterns in historic precipitation determinations and fog inferences that correspond to correct or incorrect fog inference. [00421] The fog time series analysis program causes the machine learning training module to create, and can periodically update, fog time series rules ML models (984) which are used by the fog inference program of the system to confirm a preliminary fog inference and determine a confirmed fog inference (or in the absence of a confirmation, refute the preliminary fog inference). The fog time series rules ML models encode patterns of attenuation magnitude that are indicative of whether or not fog is likely. The encoded patterns of attenuation magnitude are identified, by the time series analysis program, using time series analysis of a series of historic attenuation magnitudes preceding a confirmed fog event. Confirmed fog events can include fog events detected by known fog detection methods including, but not limited to, human observers, visibility measurements, or specialized fog detection instruments or sensors. The fog time series analysis program stores the fog time series rules ML models in the fog time series rules database (986). [00422] In an embodiment, a fog time series rule ML model includes a mask that encodes a shape corresponding to a plot of fog LWC estimate magnitude on a vertical axis and time on a horizontal axis wherein the shape of the plot is derived from one or more time series of historic fog LWC magnitudes that preceded and/or included a confirmed fog event. The fog inference program can infer a presence or absence of fog by comparing the mask to a plot of historic fog LWC magnitudes preceding a current, or real time, fog LWC estimate and determining a measure of correlation between the mask and pattern of fog LWC estimate values. In an exemplary embodiment, the fog inference program maintains, in working memory of prediction and modeling server (360), a time series of recent fog LWC estimate values, for example a series of fog LWC estimate values measured during one or more cadence instances of the 30 minutes preceding a current cadence instance. If the pattern of previously calculated and current fog LWC estimate magnitude is similar in shape to the mask encoded by the fog time series rule ML model, the fog inference program can infer that fog is likely to be present. [00423] Fog generally develops slowly while initiation of a significant precipitation event can be sudden. Therefore a rapid increase in estimated fog LWC magnitude relative to a baseline can indicate that precipitation is more likely while a gradual increase in fog LWC magnitude can indicate that fog is more likely. A first illustrative fog time series rule ML model includes predicting that fog is not present and making no fog (i.e. precipitation) inference

determination if an increase in fog LWC magnitude greater than a threshold amount occurs over a particular time period. A second illustrative fog time series rule ML model includes predicting fog and making a fog inference determination if fog LWC estimate is part of a time series of fog LWC estimates characterized by a pattern of gradually increasing LWC magnitude. A third illustrative fog time series rule ML model includes a mask having a shape representing gradually increasing fog LWC magnitude over time. [00424] In another embodiment, a fog time series rule ML model can include patterns of fog versus precipitation (or“fog/no fog”) determinations that are indicative of a possible fog inference false alarm. For example, a time series pattern that includes multiple precipitation inferences followed by a single fog inference could predict that the single fog inference is incorrect since it is unlikely that precipitation will abruptly change to fog. A corresponding fog time series rule ML model requires that, if multiple previous inferences indicate precipitation, then multiple consecutive fog inferences must be made before a fog inference is confirmed. In a similar manner, a time series that includes multiple consecutive fog inferences followed by a precipitation inference could be predictive of a false inference of a cessation of a fog event. A corresponding fog time series rule ML model requires multiple consecutive precipitation or no fog inferences before a no fog inference is confirmed. 6.7.1.10 Fog transform program (995)

[00425] The fog transform program (995) carries out fog transform creation process (4000) to pre- calculate transforms and filters useful for converting microwave attenuation collected data to weather parameter data including, for example, atmospheric water vapor and LWC estimates on or more system tile layers. 6.7.1.10.1 Illustrative fog transform creation process

[00426] Referring to Figure 17, an illustrative fog transform creation process (4000) is shown for pre-calculating fog baseline and fog transforms. It comprises steps to pre-calculate fog- specific transforms to be used for fog inference generation and LWC calculation. One or more programs that generate fog-specific transforms, collectively called fog transform generation programs, perform steps of the fog transform creation process (4000). For example, baseline attenuation determination program (641) and/or one or more microwave link data processing programs (e.g.615a, b) and dedicated fog transform program (995) can perform the steps to generate transforms for determining fog-specific baselined attenuation and the microwave data processing programs or fog transform program can perform steps to generate fog transforms. [00427] At step 4010 a fog transform generation program retrieves, from a terrestrial or satellite information database (e.g.390, 657), satellite and terrestrial microwave link infrastructure data including link endpoint locations, link transmit power, and link polarization. The microwave link infrastructure data can include satellite microwave link location and characteristics data and terrestrial microwave network topology microwave tower and signal characteristics data (and link status update information). In some exemplary embodiments, the fog transform generation program retrieves pro-forma link endpoint locations and pro- forma link information. [00428] At step 4018, the fog transform generation program pre-calculates fog-specific baseline attenuation transforms. Fog-specific baseline attenuation transforms include transforms for separating, from satellite or terrestrial microwave link attenuation measurements, baseline attenuation when no fog and no precipitation is present. Baseline attenuation determination is discussed in further detail herein in relation to baseline attenuation determination program (641). [00429] At step 4020, a fog transform generation program pre-calculates fog transforms including link-to-grid and grid-to-tile transforms. The fog transform uses the retrieved microwave link configuration information to pre-calculate link-to-grid and grid-to-link transforms, as described earlier. [00430] In an exemplary embodiment, a fog transform includes a well-known LWC estimation model to estimate a liquid water content (LWC) of fog including, for example, a model that can be used to estimate LWC as a function of ambient temperature, microwave attenuation and microwave frequency. [00431] In additional exemplary embodiments, a fog transform includes one or more additional models to estimate additional atmospheric conditions based on microwave link attenuation measurements, for example a well-known atmospheric water vapor estimation model to estimate atmospheric water vapor density. In a further embodiment, fog transforms include equations or algorithms for calculating precipitation estimates and for transforming LWC and precipitation estimates to a separate LWC tile layer (2048) and microwave precipitation tile layers (2022a,b) or to combined LWC and precipitation tile layers. [00432] In some exemplary embodiments, fog transforms are encoded with threshold values of LWC and/or precipitation estimate values for fog yes/no inference decision making by the fog inference program. For example, an exemplary fog transform includes a maximum LWC magnitude threshold (TFogHigh) above which a presence of fog is not inferred or a range of LWC value thresholds (e.g. between TFogLow and TFogHigh) within which a LWC estimate value must fall to generate a fog inference based on the LWC estimate value. [00433] In an embodiment, a fog-specific baseline transform and a fog transform are configured as a unitary transform, i.e. a single transform that determines both a baselined or fog-specific attenuation and a fog LWC. [00434] In an additional exemplary embodiment, microwave link precipitation programs (654a,b) perform fog inference and microwave link precipitation transforms, i.e. precipitation link-to- grid and grid-to-tile transforms, include transforms for calculating LWC as well as for generating precipitation , estimates and transforms for mapping generated data to a grid and to tiles. In this additional embodiment, separate fog transforms are not created and step 4020 includes calculating fog-specific components of microwave link precipitation transforms. [00435] At step 4022, the fog transform program saves fog baseline and fog transforms to the filter and transform database, after which the process ends (4023). 6.7.1.11 RVR transform program (324)

[00436] The RVR transform program (324) carries out RVR transform creation process (2300) to pre-calculate transforms and equations for determining RVR at locations of interest retrieved from a location of interest database (391). The pre-calculated RVR transforms are used by the RVR forecasting program. 6.7.1.12 Illustrative RVR transform creation process

[00437] Referring to Figure 18, an illustrative RVR transform creation process (2300) is shown for pre-calculating RVR transforms. It comprises steps to pre-calculate RVR transforms that are used for calculating and forecasting RVR at one or more pre-selected locations of interest, for example at airports, runways, or other locations. The RVR transform program (324) performs steps of method (2300). In an exemplary implementation of method (2300), the RVR transform program retrieves one or more user-selected locations of interest from location of interest database (391), pre-calculates mapping of each location of interest, e.g. a selected RVR forecast location, to system tiles, retrieves location-specific ancillary data for RVR forecasting, and pre-calculates precipitation-to-RVR equations and fog-to-RVR equations for each retrieved location of interest. Pre-calculating RVR equations includes retrieving, and associating with retrieved location of interest, e.g., RVR forecast locations, values of parameters used for calculating Va and Vk and other measures of visibility corresponding to the locations of interest. The RVR transform programs creates RVR transforms that include the pre-calculated mappings, equations, and ancillary data and saves the RVR transforms to a transform and filter database. [00438] At step (2310), the RVR transform program retrieves one or more locations of interest, for example airport and/or airport and runway location information, from the location of interest database (391) and maps each RVR forecast location to one or more tiles of input precipitation and/or fog forecast tile layer(s) and output RVR forecast tile layer(s). The RVR transform program can prompt the RVR ancillary data collection program (519) to collect and store any additional airport or other RVR location-specific information needed for pre- calculating RVR transforms. The RVR ancillary data collection program retrieves the additional information and stores it, as RVR ancillary data (529), to the RVR location and ancillary data database (929). The RVR ancillary data may include current runway light luminosity (I), current and historical Vk measured by RVR sensors (245-248) at the airport, and background light intensity (BL) data. In an alternative embodiment, the RVR transform program uses estimated values of one or more of the variable. For example, in one embodiment, the RVR transform program assumes a value for airport current runway light luminosity I based on standards and estimates Et, which is a function of BL, rather than calculating and estimated Et using measured BL. In an exemplary operating method, the RVR ancillary data collection program collects, processes, and stores airport location, runway locations and length data, RVR sensor location, and other information from or corresponding to an airport. This information is stored in the RVR location and ancillary data database. Step (2310) can be initiated when a user selects one or more runways or airports for RVR report generation while further process steps to generate the RVR report are deferred until a user- defined RVR forecast reporting time. [00439] At step (2320), the RVR transform program maps one or more retrieved locations of

interest, for example one or more RVR forecast locations, to tiles comprising one or more tile layers of forecast stack MiFj. Referring to Figures19A-B, the RVR transform program maps airport and runway polygons (3010, 3012) retrieved from the location of interest database to tiles (3050) from a tile layer of a collection data stack Mi or forecast stack MiFj by determining which tiles correspond to each polygon. Referring to Figure 19A, a first location of interest include an airport polygon (3010) enclosing airport (3015) and a second location of interest includes a runway polygon (3012) enclosing runway (3016). Referring to Figure 19B, the RVR transform program determines an airport RVR location tile set (3020) that corresponds to the airport polygon and a runway RVR location tile set (3022) that corresponds to the runway polygon. The airport and runway RVR location tile sets are indicated by outlines with dark border and filled with cross hatching. The RVR transform program maps an airport location, and optionally the runway location(s) to tiles (3050) by determining which tiles correspond to the location of the airport and known locations along the runway (such as touchdown and rollout areas of each runway). In an exemplary embodiment, when mapping the runway to tiles (2320), the RVR transform program determines tiles that correspond to locations of RVR sensors (e.g., 245, 246, 247, 248) along the runway and, in some embodiments, determines a set of tiles that are within a threshold distance of the runway. These tiles represent the set of tiles that can be queried to determine precipitation rate or fog LWC and other atmospheric parameters along the length of the runway. [00440] When a retrieved location of interest includes a flag indicating a specific location, the RVR transform program can determine a flag RVR location tile set (not shown), including one or more tiles, by mapping a nearest tile to the flag RVR forecast location. Alternatively, the RVR transform program can map multiple tiles surrounding the flag RVR forecast location, for example a set of tiles within a threshold distance of the RVR forecast location, to a flag RVR forecast location. The RVR transform program can combine data corresponding to the set of tiles by, for example, calculating an average of RVR at each of the tiles in the set of tiles wherein the individual tile RVR values are weighted by distance. [00441] In a non-limiting implementation wherein a retrieved location of interest includes an RVR location other than a flag or polygon, for example an airport name and a particular runway at the airport, the RVR transform program prompts the RVR ancillary data collection program to retrieve runway data including the geographical location and length of the runway from an RVR ancillary data source or from another data source such as map data source (348). The RVR transform program determines an airport RVR location tile set that corresponds to the airport and a runway RVR location tile set that corresponds to runway based on the retrieved information. [00442] The RVR transform program stores the data corresponding to runway tiles, including

associated luminosity and other collected data, in the RVR location and ancillary data database where it can be accessed by the RVR transforms program, by other servers, and by programs running on other servers. [00443] At step (2325), the RVR transform program uses the RVR location tile sets and RVR

ancillary data to pre-calculate RVR transforms that are used to calculate RVR. The RVR transforms are pre-calculated prior to the RVR forecasting program (920) retrieving forecast precipitation data and/or forecast fog data that are used to generate forecast RVR data. This allows the RVR forecasting program to rapidly process forecast precipitation data to generate RVR forecasts when precipitation forecast data is received. The RVR transform program retrieves the airport RVR location tile set (3020) and runway RVR location tile set (3022), and flag RVR location tile set (not shown) from RVR location and ancillary data database (929) and pre-configures precipitation-to-RVR and fog-to-RVR equations for each tile set by retrieving location-specific parameters (BL, I, etc.) and associating the location specific parameters with the location tile sets and RVR equations. The RVR transform program pre calculates RVR transforms that include a runway precipitation-to-RVR and/or fog-to-RVR transform and airport precipitation-to-RVR and/or fog-to-RVR transforms. The RVR transform can pre-calculate additional or alternative RVR transforms for determining RVR based on other parameters such as for, example, another visibility measures (other than RVR), LWC, smoke, and other atmospheric conditions. At step 2327, the RVR transform program stores the RVR transforms in transform and filter database (393), and the process terminates (2329). 6.7.1.13 Machine Learning training data preparation module (677)

[00444] The machine learning (ML) training data preparation module (677) retrieves weather

parameter data, for example data comprising features or predictors and corresponding outputs, from a system database (320) and processes the weather parameter data to generate machine learning model training, validation, and testing data formatted as a data frame suitable for processing into one or more ML models. The ML training data preparation module is configured to generate training data useful for initial training of a machine learning model and training data useful for retraining or updating a previously trained machine learning model. Exemplary weather parameter data retrieved by the machine learning data preparation module includes processed collected and generated collected data, for example ground station precipitation, temperature, and relative humidity processed collected data, microwave link attenuation data, and fog LWC estimates, from current and previous cadence instances as well as previously calculated forecast generated data. The ML training data preparation module stores ML training, testing, and validation data in ML training data store (683). Processing of the retrieved data can include cleaning the data to remove outliers, interpolating or otherwise filling in missing data points, and removing erroneous or otherwise unneeded data and formatting the data in a date frame. In some embodiments, one or more these data cleaning operations are be carried out by other processes, for example MW link data collection programs (510a,b) and ML link data processing programs (615a,b). In some embodiments, the ML training data preparation module generates and pushes, or otherwise makes available, filters usable by the data collection and processing programs to perform data cleaning and formatting operations. 6.7.1.14 Machine learning training module (678)

[00445] The ML training module (678) retrieves an untrained, partially trained, or previously

trained ML model from the system database (320), retrieves ML training data from the ML training data store (683), and uses the training data to train or retrain the ML model, thereby generating a trained ML model, which it stores in the system database (320). The stored ML model includes algorithms from commercially available ML toolkits as well as custom algorithms and models. Some examples of types of predictive models include (without limitation) regression models (e.g., linear regression, logistic regression), classification and regression tree models, neural network classifier models, multivariate adaptive regression spline models and other machine learning models (e.g., Naïve Bayes, k-nearest neighbors, Support Vector Machines, Perceptron, gradient boosting, and random forest regression). In an exemplary embodiment, the ML model training module re-trains or updates a trained ML model by retrieving the trained model from the trained model store, retrieving training data from the ML training data store, and using the training data to perform additional model training. In further embodiments, the ML training module also directly retrieves data corresponding to features of a trained or untrained ML model from a system database. This retrieved data includes, for example, recent processed collected data and generated collected data. ML training module can incrementally improve the training of a model as the newly collected, processed, and generated data becomes available. The re-trained or updated ML model is stored in the system database. The ML training module is configured to execute a trained ML model to generate and update rules including rules usable by one or more programs operating on the modeling and prediction server (360) or the data collection and normalization server (310). For example, fog time series analysis program (982), comprises a ML training module that is configured to execute a time series ML model with fog-related training data to generate fog time series rules ML model output data. In some embodiments, offline/backend server (330) includes multiple ML training modules (i.e.678a, 678b, etc. (not shown)) which are each configured to execute, train, and retrain one or more ML models. [00446] The ML training module trains and, in some exemplary embodiments, periodically retrains, a fog predictive model to recognize sets of conditions and trends that occurred when attenuation-based fog inferences are likely to be correct or incorrect. The fog predictive model is a machine learning model or algorithm, for example a neural network algorithm, that is trained using fog-related weather parameter data and fog detection data to predict fog/no fog based on a particular set of current or forecasted weather parameter inputs. In an embodiment, the ML training module trains the fog predictive model with historic fog-related weather parameter data and data indicating locations of verified fog events. Fog-related weather parameter data includes static data and/or trends in data for atmospheric and other measurable parameters that can be related to or influence fog formation, for example: air temperature; ground temperature; water temperature; wind speed; wind direction; advection conditions; cloud cover; time of day; terrain characteristics; soil type; soil moisture; and vegetation characteristics. [00447] A second exemplary ML training module is a module that trains a neural network to

associate one or more“ground truth” weather data sources with one or more specific microwave link areas of effect, and relating the“ground truth” readings with the calculated weather data based upon link attenuation. In a particular exemplary embodiment, the ML training module trains a precipitation neural network classifier model that is configured to generate probabilistic precipitation determinations and precipitation rate estimates. The ML training module trains the precipitation neural network classifier model with multiple time series of data including two or more time series of historical microwave link attenuation collected processed data values from one or more microwave links, precipitation rate generated data values calculated from the microwave link attenuation values, and historical ground station precipitation, temperature, and relative humidity collected processed data values from ground stations within the areas of influence of the microwave links, or within a preconfigured distance from each of the microwave links, e.g. within 1 kilometer of each link. This approach improves the accuracy of the link attenuation-derived weather data. 6.7.1.15 Machine learning validation module (679)

[00448] The ML model validation module (679) retrieves a trained ML model from the system database (320), retrieves evaluation data (i.e. testing and validation data) from the ML training data store, and performs testing and validation operations using the trained model and the retrieved testing and validation data. In some exemplary embodiments, the ML validation module generates a quality metric, e.g., a model accuracy or performance metric such as variance, mean standard error, receiver operating characteristic (ROC) curve, or precision-recall (PR) curve, associated with the trained ML model. For example, the ML model validation model generates the quality metric by executing the model and comparing predictions generated by the model to observed outcomes. The ML model validation module stores model quality metrics in he system database (320), associated with the trained ML model, and the system may not include a ML model validation store. In some exemplary embodiments, the ML model validation module periodically tests trained ML models using training data derived from processed collected or generated collected data and recalculates quality metrics associated with the trained ML models. In some embodiments, the ML training module retrains a trained ML model if the system determines that an associated quality metric has deteriorated below a threshold amount. In some embodiments, trained ML models are retrained on a periodic schedule. 6.8 Modeling and Prediction Server (360)

[00449] Referring to Figure 2, a third server (including a data processing component) is a modeling and prediction component that performs parallel computations generating precipitation estimates, fog inferences, and for preparing precipitation and fog forecasts that at least indicates a precipitation type and a precipitation intensity at various locations and is preferably further based on other weather phenomena . In an embodiment, the parallel calculations are based at least on microwave attenuation data from a plurality of microwave links (e.g. such as satellite microwave links) and is preferably further based on other weather phenomena, using other data types, such as current radar attenuation data, wind

characteristics, temperature, humidity, dew point, and other conventional weather related information that has been collected, formatted, and stored in the various databases as input. [00450] The modelling and prediction component, using the available pre-formatted data, produces calculated outputs that are written to databases for use by subsequent iterations of modelling and prediction processing and for subsequent use in one or more user products produced by the system. [00451] The modeling and prediction server (360), as illustrated in Figure 20, comprises one or more computer systems similar to the exemplary server illustrated in Figure 3. This server comprises one or more processors (730), programs (654a,b, 905, 910, 915, 918- 920, 925- 926, 930-931) that are stored and executed from transient or persistent memory (700), and one or more databases such as system database (320). [00452] The modeling and prediction server executes one or more programs to perform various complex and processor intensive modeling and prediction algorithms and data manipulations used to prepare one or more precipitation estimates, fog inferences, and precipitation and fog forecasts which may be projected onto geographic maps. [00453] In an embodiment, the predictive model programs (e.g. fog predictive model program

(926)) collect information previously stored in one or more of the system databases and calculates the current precipitation intensity values, infer weather conditions, such as determining if fog is likely to be present, and calculate current weather conditions based upon the precipitation, atmospheric water vapor, and atmospheric condition models. The current precipitation intensity values and atmospheric condition-related values are stored back into a database for later use. [00454] The server also implements one or more data management (e.g. applying transforms, tile layer compares, copying, and blending), weather inference, and weather forecast programs. These programs are used create aspects of the forecast data for the system. Generally, the modeling and prediction server programs retrieve data of the forecast program required type and time window from the system database (320) and from other sources of data provided by the system. The modeling and prediction server executes one or more programs to perform various complex and processor intensive modeling and prediction algorithms and data manipulations used to prepare a one or more weather and precipitation forecasts. Processing results (processed collected data, generated data, forecast data, and weather data) are stored as updates to, or as new information for, one or more logical databases. Alternatively, one or more of the stored data are sent directly to the information distribution and alerting server (370) for use in notifying a user or producing a forecast report. [00455] The modeling and prediction server also implements the cadence manager, which controls the operation of the cadence-based forecasting programs, and the programs that implement each portion of the cadence cycle. The cadence and cadence manager is described in more detail below. 6.8.1 Cadence management programs of the forecasting and modelling server

[00456] The modeling and prediction server (360), as illustrated in Figure 20, comprises one or more computer systems similar to the exemplary server illustrated in Figure 3. This server performs calculations and modelling for real-time processing of information, calculations of weather models, and production of weather predictions using one or more processors (730) and programs including real time precipitation estimation programs (e.g. satellite microwave link precipitation program (654a), terrestrial microwave link related programs, e.g. terrestrial microwave link precipitation program (654b), programs that blend precipitation

measurements and estimates from multiple sources (e.g. precipitation blending program (918)), programs that infer a presence of a weather condition based upon collected and forecast weather data (e.g., fog inference program (919)), internal predictive model programs (e.g., fog predictive model program (926)) and forecast processing programs (e.g., precipitation forecasting program (915), fog forecasting program (931), and RVR forecasting program (920)) that are stored and executed from transient or persistent memory (700). The server programs read information from system database (320) including one or more databases listed in Table 1, for example processed microwave link measurements from attenuation databases (e.g., 352a,b), databases containing precipitation estimates (e.g., 356a,b), forecast RVR database (923), vehicle weather data database (632) and other databases comprising weather data that are part of the system database as required, and can data cache (720) in one or more transient or persistent memories (700) for use by programs that carry out real-time modeling and/or prediction processing. Processing results including terrestrial microwave link precipitation estimates (626b), satellite microwave link precipitation estimates (626a), blended precipitation data (928), forecast precipitation data (902), and forecast RVR data (922) are written as updates to, or new information for one or more databases containing precipitation estimates (e.g., 356a,b) and precipitation or other weather parameter forecasts (e.g., 325). 6.8.1.1 Cadence manager (905)

[00457] The cadence manager (905) is a program that is part of a forecasting system (300) and that manages operations related to cadence processing, including any necessary propagation and processing programs. The cadence manager controls the cadence time base, including when to change from one cadence instance to the next and when to change from one processing stage to the next. The cadence manager also controls and manages the simultaneous program execution(s) that are part of one or more cadence cycles, and the resulting cadence instances that are produced as a result of these program executions. It also sets and manages the cadence cycle and cadence instance variables in the cadence instance data structures as well as globally for the system. The cadence manager determines which programs are to be processed next as part of a cadence instance, when they are to be processed, and in some embodiments, determines which resources are used by those programs (e.g. which processor a specific program is executed by). [00458] The cadence manager is responsible for optimizing run-time resource utilization during the processing of cadence instances. One important optimization by the cadence manager is the determination on whether a specific cadence instance can reuse some or all of prior collected data and forecasts or whether it is more efficient to fully process and calculate each element of the cadence instance. Accordingly, the cadence manager implements one of two mechanisms for creating and updating cadence instances, depending upon the current status of cadence instance(s) that have been generated in the past and the current data collection state. [00459] As shown in Figure 4, the cadence manager makes this determination each time the

processing of the cadence changes processing stages; e.g. at the end of collection activities, at the end of post-collection activities, at the start of each forecast cycle, and the end of forecast processing (for all forecast cycles), prior to post-forecasting processing, and prior to each weather product program execution. [00460] At the end of collection activities, the cadence manager makes a determination whether the collected data and previous forecasts are in agreement by comparing corresponding collection and forecast data. This is done with the tile layer comparison program (910). If the collected data and a previous forecast are in agreement or are mostly in agreement, there is no need to rerun the whole forecast in order to create a new forecast. If the forecast is in complete agreement (often the case when cadence intervals are small or when the weather patterns are changing slowly), the previous forecast, and weather product data can be copied (propagated) and used in the new cadence instance, saving substantial resources. If small portions of the forecast have changed, the bulk of the forecast and weather product data can be copied and only those portions that have changed (or are dependent upon a changed portion) need be recalculated, again saving substantial resources. The same types of checks can be made at the beginning of each forecast cycle, and at the end of the forecast cycle in order to avoid unneeded forecast cycles and calculation of weather product data. [00461] If differences are detected that require a partial or complete calculation of forecasts, the cadence manager determines which method of calculation and/or propagation is most appropriate to minimize the required resource usage to process the current cadence instance based upon a variety of input parameters, such as the amount of change in newly collected data and the volatility of the forecast mechanisms. In general, there are two primary approaches that the cadence manager uses; complete (re)calculation and incremental update calculations. The cadence manager uses one or more of the following inputs in order to make a determination as to which approach to use: a) new information collected in the current cadence instance’s data collection tile layers, b) information from prior cadence instance data collection tile layers, c) information from prior cadence instance tile layers, and d) information provided by processing programs used when creating a cadence instance. [00462] Once the cadence manager makes a determination as to the cadence instance processing approach, it then selects an option to either to perform a complete calculation for all cadence instance elements or to incrementally update the cadence instance by propagating tiles from previously generated tile layers into the current cadence instance. In some embodiments, the determination and processing approach determination is typically made once per cadence instance processing. In alternative embodiments, the determination may be made on a periodic basic. In other alternative embodiments, the determination is made once and all cadence instance processing (for a specific cadence cycle) implements the same

determination. [00463] If the cadence manager selects the option to copy and update a prior forecast tile layer, the cadence manager often still has to run any missing processing programs in order to complete a new cadence instance. Even though the missing processing programs and forecast cycles have to be run, the compute and time savings of these“shortcut” approaches significantly reduces the amount of computing cycles requires to produce the next forecast cycle, and substantially reduces the amount of time required as well. In some cases, the time savings may exceed 75, 80, 85, 90, 95, or even 98%, resulting in corresponding forecast calculation times (assuming a 10 minute forecast cycle) of 2.5 min, 2.0 min.1.5 min, 1.0 min, 30 sec, or 15 sec respectively. Similar percentage savings may be achieved on the forecast calculation compute requirements. 6.8.1.1.1 Tile layer generation by complete (re)calculation approach

[00464] The cadence manager (905) uses a complete calculation approach when a cadence instance does not have appropriate previous cadence instances to update with current data, when the rate of incoming collected data is very high, when the analysis performed by the cadence manager of the cadence instance processing approach indicates that the amount of processing to perform updates and propagation exceeds the amount of processing required to completely calculate the cadence instance from initial collected data, or when it is the first time that this particular tile layer is being generated. [00465] Complete (re)calculation of a tile layer can be very expensive in terms of resources and time, so the cadence manager typically defaults to a partial calculation and update mode. Partial calculations and updates reduce the amount of recalculation required when sparse or high frequency updates are being made to underlying tile layers. When the number of recalculations exceeds a configurable threshold, the cadence manager makes a determination that it will be more efficient to recalculate the entire dependent tile layer. 6.8.1.1.2 Partial calculation and update approach

[00466] Once a determination is made by the cadence manager (905) to perform a partial calculation and update within a cadence instance, several steps occur. First the portions of the tile layers to be copied to the cadence instance along with their corresponding prior tile layers selected from one or more of prior collected data tile layers, processed collected data tile layers, forecast tile layers, forecast post-processing tile layers, and weather product tile layers. The identified prior tile layers are propagated by copying to the current cadence instance. 6.8.1.1.3 Partial Recalculation and Propagation Method of the cadence manager

[00467] Referring to Figure 21, an illustrative cadence instance partial recalculation and propagation method (50000) is shown for updating forecast stacks of a cadence instance to reflect newly collected data when there is going to be a partial calculation and update. It comprises steps for comparing at least one first source tile layer to a second source tile layer, propagating data from at least one of the source tile layers to a target tile layer, and then recursively updating subsequent dependent tile layers that depend upon the target tile layer. [00468] At step (50100) and (50110), the cadence manager (905) determines an at least one of a first and a second source tile layer are available for comparison testing. A tile layer becomes available for comparison testing when there are no current processing steps acting upon it (e.g. collection activities, forecast programs running, other propagation activities). [00469] Once the tile layers are available, the cadence manager, at step (50120), determines the significance factors to use when evaluating changes in the input data to determine if reprocessing of one or more tiles is necessary. Significance factors are dependent upon the processing program, including the inputs that the processing program uses, that program’s known sensitivity to input variations and computational parameters of the forecasting method. For example, the cadence manager determines the applicable significance factors by querying a processing program that generated a particular forecast tile layer. Alternatively, significance factors are encoded as a data element associated with a tile layer and the cadence manager reads those significance factor values from that tile layer. [00470] At step (50130), the cadence manager runs a tile layer comparison program (910) to

perform comparison testing between the selected source tile layers in order to determine whether a source tile layer can be copied or whether significant differences are present between the selected tile layers that require tile level updating, and to identify those tiles and tile layers that will be propagated by the tile propagation program (930). This step is sometimes called verification when performed on a forecast tile layer, and is performed in order to determine the portions of the forecast layer that were accurate and which were not. [00471] In a first embodiment of this test, the cadence manager identifies as a source collected data tile layer (e.g. a rapidly updated ground weather data layer from vehicle sensors) and identifies the tiles within that tile layer that have changed in the current cadence instance. The cadence manager identifies a forecast tile layer as its second source tile layer. It then identifies at least one forecast tile layer as a target tile layer that needs to be updated as a result of the updated collected data. The cadence manager then runs a tile layer comparison program to compare the subsequent source collected data tile layer to the identified source forecast tile layer in order to verify the source forecast data. The source forecast data is verified by using one or more forecast comparison tests that compare the source forecast data to the selected collected data tile layer and to determine the significance of any differences between the compared tile layers. [00472] If the source forecast data passes the comparison testing based one or more criteria, for example if source forecast tile layer differs from the collected data tile layer by less than a threshold amount, then the source forecast tile layer is verified and may be copied directly to the target forecast tile layer. Thresholds used in comparison tests are based on one or more factors including the desired or required accuracy of forecasting results and confidence in a data source. For example, a ground station precipitation measurement may have higher accuracy or fidelity than a radar-based precipitation estimate; therefore tiles of a ground station precipitation tile layer have a higher confidence score than tiles of a corresponding radar-based precipitation layer. If a forecast tile is verified or updated, a corresponding confidence score associated with the tile is increased to indicate an increased confidence in the verified forecast tile. Note that the comparison tests used may differ for each type of collected data, and for differing forecast models. Forecast data sets also can be verified against unitary collected data tile layers, for example against a ground station precipitation tile layer, or may be verified against blended generated collected data sets encoded as tile layers, for example against a tile layer that includes blended ground station, radar, and microwave link precipitation measurement data. [00473] The tile layer comparison program (910) may be used to perform comparison testing (verification) on a subset of tile layers. For example, when available collection data only includes ground station precipitation measurements, the tile layer comparison program is called to perform comparison testing on the tiles that are located within geographic regions that include the ground stations. The cadence manager may also prioritize verification of tile layers that comprise data that is more valuable to an end user or that has a greater impact on derived data than other, less interesting data. Computation may be further optimized by only doing verification until a result is obtained, and skipping additional verifications once a determination is made that a tile or tile layer needs to be updated. For example, the cadence manager may limit verification to precipitation above a threshold intensity relevant to the forecasting program or to data related to weather phenomena that are rapidly changing. [00474] At step (50140), the cadence manager then propagates changes from the source tile layer(s) to the target tile layer. If portions of at least one of the source tile layers are determined to be significantly different from a prior source tile layer that the target tile layer was dependent upon, the cadence manager calls the tile propagation program to update the tiles of the target tile layer in order to reflect the changes from at least one of the source tile layers. [00475] Note that propagation may take multiple forms. Some or all of the target tile layer’s data is modified by the tile propagation program. If greater than a threshold amount of the target tile layer’s data is going to be updated by the tile propagation program, the tile propagation program (or cadence manager) may create a new target tile layer instead of propagating changes over a target tile layer. Otherwise, only the portion of the source tile layer that failed the test is updated. [00476] Other tile layers that depend on an updated tile layer are also updated using this process, for example, tile layers that support weather data products derived from updated forecast data, and specialty forecasts such as RVR forecasts and fog forecasts. In this manner, the system updates only the previously determined forecasts and derived data that are affected by the subset of forecast data that was determined to be inaccurate in light of newly collected data. In this manner, computations become significantly faster and more efficient, reducing computing resource requirements and computing time. [00477] At step (50145), the cadence manager determines if there are any other tile layers that are dependent upon the target tile layer. When the target tile layer is a forecast tile layer, dependent tile layers may include subsequent forecast tile layers of the cadence instance, or tile layers produced by various processing programs. [00478] If the cadence manager determines that there are no dependent tile layers, the process terminates (50170). [00479] If the cadence manager determines that there is at least one dependent tile layer, at step (50150), the cadence manager invokes propagation dependency program (925), to identify tiles requiring update in the at least one dependent tile layer, as is discussed in further detail below. Then, at step (50155), the cadence manager invokes the tile propagation program to propagate updates to the identified tiles. [00480] At step (50160), the cadence manager determines whether tiles of the dependent tile layer were altered by propagated updates to the dependent tile layer at step (50155). If no tiles were altered, (e.g. the changes did not result in any change of significance in the target tile layer) the cadence manager determines that updates to the dependent tile layer no longer need to be propagated through the tile stack and the propagation process terminates (50170). [00481] If updates to the dependent tile layer resulted in significant alterations to one or more tiles, then the cadence manager returns to step (50145) and continues iterating the propagation of updates until either all dependent tile layers have been processed (i.e. until step (50160) results in a“no” answer and the propagation update process terminates). 6.8.1.1.4 Example 1: Propagate data from collected data tile layer and

merge with previous forecast to create new forecast tile layers

[00482] This example is based on the following cadence scenario.

TABLE 11: Cadence Scenario:

[00483] The following describes a process for updating a previously computed set of forecast tile layers using current collected data. Tile layers for M6F0, M6F1, M6F2 and M6F3 will be propagated from the M6F0 collected and processed tile stacks, the M3F1, M3F2, and M3F3 forecast tile layers. [00484] In this example, a source tile stack includes M ₆ F ₀ collected and processed tile stacks and the F3F1 precipitation forecast tile layer, and the verification process verifies the forecast of M3F1 using the collected and processed tile stacks of M ₆ and selectively propagates significant changes from M ₆ F ₀ into a copies of M ₃ F ₂ and M ₃ F ₃ in order to create M ₆ F ₁ and M ₆ F ₂ respectively. M6F3 will be run independently after the M6F2 tile layers are created. [00485] Each of the selected forecast stacks comprise at least one precipitation tile layer. In this example, M ₃ F ₁ comprises a forecast precipitation tile layer; M ₆ F ₀ has a collected precipitation tile layer. [00486] The cadence manager (905) determines whether collected data from the M6F0 forecast stack is suitable for use to verify a previously calculated forecast stack of another cadence interval based upon absolute times of the cadence cycles. The cadence manager compares a time stamp of the M6F0 forecast stack to time stamps of one or more forecast stacks, including M3 forecast stack, and determines, based on matching time stamps, that data included in M ₆ F ₀ collected precipitation tile layers are suitable for use to verify at least one forecast tile layer of M3F1 forecast stack. In this example, the compared forecast stacks both have the same absolute time stamp (t = 20 min.), but the cadence manager can match tile stacks with similar but not exactly matching time stamps. In this case, the cadence manager determines that M3F1 forecast precipitation tile layer is verifiable using the M6F0 collected precipitation tile layer because both tile layers comprise precipitation amounts (forecast and actual respectively). [00487] The cadence manager then invokes a tile layer comparison program (910) which compares M3F1 precipitation forecast tile layer to M6F0 collected precipitation tile layer and determines whether at least one significant difference exists between data contained in the collected and forecast precipitation tile layers and the tiles that have those differences (i.e. that one or more tiles of M3F1 precipitation forecast tile layer have inaccurate forecast data and should be updated because there was a significant change in the forecast outcome based upon current collected data). [00488] The cadence manager then invokes the tile propagation program (930) to propagate the M3F1 forecast precipitation tile layer to the M6F0 forecast precipitation tile layer, where the M ₆ F ₀ tile layer is created by copying the M ₃ F ₁ forecast precipitation tile layer to M ₆ F ₀ forecast layer, and then running a forecast program only for those tiles for which there were significant differences between the M3F1 forecast precipitation tile layer and the M6F0 collected precipitation tile layer. This produces a current M ₆ F ₀ forecast utilizing a fraction of the computing resources required to fully compute the M ₆ F ₀ tile stack from collected data. In an alternative embodiment, the copy operation could be performed by changing database tags in specific tiles of M3F1 forecast precipitation tile layer to include a reference to

corresponding tiles of M ₆ F ₀ collected precipitation tile layer. [00489] The cadence manager then determines that the M6F1 forecast stack is dependent on M6F0 forecast stack and upon the M3F2 forecast stack using the propagation dependency program (925), and then uses the tile layer comparison program to identify the tiles of the M ₃ F ₂ forecast precipitation tile layer that can be copied from M ₃ F ₂ and those tiles that should be forecast from M6F0 because of significant differences and/or propagation effects. Those tiles that can be copied are copied to M ₆ F ₁ , and those that must be forecast are created using a forecast program. [00490] This process iterates for additional forecast cycles until there are no more forecast cycles to process (e.g. M3F2/M6F1 to produce M6F2). In the event that a forecast converges in any of the cycles (e.g. there are no significant differences between the previous and current forecast, the cadence manager simply copies the remaining previous forecasts to the new cadence instance. The cadence manager then runs any missing forecast cycles (e.g. M6F3) to complete the forecasting process. [00491] A similar process is used to update post-forecast processing that is stored in weather

product tile layers. [00492] If the cadence manager selects the option to copy and update a prior forecast tile layer, the cadence manager often still has to run one or more processing programs in order to complete some of the tile layers of the new cadence instance. For example, if a forecast is copied from once cadence cycle to another, the copied forecast will need is last forecast cycle run to complete the new forecast. [00493] Process and programs run by the cadence manager [00494] The cadence manager has a number of cadence specific programs that may be performed at specific times in the cadence cycle to create and manage the cadence data structures. These programs include collection, post-collection, pre-forecast processing programs as described herein. In addition, specialized programs that manipulate the cadence data structures may also be run as circumstances dictate. Illustrative examples of these programs are shown in the table below.

TABLE 12: Data Processing Programs of the Cadence

6.8.1.2 Tile Layer Comparison Program (910)

[00495] The tile layer comparison program (910) is used to compare one or more tiles and/or tile layers in order to determine whether changes are present that are significant enough to change the results of subsequent processing and affect the propagation strategy for the tiles. The tile layer comparison program is called by the cadence manager to perform comparison testing aspects of cadence instance recalculation and propagation method (50000).The tile layer comparison program may perform simple data comparisons of discrete values, but generally performs comparisons that are more flexible in order to determine if differences are significant in the context of the comparison. For example, if two rainfall tile layers were being compared to determine if a flood forecast must be updated, a difference between 0.1 and 0.2 mm of rainfall, while technically different, is not significant to the flooding forecast program and can be ignored when determining whether to require the flooding forecast program be rerun on the basis of changed data. The tile layer comparison program takes as inputs, as specified by the cadence manager, two or more tile layers and/or tiles, and a specification describing the amount of change required to constitute a significant difference and returns either an indication that changes are significant or that changes are not significant, and alternatively identifies the individual tiles or tile layers that have significant differences. [00496] In addition to strict arithmetic comparisons, an alternative method of comparing tile layers is to encode all or some of the a set of tile layer(s) into a graphical format, use image analysis techniques to determine or expose features of the images, and then use image comparison techniques to compare the respective graphical images and determine whether the respective features of the images match. The encoding and image feature comparison aspects of this technique may encode and compare only those tile layers and parts of tile layers that are specified for comparison by the cadence manager as contextually relevant. For example, by encoding only specific tiles from a tile layer, a region (part) of a tile layer, a complete tile layer, a set of tile layers, or a combination of specific regions of a specified set of tile layers, specific features of weather data may be exposed such as shapes of rain fields at specified precipitation rates, weather features such as convective storm cells, frontal boundaries, wind fields, and the like. Image feature analysis may be used to identify these weather features, which can then be stored in a weather objects database (350) and tracked across a plurality of these generated images. Image data can be reverse mapped to tiles in specific tile layers in order to utilize the information extracted by the image comparison techniques for use in further calculations. Exemplary methods for comparing forecast data to measurements include image analysis and pattern recognition techniques such as Method Object-based Diagnostic Evaluation (MODE), contiguous rain area (CRA) object based methods, analysis methods based on morphing forecast to match observation, cluster analysis, and a Structure Amplitude Location (SAL) method. [00497] An exemplary comparison test that implements an image-analysis based technique

processes gridded forecast data (e.g., forecast data mapped to a forecast tile layer) as image data, extracts weather features from the forecast data, and verifies aspects of the extracted objects such as location, size, shape, intensity, and other attributes of objects. Exemplary objects that are extracted may include weather information such as rain fields of specified intensities. For example, the tile layer comparison program extracts, from each of the tile layers that are being compared, information related to rain intensity, and then uses an image analysis program to identify, as objects on each tile layer, rain fields with peak intensity of less than 1 mm/hr, rain fields with peak intensity of less than 1-2 mm/hr, and rain fields with peak intensity of less than > 2 mm/hr. The identified rain fields may be compared between the tile layers, and the tiles that correspond to matching and non-matching portions of the rain fields identified based on matching and non-matching portions of the objects corresponding to the rain fields. Using the same techniques, the tile layer comparison program can extract and identify other interesting weather-related aspects of the tile layer(s), including isothermal temperature fields, humidity fields, and fog and cloud structures. [00498] As an example usage, the tile layer comparison program (910) may be used to verify that one or more forecast precipitation area attributes are sufficiently similar to newly collected data including, for example: location, size, and shape of precipitation areas; and precipitation intensity within areas (average, total, peak, distribution within precipitation area) and identify those tiles which have changed as the location, shape, or size of the weather feature has changed. To verify an attribute, the tile layer comparison program determines that the forecast attribute is sufficiently similar to the collected attribute according to one or more criteria specified by the cadence manager. Sufficiently similar is defined as meaning that a forecast attribute differs from the collected data by less than an amount that would produce a change in any derivative forecast results or derived data calculated using the newly collected data (as opposed to calculating using the original data) or is within a specifically defined tolerance (difference). Exemplary criteria for determining sufficient similarity include that centroids of forecast and collected precipitations areas are within a threshold distance from each other, precipitation intensity differs from a newly collected precipitation intensity by a threshold amount, etc. The tile layer comparison program can also perform comparison testing on a more granular level. For example, the tile layer comparison program may be used to verify precipitation intensity of each tile within a region of a forecast precipitation tile layer in order to determine individual tiles within the forecast precipitation tile layer that should be updated with the newly collected data (e.g. a significant ground truth data update of a forecast tile layer). The cadence manager may call the tile layer comparison program multiple times with differing input parameters during the course of processing a cadence instance. 6.8.1.3 Propagation dependency program (925)

[00499] The propagation dependency program (925) is used to determine the tiles within a tile layer, or which tile layers themselves, that are dependent upon other tiles or tile layers that have significant enough changes to warrant propagation and/or reprocessing. The propagation dependency program is called by the cadence manager to identify tiles requiring update during processing of cadence instance recalculation and propagation method (50000). [00500] In a first mode of operation, the propagation dependency program analyzes the cadence structure and determines the dependencies between tile layers in the cadence structures. The output of this determination is used by other programs of the cadence manager in order to determine which tiles and tile layers are influenced by changes in other tile layers. [00501] In a second mode of operation, the propagation dependency program uses the output of the tile layer comparison program (910) to modify the dependency list to eliminate tiles and tile layers from the list of dependencies when those tiles and tile layers that have not changed sufficiently to warrant reprocessing. [00502] The propagation dependency manager outputs a list of tiles and tile layers that are

dependent upon other tiles or tile layers for use by the cadence manager. 6.8.1.4 Tile propagation program (930)

[00503] The tile propagation program (930) is invoked by the cadence manager (905) to propagate data changes from one or more source tile layers to a destination target tile layer. The propagation dependency program is called by the cadence manager to perform requiring tile propagation aspects of cadence instance recalculation and propagation method (50000). This is performed either by moving or copying the data from the source tile layer and storing a copy of the data associated with the target tile layer, retagging the source data to make the source data available to the target tile layer, or by recalculating and/or reforecasting the targeted tiles in the target tile layer. [00504] The tile propagation program takes as inputs one or more source and target tile layers and/or tiles and determines the type of processing required to propagate the tile datum from the source tile layers to the target tile layer. If the source and target tiles have the same data type, the tile propagation program utilizes either a move/copy or retagging operation, which are database updates. If the target tiles are of a differing type than the source tiles, the tile propagation program runs a program to make the conversion and create new data items in the database comprising the converted data and creating new tiles for the target tile layer (replacing any old tiles with the new tiles). In cases where the tile comprises data that is the result of a processing program, the appropriate processing program is run to regenerate new tile(s) with updated data. [00505] The cadence manager may call the tile layer comparison program (910) multiple times with differing input parameters during the course of processing a cadence instance. 6.8.1.5 Programs that blend precipitation measurements and estimates from multiple sources

6.8.1.5.1 Precipitation Tile Layer Blending Program (918)

[00506] In an embodiment, the precipitation blending program retrieves two or more precipitation tiles layers (e.g., terrestrial microwave precipitation tile layer (2022b), satellite microwave precipitation and atmospheric water vapor tile layer (2022a), weather sensor data tile layer (2021), NWP tile layer (2024)) as input tile layers. The precipitation blending program selects tiles from one or more of the precipitation tile layers and copies data from the selected tiles to corresponding tiles of an output M _i F ₀ forecast precipitation tile layer (2031). The output forecast precipitation tile layer is a blended precipitation tile layer that is saved to the precipitation forecast database (325). [00507] Referring to Figure 7, forecast precipitation includes blended precipitation intensity tile layer (8102) which can include precipitation estimates, combined using a blending function (8200), from one or more microwave precipitation estimate data sources and can further include precipitation estimates from one or more radar or NWP data sources. [00508] In an embodiment. retrieved precipitation intensity tile layers include one or more

precipitation tile layers (8010, 8020) of a Mi Collection Data Stack. The retrieved precipitation intensity tile layers can include precipitation intensity expressed as rainfall rates measured in inches/hour. Estimated precipitation intensity can be calculated by the modeling and prediction server (360) using microwave link attenuation measurements, by the offline/background processing server (330) from reflectivity data, or can be supplied by radar data source such as, for example, a weather radar data source (344) or by a NWP data source (341) such as the Rapid Refresh (RAP) numerical weather model, maintained by NOAA. [00509] The modeling and prediction server (360) can optionally create a blended precipitation intensity tile layer (e.g. blended weather data) by applying a blending function (8200) to two or more precipitation intensity tile layers (8010, 8020) retrieved from Mi Collection Data Stack. The blended precipitation intensity tile layer can include precipitation intensity (or other weather data) from two or more data sources. In an embodiment, a blended precipitation intensity tile layer (8102) can include precipitation intensity calculated using microwave link attenuation measurements (8010) blended with precipitation intensity retrieved from a weather radar data source (344, 8020). In an embodiment, a blended precipitation intensity tile layer can include precipitation intensity retrieved from an additional or alternative data source such as NWP data source (341). Blending of precipitation tile layers is performed in the modelling and prediction server during a forecasting process in order to generate M _i forecast cycle specific blended precipitation tile layer. Alternatively, a precomputed blended precipitation intensity tile layer (8102) can be computed as part of a post collection processing activity such as a blending function (8200) and the results (e.g. processed blended weather data) associated as part of the M _i F ₀ forecast cycle to the start of forecasting process. These blending steps may be performed by the modelling and prediction server (360) or may be performed by other servers, for example, the information collection and normalization server (310) or the offline/background processing server (330). Alternative embodiments include further or alternative blending functions such as, for example, a blending function that propagates ground level precipitation intensity calculated from microwave link attenuation measurements to higher elevation layers of tropospheric NWP data. The blended weather data in stored in a data type appropriate database associated with the current cadence instance [00510] One or more wind vector tile layers (8030) are retrieved from NWP atmospheric database (329), radar database (322), ground weather station database (323), or Other Data database (324) by the modelling and prediction server (360). Wind vector data tile layers include forecast data from the NOAA Rapid Refresh (RAP) numerical weather model, which is obtained using the weather data collection processes described herein. Wind vector tile layers from multiple wind vector data sources can be blended with a blending function (8200) using techniques similar to those used for precipitation estimate blending. Blending wind vectors includes generating a blended wind data tile layer data using wind data from two or more input wind vector tile layers, each from a different wind vector data source. In an embodiment, a wind vector tile layer can be smoothed. In an embodiment, wind vector tile layers include a series of forecast tile layers (8104, 8114, 8124, 8134) bounded by the range MiF(j-k) where (j) is a start time of a forecast and (k) is an end time of a forecast. Wind vector tile layers thus include a series of tile layers, each tile layer corresponding to a current or forecasted time point and each tile layer including wind vectors (8104, 8114, 8124, 8134) assigned to individual tiles. In an embodiment, a time zero wind vector tile layer, i.e. Mi Collection Data Stack wind vector tile layer (8030), is retrieved and MiF(j-k) wind vector tiles (8104, 8114, 8124, 8134) are determined by the modeling and prediction server (360). [00511] One or more convective available potential energy (CAPE) tile layers are retrieved from a data source such a NWP data source. In an embodiment, CAPE tile layers include a series of forecast tile layers bounded by the range M _i F _(j-k) where (j) is a start time of a forecast and (k) is an end time of a forecast. In an embodiment, a time zero CAPE tile layer, i.e. M _i Collection Data Stack C tile layer, is retrieved and MiF(j-k) CAPE tiles are determined by the modeling and prediction server (360). [00512] Each tile of precipitation intensity tile layer (8010, 8020) or blended precipitation intensity tile layer (8102, 8112, 8122, 8132) from Mi Collection Data Stack and in each MiF(j-k) forecast data stack is classified as including a storm condition including one of clear, mature, rising, or decaying and, if not clear, is further classified as convective storm or stratiform storm. The tile can be classified as rising, mature, or decaying by observing a time series of precipitation intensity values (and/or estimated precipitation intensity values). If the current precipitation intensity value is greater than a previous precipitation intensity value, the tile is classified as rising, if the precipitation intensity value has not changed the tile is classified as stable and if the current precipitation intensity value is less than a previous precipitation intensity value, the tile is classified as decaying. In an embodiment, classification can include shifting precipitation intensities between tiles of the precipitation intensity tile layer MiFj (8112) using wind vector tiles of the wind vector tile layer MiFj (8114) to predict future precipitation intensities for tiles of the precipitation intensity tile layer, as will be discussed in further detail below. The forecasting process can be repeated over time. [00513] In an alternative exemplary embodiment, the precipitation blending program uses as inputs two or more weather parameter tile layers from the collection tile stack and blends them together to produce a blended weather parameter tile layer. The precipitation blending program carries out a tile blending method to blend tiles of two or more precipitation tile layers. In a particular exemplary embodiment, the precipitation blending program retrieves two or more microwave precipitation tile layers (e.g., (2022a,b), weather sensor data tile layer (2021), NWP tile layer (2024)) as input tile layers. The precipitation blending program selects tiles from one or more of the precipitation tile layers and copies data from the selected tiles to corresponding tiles of an output M _i F ₀ forecast precipitation tile layer (2031). The output forecast precipitation tile layer is a blended precipitation tile layer that is saved to the precipitation forecast database (325). In some exemplary embodiments, a precipitation forecasting program uses a blended precipitation tile layer as an initial forecast precipitation tile layer (e.g. the M _i F ₀ -forecast precipitation tile layer). [00514] An exemplary precipitation tile layer blending program (918) operates to copy, from one or more source precipitation tile layers, precipitation data to a selected tile of a (blended) forecast precipitation tile layer, as detailed in the exemplary tile blending method. Referring now to Figure 22, at step 20110 the precipitation blending program retrieves, from system databases, two or more input precipitation tile layers and associated quality metrics. Quality metrics, for example pre-computed accuracy improvement metrics, quantify a confidence in data contained in each of the input precipitation tile layers. At step 20120, the precipitation blending program ranks each input precipitation tile layer based on corresponding quality metric data. The precipitation blending program generates an empty blended precipitation tile layer at step 20130 and selects, at step 20140, a first empty blended precipitation tile to populate with data from one of the input precipitation tile layers. At step 20150 the precipitation blending program determines the highest ranked tile layer that includes data corresponding to the selected empty blended tile layer tile. For example, the precipitation blending program first determines whether a tile of the highest ranked input precipitation tile layer corresponding to the selected blended precipitation tile layer includes precipitation data and, if it does not then determines whether a corresponding tile of the second highest ranked input precipitation tile layer includes precipitation data. The precipitation blending program, at step 20160, copies data from the highest ranked input tile layer determined in step 20150 into the selected empty tile of the blended tile layer, determines whether the blended precipitation tile layer includes additional empty tiles at step 20170 and, if so, selects one of the empty tiles at step 20180 and returns to step 20150 to populate the selected empty blended precipitation tile with data from one of the input precipitation tile layers. In this manner, the precipitation blending program copies precipitation data from input precipitation tiles layers by implementing the tile blending method for each tile of the blended

precipitation tile layer. The precipitation tile layer blending program repeats steps of the tile blending method until all tiles of the forecast precipitation tile for which at least one input tile layer are available have been populated with precipitation data after which the tile precipitation blending program can fill in missing data in the forecast precipitation tile layer, for example by copying data from another cadence instance or by interpolating data from tiles adjacent to a tile for which data is missing. [00515] In further exemplary embodiments, the precipitation blending program blends precipitation tiles of precipitation tile layers including estimated microwave precipitation tiles of two or more of microwave precipitation tile layer (2022a,b), radar precipitation tiles of a radar precipitation tile layer (not shown), and ground weather sensor tile layer (2021). In a particular exemplary implementation of blending method (20000), the precipitation blending program (918) blends precipitation estimates calculated from microwave attenuation generated collected data (e.g. microwave precipitation tile layer (2022a or 2022b) with precipitation estimates calculated from radar reflectivity processed collected data (e.g.

estimated radar precipitation tiles). [00516] In additional exemplary embodiment(s) one or more additional weather parameter blending program(s) (not shown) are configured to blend non-precipitation weather parameter data using a blending method similar to the method illustrated in Figure 22. For example, in an exemplary embodiment a wind blending program (not shown) blends wind data from two or more sources, for example wind data from NWP ground weather database (353) and wind data from weather station database (323). [00517] In an alternative embodiment, the precipitation blending program blends two of more input tile layers using an alternative an image processing-based blending process that blends two or more input tile layers by first representing the input tile layers as images, for example by converting precipitation tile layer values to grayscale pixels wherein the darkness of a pixel corresponds to a magnitude of the value of a precipitation estimate for the tile. The precipitation blending program then extracts objects from the images using one or more image processing techniques, morphs and blends the extracted objects from two or more input tile layers to generate a blended image, and translates pixels of the blended image to precipitation estimate values on a blended precipitation tile layer. In an exemplary image processing-based blending process, the blending program weights the input forecasts based on accuracy improvement data and uses a weighted morphing blending algorithm to blend the input forecasts. 6.8.2 Machine Learning programs

[00518] In some exemplary embodiments, the modeling and prediction server includes machine learning-based programs that operate as stand-alone programs or as parts of other programs. These programs are configured to use pre-calculated/pre-trained machine learning models and to implement trained algorithms in order to generate weather parameter estimates and forecasts. Machine learning model training takes place on the offline/background server. [00519] This section describes generic programs and process flows for executing trained machine learning models to generate prediction or inference data in real time and during post- processing. These programs and process flows may be modularly added to any of the processing programs described above in Table 12 in order to enable the execution of machine learning models / rules for data and cadence processing. [00520] The ML model execution module (946) retrieves a trained ML model and a corresponding ML model quality metric from the system database (320). As mentioned above, the ML model execution module is a generic program that can be a component of, or be called by, one or more programs in the cadence stack. [00521] Based upon its configuration settings, the ML model execution module retrieves ML model input data, for example processed collected and generated collected weather parameter data and historical forecast data, from one or more systems database(s). The ML model execution module executes the trained ML model using the input data to generate ML model output data which is stored in the system database (320). The ML model output data can include weather parameter estimates, predictions, and forecasts, depending on the ML model that is executed, and is saved to a tile layer of a cadence instance tile stack. The ML model execution module can associate a quality or certainty metric, retrieved from the system database (320), with the ML model output. [00522] In an exemplary embodiment, the ML model execution module executes a neural network with data from one or more“ground truth” weather data sources that are located within one or more specific microwave link areas of effect, and calculates weather data based upon“ground truth” readings and microwave link attenuation. In a particular exemplary embodiment, the ML execution module retrieves a precipitation neural network classifier model and executes the neural network classifier with measured microwave link attenuation from one or more microwave links and collected processed measurement data from ground stations within a threshold distance, e.g. within one kilometer, or within an area of interest, of each microwave link. The processed collected weather station data can include, for example, precipitation, temperature and relative humidity. In an exemplary embodiment the ML execution module executes the precipitation neural network classifier with time series of collected processed microwave link attenuation values from one or more microwave links and with time series of one or more of precipitation, relative humidity, and temperature collected processed data values provided by ground stations within the areas of influence of the one or more microwave links. [00523] In an exemplary embodiment, modelling and prediction server (360) includes multiple instances of ML model execution modules (i.e.946a, 946b, etc. (not shown)) or multiple programs that each include an instance of a ML model execution module. Each ML model execution module instance is configured to retrieve and execute a trained ML model. In some exemplary embodiments, ML model execution modules are configured to generate predictions on repeating schedules, e.g., during processing of operations of each cadence cycle, and on demand based on requests from client computing systems. [00524] Expert systems module (948) retrieves, from a system database, data processing rules, retrieves input data, for example weather parameter data, from one or more system databases, and uses the rules to process the input data. In an example embodiment, the expert systems module performs complex event processing (CEP) using the retrieved rules to recognize events and patterns in the input data. The expert system module can be configured to generate alerts and otherwise communicate results generated by the module to other system processes. 6.8.3 Fog Inference and Forecasting

6.8.3.1 Definitions of fog-related terms

[00525] We define a preliminary fog inference, or to preliminarily infer fog as meaning to conclude that fog is present based on reasoning and on evidence including values of weather parameter estimates, for example weather parameter estimates calculated from microwave attenuation measurements. In other words, we define inferring a presence of fog as concluding that the magnitude of a weather parameter estimate, for example a fog liquid water content (LWC) estimate, is indicative of the presence of fog in a geographic location at which fog the weather parameter estimate is measured or calculated. In a particular exemplary embodiment where fog LWC estimates are calculated based on microwave link attenuation measurements, inferring a presence of fog includes inferring that a measured microwave link attenuation is due to one or more microwave links passing through a portion of the atmosphere that includes fog. In an exemplary embodiment, fog LWC is calculated based on a particular attenuation measurement for a particular microwave link or based on microwave link attenuation aggregated from one or more microwave links at a particular geographic location. [00526] We define a confirmed fog inference as concluding that, at a particular time point, fog is present or is likely to be present at a particular location based on conditions preceding the particular time point. Confirming a fog inference can be based on many factors, for example, a pattern of amplitudes of historical fog LWC estimates calculated prior to calculation of a particular current LWC estimate, previous fog determinations, and one or more collected or predicted weather data. [00527] We define detecting or detection of fog as an observation of fog by a human observer or by an instrument capable of directly detecting fog or directly measuring atmospheric parameters such as liquid water content and droplet size distribution that can be used to confirm a presence of fog. [00528] We define forecasting of fog as concluding that, at a particular location and at a future time point or at a series of future time points, fog will be present or will likely be present. [00529] The presence or absence of fog greatly influences attributes such as visibility, which are essential for use in determining and reporting RVR and visibility related weather conditions. It can be difficult or impossible to determine, from collected data at an isolated time point, whether a particular set of collected data (e.g. precipitation derived from microwave attenuation) indicates a presence of fog, rain, a high local atmospheric water density in the absence of fog, or a combination of fog and another atmospheric hydrometer such as a light rain. [00530] The disclosed methods improve fog inference, including at locations that are not within detection range of a known fog detection instrument or human observer, by determining whether, based on a magnitude of measured magnitude of a fog-related weather parameter value (for example a weather parameter estimate calculated from measured microwave link attenuation), the weather parameter is indicative of fog at one or more locations. In a particular embodiment, after the system applies one or more transforms to a set of microwave link attenuation measurements to calculate fog liquid water content (LWC) estimates at a one or more locations and creates machine learning rules that infer that fog is present at locations where estimated fog LWC magnitude is greater than zero or greater than a configurable detection threshold (TFogLow) and, in some embodiments, where estimated fog LWC magnitude is less than a threshold amount (TFogHigh) that is indicative of precipitation or other non-fog atmospheric condition, for example less that a maximum likely LWC of fog at a particular location. [00531] The system then uses time series analysis to determine whether or not fog, versus some other hydrometer, is likely at locations where a presence of fog has been inferred, for example based on a time series of fog LWC estimates. A prediction of likelihood of fog based on fog predictive models is used to influence a determination of or confidence in a LWC - based fog inference. [00532] .In an embodiment, time series rules ML models are developed using time series analysis of detected fog events, i.e. fog events detected by a dedicated instrument or human observer, and historic trends in fog LWC estimate magnitude and time rate of change in fog LWC estimate magnitude associated with confirmed fog events. In an embodiment, time series rule ML models are developed using time series analysis of detected fog events and historical precipitation, atmospheric water vapor, or fog /no fog inferences based on microwave link attenuation measurements. The time series rule ML models are used to confirm or refute a fog inference based on a time series of LWC estimates to reduce fog inference false alarm rates. In a particular exemplary embodiment, the time series rule ML models are used to confirm or refute a fog inference based on a weather parameter data value, e.g., based on a LWC estimate value generated from microwave link attenuation measurements to reduce false alarm rates of fog inference based on microwave link attenuation collected data. [00533] The disclosed methods further include using fog predictive models trained with atmospheric data such as temperature, pressure, humidity, LWC, and other fog-related atmospheric parameters, along with, in some embodiments, microwave link attenuation, to predict a presence of fog, an absence of fog, or a probability of fog at a current time point, e.g. at a cadence instance collection time stamp. The predictive model’s fog prediction includes, for example, recognition of conditions that are conducive to fog formation, conditions that are likely to prevent or disrupt fog formation, and conditions under which a non-fog hydrometer capable of attenuating microwave link signal strength is likely to form. Fog prediction results generated by the fog predictive model are used to reduce false positive fog inferences by combining fog inference based on time series analysis of collected processed or collected generated weather parameter data and fog inference based on fog predictive model fog predictions. [00534] In a particular exemplary embodiment, a fog predictive model is configured to produce a binary determination or a probabilistic measure of a likelihood of fog formation which is used to confirm or disprove a fog inference that is made based on microwave link attenuation measurements. [00535] In an alternative embodiment, the system processes current microwave link attenuation measurements for individual microwave links and infers a presence of fog along each link or along one or more segments of each link. The system saves historical microwave link attenuation measurements to a system database. The system generates and updates time series rule ML models based on individual microwave link attenuation. The system processes a time series of attenuation measurements, including historical attenuation measurements, for microwave links using the time series rule ML models to confirm or refute and initial fog inferences based on a current link attenuation measurements. The system then uses a fog or no fog prediction, or a probabilistic fog prediction, generated by the predictive model in the geographic regions that the links traverse to reduce false positive fog inferences by combining microwave link based fog inference and fog predictive model fog predictions. [00536] In a further alternative embodiment, a fog predictive model is configured to determine or adjust weights applied to components of a fog/no fog calculation algorithm that includes microwave link attenuation as an algorithm input. In an exemplary embodiment, a fog predictive model is configured to generate weights corresponding to one or more parameters including: likelihood of fog formation; likelihood of fog dissipation; likelihood of rain; likelihood of cooling trend; likelihood of increasing atmospheric humidity, etc. 6.8.3.2 Fog Inference Program and Method

[00537] The fog inference program (919) retrieves data processing rules including fog time series rule ML models and processes weather parameter data using the fog time series rule ML models to generate fog inference decisions. The fog inference program implements fog inference method (4100). In some embodiments, the fog inference program also implements microwave precipitation, atmospheric water vapor, and LWC estimate calculation method (70910) to calculate microwave precipitation, atmospheric water vapor, and LWC estimates. [00538] In an exemplary embodiment, these programs are used in the fog inference program (919) described below, which typically operates during the post processing portion of the cadence stack and includes the ML model execution component. [00539] The fog inference program is in communication with and can retrieve data from and write data to system database (320) and data cache (720). In an exemplary embodiment the fog inference program inputs fog LWC estimates, for example, from an LWC tile layer (2048) from a precipitation database (356a,b) or from fog inference data database (998), time series analysis rules, and fog predictive model data. The fog inference program produces fog inference data (999) as output. The fog inference program stores fog inference data in the system database and can make it available as fog inference tile layer (2047), that includes fog fog/no fog indications or indications of fog probability at one or more geographic locations. To calculate fog inference data, the fog inference program determines a presence or absence of fog at a subject time period based on calculated fog LWC estimate values at the subject time period, matches one or more time series rule ML models to a time series of fog LWC estimate magnitudes preceding and including the subject time period, and applies fog/no fog or fog probability prediction results included in data output by fog predictive model (926). Fog inference data, recorded on a fog inference tile layer, is stored in fog inference database (998). [00540] In an exemplary embodiment, the fog inference program generates fog inferences using fog LWC estimates calculated by the fog inference program or one or more microwave link precipitation programs using pre-configured transforms. In another exemplary embodiment, the fog inference program generates fog inferences using LWC estimates provided by an external source, for example estimates provided by the National Oceanic and Atmospheric Administration (NOAA) or forecasted estimates provided by a NWP, e.g. HRRR forecast estimates. In some exemplary embodiments, the fog inference program generates fog inferences using blended LWC estimates generated by a blending program that blends LWC estimates from two or more sources. [00541] In an exemplary embodiment, the fog inference program makes a preliminary fog = yes inference at each location where estimated fog LWC is within a range defined by T _FogLow and TFogHigh, as previously discussed. In an embodiment, the fog inference program assigns a confidence to the preliminary fog inference, for example a low confidence indication or a numerical value representing a low confidence. [00542] In an exemplary embodiment, the fog inference program includes an expert systems module (948) that retrieves one or more fog time series rule ML models from a system database (320) and implements the one or more fog time series rule ML models to process input data, for a current (Mi) fog LWC tile layer (2048) and one or more previous cadence instance fog LWC tile layers from fog inference data database (998), to produce output data including time series based fog inference decisions. The fog inference program (919) uses the time series rule ML models to confirm a preliminary fog inference and determine a confirmed fog inference (or in the absence of a confirmation, refute the preliminary fog inference). In an embodiment, the fog inference program increases a confidence indication associated with each confirmed fog inference, for example a medium confidence indication or a numerical value representing a medium confidence. 6.8.3.2.1 Fog predictive model program (926)

[00543] The fog predictive model program (926) which includes an instance of ML model execution module (946) configured to retrieve and execute a trained fog predictive model machine learning model. Each ML model execution module can be configured, for example with a configuration setting, to retrieve and execute a particular trained ML model. The fog predictive model program is in communication with and can retrieve data from and write data to system database (320) and data cache (720). [00544] The fog predictive model is a machine learning model, for example a neural network

algorithm, that is trained using fog-related weather parameter data and detection data to predict fog/no fog for a particular set of weather parameter inputs. In a particular example, the fog predictive model is configured to predict whether or not fog is present given weather parameter values of a current cadence instance. In a particular exemplary embodiment, the fog predictive model is a predictive model that has been trained to recognize sets of conditions and trends that occurred when fog inferences are likely to be correct or incorrect, i.e. whether they are likely to be verified by direct instrument-based fog measurements or human observations. Sets of conditions can include conditions at a particular time point; for example, at the time point at which fog is inferred or a time point preceding a fog inference time point. Sets of conditions can include trends in conditions such as a decreasing or increasing trend in air temperature or and increasing or decreasing trend in prevailing wind speed. Sets of conditions can include conditions that are indicative of an incorrect fog inference such as a combination of prediction of fog, rather than light rain, and ground station measurements of rain accumulation indicative of light rain. [00545] The fog predictive model program retrieves, from a system database, input weather data including, for example, collected processed or collected generated weather parameter data and forecast generated data. The fog predictive model program executes the trained fog prediction model with the retrieved input weather data to produce a binary fog/no fog prediction, a probabilistic fog prediction, and/or parameter weights. The fog predictive model program stores fog predictive model data (996) including fog predictions and/or parameter weights, in fog predictive model data database (997). In an embodiment, the fog predictive model program writes fog predictive model data to data cache (720) and thus communicates the fog predictive model data to the fog inference program without saving it to a system database. [00546] Fog inference program (919) [00547] The fog inference program (919) retrieves the fog predictive model data from the fog

predictive model data database, data cache, or the fog predictive model program. The fog inference program applies fog prediction results or parameter weights comprising fog predictive model data to an attenuation-based fog inference to verify or refute the confirmed inference. In an embodiment, the fog predictive model program compares a fog predictive model probabilistic value to a configurable threshold value (T _verify ) to determine whether to verify or refute the confirmed fog inference. In an exemplary embodiment, Tverify includes a configurable range of thresholds based on geographic location, for example, on a scale or 0 to 1, 0.5 at a first location where, based on historical observations, fog events are common and 0.9 at a second location where fog events are rare. In an embodiment, the fog inference program increases a confidence indication associated with each verified fog inference, for example a high confidence indication or a numerical value representing a high confidence. In a particular exemplary embodiment, the fog inference program calculates a confidence indication value of a fog inference based on a fog probability metric generated by the fog predictive model. The fog inference programs writes for inference data (e.g., fog yes/no or fog probability) to a fog inference tile layer (2047) and stores the inference in fog inference database (998). 6.8.3.2.2 Fog Forecasting Program (931) and Method

[00548] The fog forecasting program is in communication with and can retrieve data from and write data to system database (320) and data cache (720). The fog inference program carries out a fog forecasting method, described herein. [00549] In another embodiment, the fog forecasting program (931), which operates during forecast processing, includes ML model execution module. The program that uses the component defines the ML model or rules to be processed and the dataset to be used. [00550] The fog forecasting program (931) includes an instance of ML model execution module (946) configured to retrieve and execute a trained fog predictive model machine learning model. Each ML model execution module can be configured, for example with a configuration setting, to retrieve and execute a particular trained ML model. [00551] In an embodiment, recent fog-related weather parameter data collected by information normalization and collection server (310) from weather sensor data sources and generated collected weather parameter data, e.g., calculated or collected LWC estimates, and collected or internally generated numerical weather forecast model output, e.g generated data produced by the fog predictive model program and/or collected processed data from NWP model data source (341), are used to make short-term forecasts (e.g. NowCasts) for fog and LWC at given locations, and, in some embodiments, to forecast fog at further forecast time points based on forecasted fog-related weather parameter data. [00552] In one exemplary embodiment, the fog forecasting program retrieves, from a precipitation database or from the fog inference data database, one or more LWC tile layers (2048) corresponding to MiF0 forecast time point and calculates forecast fog or LWC at further fog forecast time periods, i.e. at time periods corresponding to M _i F _j fog forecast tile layers (2049). In an exemplary embodiment the fog forecasting program retrieves at least one of fog inference data (999), generated collected LWC data calculated from microwave link precipitation estimates (626a,b), and NWP processed data (619a,b) including wind vector forecast data and in some embodiments other measured or forecast weather parameter data. In an example embodiment, the fog forecasting program calculates fog forecasts by advection, e.g., by applying two or three dimensional wind vectors retrieved from NWP databases (329, 353) to LWC estimates. The fog forecasting program writes fog forecast data to M _i F _j fog forecast tile layers corresponding to fog forecast time points. The fog forecasting program saves forecast data as fog forecast data (991) in the fog forecast data database (990). [00553] In another exemplary embodiment, the fog forecasting program retrieves and executes a trained fog predictive model in order to generate forecast fog predictions at forecast time points using forecasted and, in some embodiments, collected weather parameter data. In this exemplary embodiment, the fog forecasting program includes a machine learning model execution module (946). The fog forecasting program retrieves a trained fog forecasting model from a system database (320) and one or more forecast weather parameter tile layers, for example a stack of forecast humidity or LWC estimate tile layers and a stack of forecast temperature tile layers, and, in some embodiments additional fog predictive model input data including, for example, information regarding terrain and bodies of water. The fog forecasting program generates a fog forecast tile layer at each fog forecast time point by executing the trained fog predictive model at each fog forecast time point using the retrieved forecast weather parameter tile layer(s) corresponding to the fog forecast time point. In a first exemplary embodiment the fog forecasting program generates a fog forecast using weather parameter forecast tile layers from a single cadence instance forecast stack. In a second exemplary embodiment the fog forecasting program generates a fog forecast using collected and/or forecast weather parameter tile layers from one or more previous cadence instances. In a particular example, the fog forecast program generates a fog forecast using current cadence cycle weather parameter forecast tile layers at fog forecast time points for which current weather parameter forecast tile layers are available and using collected or forecast weather parameter tile layers from one or more other cadence cycles at fog forecast time points where current weather parameter forecast tile layers are not available. The fog forecasting program stores fog forecast data (991) in fog forecast data database (990). [00554] As will be discussed in further detail below, fog inference and LWC is used to estimate visibility and runway visual range (RVR) at the given locations and NowCasting is used to forecast visibility and RVR at the given locations based on forecast fog and LWC of the forecast fog at future time points. In an embodiment, up to 3 hours of historical observations from surface stations are processed and forecasts for a period up to 3 hours in advance are generated. [00555] In a further embodiment, fog forecasts for more than three hours, for example up to 6 hours, are generated. Forecasts up to 6 hours are useful for transportation applications, including aviation applications. For example, in the United States the Federal Aviation Administration (FAA) operates the Enhanced Traffic Management System (ETMS) which manages the US airspace. The ETMS projects flights up to 6 hours in advance from takeoff to arrival, partially based upon landing slots being available. 6.8.3.2.3 Exemplary Method for creating Fog Inferences

[00556] Referring to Figure 23, an illustrative method (4100) is shown for making fog inference decisions based on atmospheric LWC. The method includes steps to infer a presence or absence of fog based on current LWC estimates and time series rule ML models and to confirm or refute fog inference decisions, and using fog predictive data from a predictive model to verify a confirmed fog inference. In a particular exemplary embodiment the system infers a presence or absence of fog using data including LWC estimates calculated as generated collected data based on microwave link attenuation collected data. In an exemplary embodiment the fog inference program uses fog transforms to generate LWC estimates based on collected processed microwave link attenuation data, for example terrestrial, satellite, or combined terrestrial and satellite microwave link attenuation data. In an alternative exemplary embodiment, a microwave link precipitation program generates LWC estimates. [00557] A fog inference processing instance begins at step 4025. At step 4025 the fog inference program retrieves fog transforms from a filter and transform database and retrieves a fog LWC tile layer (2048) from fog inference database (998) or from another system database, for example a microwave precipitation database. [00558] At step 4030, the fog inference program determines if at least one tile of the fog LWC tile layer includes LWC within a threshold range of value, encoded within the fog transforms that is indicative of fog. If yes, the fog inference program selects a fog LWC tile with fog LWC within the threshold range of values and makes a preliminary fog = yes inference for the selected LWC tile and records the preliminary inference to a corresponding tile of a fog inference tile layer (2047) with, in some embodiments, a confidence score associated with the preliminary inference. If no, the process ends. [00559] At step 4035 the fog inference program retrieves one or more fog time series rule ML

models from a system database (320) and retrieves a time series of fog LWC tile layers, for example fog LWC tile layers generated or collected during one or more preceding cadence intervals, from the fog inference database or from a precipitation database. The fog inference program applies the fog time series rule ML model(s) to a time series of LWC estimates corresponding to the selected tile to make a confirmed fog/no fog or fog/precipitation inference based on the preliminary inference. The fog inference program generates the confirmed inference by using the fog time series rule ML models to determine whether one or more patterns of fog LWC estimates in the time series matches a pattern of fog LWC estimates that indicate that fog is or is not present or that precipitation is present. In an embodiment, the fog inference program applies fog time series rule ML models to a time series of fog LWC estimates that include a current, real time, fog LWC estimate and recorded fog LWC estimates from the preceding three hours. If a pattern of fog LWC estimates matches a pattern of LWC values that is indicative of fog, the fog inference program determines that fog could be present in the location covered by the selected tile during the current cadence instance. If so, the fog inference program confirms the preliminary fog inference. The fog inference program records the confirmed inference to the corresponding fog inference tile layer (2047) and, in some embodiments, increases the associated confidence score. [00560] However, if, at step 4035, the fog time series rule ML models indicate that fog is not

present or that fog is not likely then the fog inference program refutes the preliminary fog inference, records a no fog result, and in some exemplary embodiments an inferred precipitation result, for the selected tile, and proceeds to step 4060 to determine if there are additional locations, i.e. additional tiles with LWC values within a threshold range of values that is indicative of fog, to process. [00561] At step 4040 the fog inference program retrieves fog predictive model data generated by the fog predictive model program (926). In an exemplary embodiment, the fog inference program causes the fog predictive model program (926) to generate fog predictive model data and then retrieves the generated predictive model data (996). To generate the predictive model data, the fog predictive model program loads a trained fog prediction model and retrieves weather parameter data including, for example, current cadence cycle microwave link attenuation, temperature, and humidity data. The fog predictive model program processes the retrieved weather parameter data using the trained fog prediction model to generate fog predictive model data. In some exemplary embodiments, the fog predictive model records the likelihood or rain, or probabilistic indication of rain, and magnitude of predicted precipitation to a system data based on a fog or precipitation tile layer. [00562] At step 4045, fog inference program uses the fog predictive model data to verify or refute the fog inference that was confirmed at step 4035. If a confirmed fog inference was generated at step 4035 and the fog predictive model data includes an indication of a presence of fog, the fog inference program verifies the confirmed fog inference determination at step 4045. If a confirmed fog inference was generated at step 4035 and the fog predictive model data indicates that fog is not present, then the fog inference program refutes the fog inference at step 4045, records a no fog result for the location, and proceeds to step 4060 to determine if there are additional locations with LWC greater than zero or with TFogLow< LWC < TFogHigh to process. If a precipitation inference was made at step 4035, then the fog inference program verifies the precipitation inference without referring to fog predictive mode data at step 4045, records the verified inference result to the corresponding fog inference tile, and in some embodiments increases or recalculates the associated confidence score. In an exemplary embodiment, the fog inference model calculates and records a fog probability metric to the corresponding fog inference tile. [00563] In a first example implementation of method 4100, at step 4035 the fog inference program confirms, based on LWC estimates and fog time series rule ML models, an inference that fog is present, i.e. that precipitation is not present. At step 4045, the fog inference program determines that fog predictive model data includes an indication that, based on atmospheric conditions and/or trends, that fog is present or that there is a high probability that fog is present. Based on the presence of fog indicated by fog predictive model data, the fog inference program verifies the fog inference. [00564] In a second example implementation of method 4100, at step 4035 the fog inference

program confirms an inference that fog is present. At step 4040 the fog inference program determines that fog predictive model data indicate that fog is not present or that there is a high probability that fog is not present. Based on the fog predictive model data, the fog inference program determines that fog is not present, i.e. that the fog inference determination that was confirmed by time series rule ML models at step 4035 may be incorrect, and therefore refutes the fog inference. An exemplary set of conditions under which this might occur include microwave link attenuation having a magnitude that, when processed using fog transforms to produce fog LWC estimates, is indicative of a presence of fog. However, fog predictive model data indicate that fog formation is unlikely due to one or more atmospheric characteristics or due to a combination of atmospheric characteristics such as wind speeds that are too high for fog formation, humidity that is too low, and other conditions that are not conducive to fog formation. [00565] In a third example implementation of method 4100, the fog predictive model data include an indication of a high likelihood of rain capable of producing microwave link attenuation similar to that produced by fog, in which case the fog inference program determines that precipitation is a more likely cause of measured microwave attenuation and refutes a confirmed fog inference determination at step 4045. [00566] In a fourth example implementation of method 4100, at step 4035, the fog inference

program confirms a fog inference. At step 4040 the fog inference program retrieves fog predictive model data including a probabilistic fog prediction value. If the probabilistic fog prediction value is greater than a threshold magnitude, T _verify , for example greater than 90% certainty of fog, and the microwave link attenuation data indicates the presence of fog, then at step 4045, the fog inference program verifies the fog inference. [00567] In a further embodiment, the fog inference program determines a verified fog inference based predictive model results generated by the fog predictive model program using inputs including fog LWC estimates, for example LWC estimates calculated by the system based on microwave attenuation measurements In this exemplary embodiment, at step 4045, the fog inference program generates a verified fog yes/no inference based upon outputs the fog inference determination. [00568] At step 4050, the fog inference program stores fog inference data (999), including fog

inference results, e.g. a fog inference tile including fog inference result and associated confidence score, to fog inference data database (998).). [00569] At step 4060, the fog inference program determines if one or more additional locations with LWC within the threshold range of values indicative of fog are available for processing and, if so, returns to step 4035 to process and additional LWC tile. If no additional microwave link data is available, process 4000 ends at step 4065. 6.8.4 Exemplary method for calculating microwave precipitation, atmospheric water vapor, and LWC estimates [00570] Figure 24 includes a flowchart depicting an exemplary microwave precipitation,

atmospheric water vapor, and LWC estimate calculation method (70910) for generating weather parameter data from processed microwave link attenuation data (625a,b) using pre- calculated transforms. Process (70910) is carried out by one or more microwave link precipitation programs (654a,b) or by fog inference program (919). [00571] At step (70911) a microwave link precipitation program retrieves microwave link

processed attenuation data (one or more of (625a,b)) from one or more microwave link attenuation databases (352a,b). [00572] At step (70912) the microwave link precipitation program retrieves pre-calculated link-to- grid and grid-to-tile transforms from transform and filter database (393). [00573] At step (70914), the microwave link precipitation program processes the retrieved

microwave link processed attenuation data (625a,b) using link-to-grid transforms to generate one or more of precipitation, atmospheric water vapor, and LWC at one or more grind points of a static microwave grid. When processing satellite microwave link processed attenuation data (625a), the microwave link precipitation program uses link-to-grid transforms to project satellite link segments to planes, apportion attenuation to the satellite microwave link segments, and to satellite microwave link points, and to generate, based on attenuation mapped to each link point, precipitation, atmospheric water vapor, and LWC at static microwave grid points of static microwave grids corresponding to planes onto which satellite link segments are projected. At step (70915), the microwave link precipitation program uses grid-to-tile transforms to map gridded precipitation, atmospheric water vapor, and LWC estimates to tiles of one or more precipitation, atmospheric water vapor, or LWC tile layers as atmospheric precipitation and water vapor estimates (626a) or precipitation estimates (626b). Application of grid-to-tile transforms can include using projection or clipping transforms to project the precipitation, atmospheric water vapor, or LWC estimates to one or more planes, each plane corresponding to a corresponding tile layer. [00574] At step (70916), the microwave link precipitation program saves the precipitation,

atmospheric water vapor, and LWC estimates (626a,b) to a microwave link precipitation database (356a,b) and process (70910) terminates (70917). [00575] In a further exemplary embodiment, a microwave link precipitation program performs a method substantially similar to method (70910) to calculate ground level precipitation estimates using both satellite and terrestrial microwave link attenuation collected data. In this embodiment the microwave link attenuation program retrieves, at step (70911) both satellite microwave link processed attenuation data (625a) and terrestrial microwave link processed data (625b), from satellite and terrestrial microwave link databases, and retrieves combined terrestrial and satellite microwave link transforms from the filter and transform database at step (70912). The microwave link precipitation program processes the microwave link attenuation data to calculate weather parameter data values, for example one or more of microwave link precipitation, atmospheric water vapor, and LWC estimates on a ground level microwave precipitation tile layer (2022a,b) or LWC estimates on a ground level LWC tile layer (2048). The microwave link precipitation program further calculates confidence metrics for each weather parameter data value. [00576] Methods substantially similar to those discussed in relation to Figure 24 can be used by the satellite microwave link precipitation program to estimate, for example, atmospheric water vapor from GPS satellite signal delay measurements, atmospheric precipitation rates from satellite microwave attenuation or delay measurements, and cloud water content from satellite microwave attenuation measurements by substituting appropriate collected data and collected-to-generated-data calculation transform (e.g. precipitation estimate calculation transforms) for satellite microwave attenuation collected data and/or satellite microwave attenuation-to-atmospheric water transforms. [00577] Terrestrial microwave link precipitation program (654b) [00578] In an embodiment, the terrestrial microwave link precipitation program retrieves, from

terrestrial microwave link attenuation database (352b), terrestrial microwave link processed attenuation data (625b) including baselined and filtered attenuation data that has previously been mapped to microwave links and associated with pre-calculated link-to-grid and grid-to- tile transforms by terrestrial microwave link data processing program (652b). The terrestrial microwave link precipitation program retrieves, from transform and filter database (393), the associated pre-calculated link-to-grid and grid-to-tile transforms and uses the transforms to calculate precipitation estimates for each microwave link, map the precipitation intensity to a ground level static microwave grid, and map gridded precipitation estimates to tiles of terrestrial precipitation tile layers (2023). The terrestrial microwave link precipitation program saves gridded and tiled precipitation estimates as terrestrial microwave link precipitation estimates (626b) to terrestrial microwave link precipitation database (656b). [00579] Precipitation forecasting program (915) [00580] In an embodiment, the precipitation forecasting program inputs precipitation data from one or more microwave precipitation data (e.g.626a,b, 928) and/or forecast precipitation data (902), NWP processed data (619a,b) including wind vector forecast data, and in some embodiments other measured or forecast weather parameter data, processes the input data using a precipitation forecasting algorithm (e.g. a shift-by-wind algorithm) or other numerical weather prediction (NWP) model, and produces, as output, forecast precipitation data (902) that includes precipitation forecast data at one or more forecast time points. The precipitation forecasting program stores forecast precipitation data (902) in precipitation forecast database (325) 6.9 Information Distribution and Alerting Server (370)

[00581] Also referring to Figure 2, a fourth server (including a data processing component), is an information distribution and alerting component (370) that retrieves information from the system database (320), or directly from the modeling and prediction server (360), and processes the data received therefrom. [00582] The information distribution and alerting server (370), as illustrated in Figure 25, comprises one or more computer systems similar to the exemplary server illustrated in Figure 3. This server employs one or more processors (870) using specialized programs (810, 820, 830, and 840) to package collected information together with calculated information generated by the system into information products and distribute them to users. In some cases, the distribution takes form of publishing the information products. Typically, this information is provided to users via a web service (840), a notification provider (830) or by other means (not shown). Packaging collected information into information products is performed by a map generation program (810) using data from map data sources (348) and map databases (880) and the results of forecast processing by other servers stored in one or more system databases (e.g. 325). In at least some implementations, data required by the map generation program can be read from system database (320) including one or more databases listed in Table 1, and process the data to make its format usable with the map information as an independent layer of the map, such as for merging, normalizing, or reformatting, by a data manager program (820). Programs (810 and 820) can be stored in and executed from transient or persistent memory (800). This server is connected to the other servers, data sources, and services using traditional networking techniques and interfaces (845a,b). [00583] The map database (880) can be a local database that is part of the system database (320) that stores map information used by the server to produce the information products, or, in an alternative embodiment, the map database (880) may be an external database that is not part of the system database. [00584] Also referring to Figure 2 and Figure 25, a fourth server (including a data processing

component), is an information distribution and alerting component (370) that retrieves information from the system database (320), or directly from the modeling and prediction server (360), and processes the data received therefrom. The processing is performed in order to merge forecast generated data with one or more customized mapping and or information templates (e.g. also retrieved from the system database or from public map sources and data sources such as map data sources (348) and external databases (349)), in order to produce data outputs (380) used for weather-based information products that are distributed to end users. The weather-based information products may be produced on demand or on a scheduled basis. Weather-based information products can include a map and/or report showing current precipitation intensity and other weather conditions over a geographic region; a forecast map showing expected precipitation intensities and other weather conditions over the geographic region, wherein each map may include expected total precipitation accumulation from a given weather event, or the like; as well as other products usable to alert users of potentially hazardous conditions, to track historic weather conditions, to predict further weather conditions, and to provide customized weather maps focused on user selectable parameters (e.g. for a particular building or property, or the like). [00585] The information distribution and alerting server also provides a user interface component (e.g. web interface or API) that permits the user to specify forecast types (e.g. precipitation, RVR), forecast time requirements (e.g. for the next one hour), locations of interest (e.g. an airport (as a whole, such as WBWI) or a specific runway. Other types of specific forecasts also may be requested from the user interface component. [00586] HyperCast program [00587] Referring again to Figure 25, the information distribution and alerting server (370) includes a HyperCast program (890) which communicates with network interface programs such as web interface program (840) and API (835) in order to receive requests for data products from users and to produce displays and reports for delivery to users. User requests include time and weather parameter requests at specific locations of interest, and requests for notification or alerts based upon specific user-specified thresholds. User responses may include data sets comprising data from one or more system databases matching the request time and weather parameter request, screen displays, reports, and/or alerts and notifications based upon request parameters. 6.9.1 Runway Visual Range (RVR)

[00588] Figure 26 illustrates how weather-related runway visibility can affect airport operations. A metric called“Runway Visual Range” (RVR) is calculated for determining runway visibility. Runway visual range is a measure of the horizontal distance a pilot will be able to see down a runway while landing or taking off. As an aircraft (210) descends on a glide path (220) toward an intended touchdown point (230) on a runway (240), it experiences weather conditions in the atmosphere surrounding and above the airport (250). [00589] In order to land or take off safely, pilots must have a minimum required visibility of the runway. On a landing approach, if a pilot does not have adequate visibility of the runway by the time a specific point above the ground is reached (known variously as“Minimum Descent Altitude” (MDA),“Decision Height” (DH), and“Decision Altitude” (DA)) (270), the landing may not proceed (225). The specific altitude or height of the MDA (280) and the distance from the airport where this point (270) is located varies based upon a number of factors. [00590] RVR is used by pilots and air traffic controllers as a metric to determine whether or not it is safe to conduct flight operations and to schedule takeoff and landing intervals. RVR is affected by atmospheric conditions, background lighting, and the intensity of runway lights. Instantaneous RVR is typically determined by sighting either high intensity runway lights or other objects, for example a black object sighted against brighter background lighting, and reported as the greater visual range of the two sightings. Visibility determined by sighting high intensity lights is typically referred to as Va. Visibility determined by sighting a black object is typically referred to as V _k . V _a and V _k can be calculated by solving well-known formulas. An airport can select either Vk or Va to report as RVR; the selection may vary depending upon condition or time of day. [00591] Airports currently use data collected by one or more RVR sensors (245, 246, 247, 248) to determine a measure of the current V _k . Each runway may include multiple RVR sensors including one sensor located at each of the touchdown end (245), far end (248), mid-point (246), and rollout end (247) of a runway. V _k and V _a vary with atmospheric conditions such as rain, snow, hail, or sleet rate and the presence or absence of fog. [00592] To calculate or estimate RVR, an atmospheric light extinction (b) is calculated and then used as a parameter that is included in an equation that is solved numerically to determine Va. The atmospheric extinction coefficient for rain (br) can be parameterized using equation 4: br = aR ^b (4) where R is the instantaneous or forecast precipitation intensity and a and b are atmospheric extinction parameters that can be determined by experimentation and modelling. [00593] Exemplary parametrization for extinction coefficients for snow (bs) and for fog (bf) are also known. [00594] The estimated LWC of a fog field can be used to estimate visibility (V) using well-known equations as a function of measured attenuation, microwave link frequency, and temperature. Visibility estimates calculated based on fog LWC can be expressed in terms of RVR (i.e. Cat 1, Cat 2, etc., meters or feet, one bar equals 1500m, 2 bars equals 1000, 3 bars 500m or Cat 1, etc.). [00595] RVR Forecasting Process [00596] Although the methods and systems disclosed herein are useful for estimating and

forecasting a plurality of visibility measurement and/or reporting types, the following discussion of illustrative embodiments includes forecasting runway visual range (RVR). The system can be configured to estimate and forecast additional or alternative visibility measurement types can by substituting suitable equations and parameterizations, and associated data inputs, for those discussed in relation to RVR. Illustrative, non-limiting, visibility types that the system can be configured to estimate and forecast include runway visual value (RVV), meteorological optical range (MOR), surface visibility, tower level visibility, prevailing visibility, sector visibility, and observer visibility. In an additional, non- limiting, embodiment the system can be configured to estimate and forecast flight and vertical visibility at one or more selected altitudes, for example at one or more altitudes or altitude ranges corresponding to Visual Flight Rules (VFR) weather minimums and/or classes of air space. In a still further exemplary, non-limiting, embodiment the system can be configured to estimate and forecast, based on visibility estimates and forecasts, AOT. AOT is defined as the integrated vertical extinction coefficient over a vertical atmospheric column of unit cross-section. 6.9.1.1 Overview of RVR forecasting

[00597] We define instantaneous RVR as the actual current RVR calculated for a runway or airport as read from the RVR sensors deployed at an airport. We further define the forecast RVR as a RVR estimate or a sequence of RVR estimates projected into the future, where the forecast RVR is calculated by the system as an additional forecast parameter based upon the forecast precipitation amount and type at the airport location or based on inferred forecast fog and forecast LWC. Referring to Figures 5 and 6, forecast RVR is included as a forecast RVR tile layer of a forecast stack MiFj and forecast RVR includes a time zero, or real time, RVR at MiF0 and RVR at future forecast time periods bounded by the range M _i F _(1-n) . [00598] In an exemplary embodiment, the forecasting system (300) generates RVR forecast tile layers that include RVR forecast over an entire region that is covered by a precipitation or fog forecast tile layer. That is, the system can forecast RVR at every region where precipitation intensity forecasts are generated. In alternative embodiments, the system limits RVR forecasts to locations or areas that are specified as locations of interest by users and customers. The following discussion includes generating RVR forecasts at selected locations but these are not intended to be limiting examples. The system can also generate RVR forecasts over larger, non-specific, regions, for example over an entire forecast tile layer. [00599] A user can interact with information distribution and alerting server (370 of Figure 2) select a location of interest, for example by entering a request, for the forecast RVR report via network interface (845a) and request that RVR forecasts should be generated for the selected location of interest, for example for a particular runway or airport. This selected location of interest is stored in the system in location of interest database (391). Although the following discussion is limited to requesting RVR reports or notifications at specific times and locations, similar methods can be used to request reports and forecasts of fog, including fog LWC or intensity, or reports and forecasts of other weather phenomena at selected locations and time points. [00600] Referring to Figure 27, a user requests a report or notification of RVR at one or more

desired locations of interest by interacting with an overview map (1110) to select a location for RVR forecast by placing a flag (1410) or defining a polygon (1510) on the overview map. For example, a user can place a flag at the touchdown end of one or more selected runways at an airport to request an RVR report at each selected runway touchdown end. [00601] A user can request an RVR report for a desired area of a map such as a runway or airport by drawing, on a display, a polygon that encloses the desired area. The information distribution and alerting server retrieves RVR forecast data from each tile that is enclosed by the polygon and reports the minimum RVR corresponding to the area enclosed by the polygon. A user can draw a polygon around a runway to request an RVR report for the entire runway, i.e. to request a report of the minimum RVR along the entire runway. A user can draw a polygon around an entire airport to request a report that includes the minimum RVR at the airport. For example, referring to Figure 19A, a user defines polygon (3010) to enclose airport (3015) and polygon (3012) to enclose runway (3016). A user can specify multiple flags, multiple polygons, or a combination of flags and polygons. The information distribution and alerting server will report RVR for each flag and polygon. [00602] In some exemplary embodiments, one or more alternative selection methods are used to request an RVR report corresponding to an airport or a runway. For example, a user can select an airport or runway from a list of airports and runways and can further specify an RVR location along a runway, for example a user can specify a touchdown RVR location on a particular runway. [00603] The information distribution and alerting server saves selected RVR forecast locations to RVR location of interest database (391) and updates the location of interest database when RVR forecast locations are added or removed. [00604] A user can specify a particular time, which can include current time or a time point in the future, for which a report of RVR is desired. A user can specify a report of RVR over a span of time in which case the information distribution and alerting server will return RVR values for multiple time points within the specified span of time. Additionally or alternatively a user can schedule periodic RVR reports. Additionally or alternatively a user can select airports and runways and defer request of an RVR report or forecast until a later time. In an exemplary embodiment the system is configured to generate RVR forecasts whenever precipitation forecasts are generated. In a first configuration the precipitation forecasting program (915) alerts the RVR forecasting program (920) when a set of precipitation forecast tile layers (e.g. a set of forecast precipitation tiles from M _i F _(0-n) ) or a set of fog forecast tile layers (e.g. a set of forecast fog LWC tiles from M _i F _(0-n) ) is available and the RVR forecasting program generates an RVR forecast following the completion of calculations of a precipitation forecast. In a second configuration precipitation forecasting program (915) alerts the RVR forecasting program (920) when a forecast precipitation and/or fog tile layer available and the RVR forecasting program generates forecast RVR tile layers substantially in parallel with calculation of forecast precipitation. In a similar manner, in some exemplary configurations, the fog forecasting program alerts the RVR forecasting program when new fog forecast generated data is available. [00605] The information distribution and alerting server communicates with other servers, including information collection and normalization server (310) and modelling and prediction server (360), to cause the other servers to pre-configure precipitation-to-RVR and fog-to-RVR programs, collect input data, retrieve forecast precipitation data and forecast fog data, determine forecast RVR, and then to make the forecast RVR data available to the information distribution and alerting server for use in generating a forecast RVR report, for example by storing forecast RVR data (922) to RVR forecast database (923). 6.9.1.2 Illustrative method for calculating, forecasting, and reporting RVR

[00606] Referring to Figure 28, an illustrative precipitation-to-RVR method (2400) is shown for producing RVR estimates and forecasts. It comprises steps to process precipitation measurements and forecast estimates, to calculate RVR, and to produce RVR forecasts and reports. A method similar to precipitation-to-RVR method can be used to produce RVR products using additional or alternative inputs including, for example, fog and atmospheric LWC estimates. RVR forecasting program (920), operating on modeling and forecasting server (360), performs steps of the precipitation-to-RVR method. [00607] In an embodiment, the RVR forecasting program inputs data including at least one of forecast precipitation data (902), fog forecast data (991) related RVR ancillary data and produces, as output, forecast RVR data (922) for one or more forecast time points and locations. The RVR forecasting program saves forecast RVR data (922) to forecast RVR database (923). [00608] The precipitation-to-RVR method step begins at step (2330) with the RVR forecasting program receiving a request, for example from the information distribution and alerting server, for an RVR report, the request including one or more RVR locations of interest (in this case airport (3015) and runway (3012)) and RVR forecast time point(s). Referring to Figure 19C, at step (2332), the RVR forecasting program retrieves pre-calculated

precipitation-to-RVR transforms corresponding to the location of interest from transform and filter database (393). The pre-calculated precipitation-to-RVR transforms include mapping of precipitation tile layers to RVR location tile sets (3220, 3222), precipitation-to-RVR equations, and ancillary RVR data. [00609] At step (2334), the RVR forecasting program retrieves forecast precipitation tiles (3050a, 3050b, 3050c…3050n) from precipitation forecast database (325). Additional atmospheric data, which can include temperature (T), relative humidity (RH), dew point temperature (Td), smoke and dust data can also be retrieved from or one or more additional databases such as weather sensor database (323) if not already stored in the RVR location and ancillary data database. The additional atmospheric data can include data collected by one or more weather sensor data sources (346) which can include weather stations located at or near an airport and can include forecast generated data provided by a NWP model data source (341). If necessary data is not available from a data source, the RVR ancillary data collection program can be prompted to perform calculations to determine the missing data and store it to an appropriate database. For example, T, RH, and smoke and dust data can be requested from the airport. T _d can be estimated based on T and RH. [00610] Referring to Figure 19C, each arrow labeled as precipitation-to-RVR transform (3222a– 3222n and 3220a– 3220n) represents processing, by the RVR forecasting program, and using the corresponding precipitation-to-RVR equations, precipitation data from precipitation forecast data tiles to generate RVR data in RVR forecast tiles. Airport precipitation-to-RVR transforms (3220a– 3222n) are applied to airport precipitation forecast tile sets (3020a– 3020n) to generate airport RVR forecast tile sets (3120a– 3120n). Runway precipitation-to- RVR equations (3222) are applied to airport precipitation forecast tile sets (3022a– 3022n) to generate airport RVR forecast tile sets (3120a– 3120n). Alternatively, tile layer precipitation- to-RVR transforms can be applied to all tiles of precipitation forecast tile layers (3050a– 3050n) to generate RVR forecast at all tiles of RVR forecast tile layers (3150a– 3150n). Processing of precipitation data to generate data for RVR forecast tiles can include, at each forecast time interval (F0-Fn), repeating process steps (2340–2380) to calculate parameters used in precipitation-to-RVR equations. Alternatively, one or more parameters (e.g. Et, b parameterization) can be determined once, for example when calculating RVR estimates at M _i F ₀ , and can be re-used for subsequent applications of the precipitation-to-RVR equations, i.e. when calculating RVR at MiF(0+1 - n). [00611] The RVR forecasting program determines or estimates threshold illuminance E _t for each RVR location tile set at step (2340). E _t varies with background illumination. The RVR forecasting program can retrieve background illumination (BL) from the RVR location and ancillary data database (929) and calculate Et based on measured background light (BL). [00612] In an exemplary method, instead of calculating Et, the RVR forecasting program uses an estimated value of Et = 1e ^-6 for daytime calculations and an estimated value of Et = 1e ^-4 is used for nighttime calculations. This is useful, for example, if BL data is not available from an airport or to reduce the use of processing resources. [00613] At step (2350), the RVR forecasting program determines a parameterization for the

atmospheric extinction coefficient b as a function of retrieved forecast precipitation rate and other forecast atmospheric data. The parameterized atmospheric extinction coefficient is used with the Allard and Koschmieder formulas to determine RVR, as will be discussed in more detail below. A different parameterization of b is applicable to each of multiple precipitation types, for example referring to equation 4, atmospheric extinction coefficient for rain br is applicable for rain. Additional parameterizations of b include b _s , which is applicable for snow, bf, which is applicable for fog, and additional parameterizations which are applicable for sleet, hail, smoke, dust, and other atmospheric conditions and combinations of atmospheric conditions. [00614] In an exemplary method for determining extinction parameters to use for forecasting RVR, the RVR forecasting program retrieves MiF0 precipitation intensity and measured Vk corresponding to each RVR location tile set (3020, 3022) and determines a plurality of calculated V _k using the M _i F ₀ precipitation intensity with each V _k calculated using a set selected from a plurality of sets of well-known extinctions parameters, each set corresponding to a different parameterizations of b. The RVR forecasting program then compares the plurality of calculated values of Vk and selects, for use in forecasting RVR at each RVR location, the extinction parameter set corresponding to the calculated V _k that most closely matches the measured V _k at the location. Analogous methods for selecting parameterization variables can be used when RVR is determined for precipitation other than rain, for example for fog or snow. [00615] At step (2360), the RVR forecasting program calculates, for each RVR location tile set (3020, 3022), a value for b using the parameterized expression and extinction parameters determined for b at step (2350). [00616] At step (2370), the RVR forecasting program calculates V _k and V _a for each tile of RVR location tile set (3020, 3022) by solving the Allard and Koschmieder formulas using the value for b determined at step (2350) and the value for Et determined at step (2360). A particular value of e (threshold contrast) is assumed, typically ranging from 0.1 to 2.0, when solving the Allard and Koschmieder formulas. In an exemplary embodiment, e is assumed to be 0.05. [00617] At step (2380), the RVR forecasting program selects one of V _k or V _a to report as RVR at each tile of RVR location tile set (3020, 3022). In an embodiment, the visibility (V _k or V _a ) having the largest value is selected. The RVR forecasting program then stores RVR forecast results as a RVR forecast tile layer corresponding to the current forecast time interval (one of 3150a, 3150b, 3150c…3150n) of forecast stack M _i F _j in forecast RVR database (923) at step (2385). The RVR forecasting program then repeats calculation of RVR for each forecast time interval bounded by the set MiF(0-n) by repeating steps (2350) through (2380), or alternatively repeating steps (2360) through (2380) if the precipitation type at a time interval is the same as the precipitation type at a previous time interval. RVR can be determined at each time point for which forecasted precipitation tile layers (3050a– 3050n) are available in data that was retrieved from precipitation forecast database (325) at step (2330). [00618] At step (2390), the information distributing and alerting server retrieves stored RVR

forecasting data from RVR forecast database (923) and prepares a forecast RVR report using the data. The RVR report can include RVR data reported in a format suitable for the customer’s needs. For example, RVR can be reported as a single value of RVR at the runway touchdown end for use by pilots whose airplanes are on an approach course to an airport. RVR can be reported at both touchdown and rollout locations of one or more runways at the airport, for example for use by air traffic controller scheduling decisions or for use by a shipping vendor to predict possible shipping delays due to poor visibility. [00619] The RVR forecasting program implements a method substantially similar to that illustrated in Figures 19A-C to generate forecast RVR based on fog inference data and fog forecast data corresponding to one or more tiles comprising a RVR location tile set (3020, 3022). In an exemplary embodiment, the RVR forecasting program, at step (2330) queries each of precipitation forecast database (325) and fog forecast data database (990) to determine if tiles corresponding to RVR location tile set (3020, 3022) include forecast precipitation results or forecast fog results. If forecast precipitation tiles corresponding to the RVR location tile set include non-zero values of forecasted precipitation estimates, the RVR forecasting program carries out the precipitation-to-RVR forecasting steps described above in relation to Figures 19A-B. [00620] If, however, forecast precipitation tiles corresponding to the RVR location tiles do not include precipitation estimate values, and forecast fog tiles corresponding to the one or more RVR location tiles include an indication of the presence of fog, for example atmospheric LWC with a magnitude indicative of fog (e.g., 0.05 g/m ³ ), the RVR forecasting program retrieves fog-to-RVR transforms, along with any additional atmospheric data specified by the fog-to-RVR transforms, and uses the transforms to estimate RVR due to fog in the one or more RVR location tiles. In an example embodiment, fog-to-RVR transforms include well- known models relating RVR to LWC as a function of LWC and N _D where N _D is number droplet concentration. The RVR forecasting program retrieves LWC from a forecast fog or LWC tile layer and N _D from a numerical weather prediction (NWP) data tile layer. In a further example embodiment, , fog-to-RVR transforms include equations for solving for V _a and/or Vk using an extinction coefficient for fog (bf). bf is a function of prevailing temperature, dew point temperature, and relative humidity. The RVR forecasting program retrieves forecast values of these parameters for corresponding tiles and forecast time points and uses them to estimate forecast RVR. RVR forecast data based on fog forecast data is stored in RVR forecast database (923) from which it can be retrieved by information distributing and alerting server (370) and used to generate an RVR forecasting report. An RVR forecasting report can include RVR forecast data based on precipitation and RVR forecast data based on fog. [00621] RVR is reported by the information distribution and alerting server (370) at each flag

location and polygon. Referring to Figure 29, RVR can be reported in each of multiple mini status windows (1710, 1720, 1730, 1740). For each selected location, flag, or polygon, RVR can be reported as a distance or as a category (i.e. Cat1, Cat2, Cat3, Cat3A) and can be reported as a single value or on a plot. An RVR plot is displayed in a mini status window as stacked bars with each bar representing a distance or category. For example, one bar equals 1500m, 2 bars equals 1000, 3 bars 500m or Cat 1, four bars 350m or Cat 2, five bars 200m or Cat 3, six bars 150m or Cat 3A. If RVR varies by more than one reportable variable over a ten minute period, the lowest and highest values are reported with a letter“V” interposed between them. [00622] RVR can be plotted on timeline (1120)(not shown). A timeline RVR plot can include time on a horizontal axis and RVR represented on a vertical axis as a stack of bars, as previously described, at each time point of the horizontal axis. An RVR report can include alerts such as a current or predicted RVR value that could prevent an airplane from landing or taking off. Different aircraft and aircraft equipped or not equipped with specific equipment can be associated with different RVR threshold values for takeoff and landing decision points, for example as function of the type of instrumentation that is available to a pilot on the aircraft. For example, an aircraft must be equipped with an approved lateral guidance system to be approved for a low vision take off (LVTO), i.e. a takeoff when RVR is below 125 m but greater than 75 m. Training that a particular pilot has received can also affect RVR threshold values for takeoffs and landings. Alerts can be based on the threshold RVR values associated with each aircraft and/or with each pilot. [00623] In addition, RVR reports can include an indication of RVR at one or more runways superimposed on an image or map of the airport or of a specific runway. For example, RVR can be indicated by a runway image being shaded with a color representing a value of RVR falling within a specified range of RVR values. For example, blue shading indicating RVR > 6000 ft., green for RVR between 6000 and 1200 ft., yellow for RVR between 1200 and 600 ft. (which can indicate low visibility conditions), and red for RVR less than 600 ft. (which can indicate takeoffs and landings are prohibited). [00624] RVR can be reported as a single value and/or color for an entire runway, as discrete values and colors at each end and at selected locations along a runway, or as a continuous range of values along a runway. For example, a runway image can be subdivided into discrete segments and each discrete segment can be shaded with a color representing RVR at the segment. The prepared RVR report is provided to the customer by distributing and alerting server (370), for example by communicating the report to the customer via network interface (845b). 6.10 Example Uses of the Technology 6.10.1 Transportation

[00625] Ground or water transportation customers can receive per-route weather monitoring and forecasting data to help operational planners, drivers, and other transport operators select an optimal route and modify a selected route, while navigating the route, in response to changing or forecast conditions. The improved weather forecasting of the described technology permits more accurate estimation of travel delays due to weather. The disclosed technology can generate notifications based on real-time and forecast generated data including warnings regarding potential icing conditions, low visibility due to fog or snow squalls, snow accumulation on specific roads or in specific locations or areas. 6.10.1.1 Aviation

[00626] The disclosed technology can provide accumulated, real time, and forecast weather data that is useful for aviation customers including airports, pilots, and passenger and freight air carriers. The disclosed technology can estimate RVR data and other aviation-related information. Aviation customers can receive additional weather parameter information including historic, predicted, and real time precipitation types, rates, and accumulations. [00627] Aviation customers can configure the information distribution and alerting server (370) with alerts to generate warnings and notifications based on accumulated, real time, and predicted weather data including precipitation estimates. Notifications can warn of current or predicted icing conditions on a runway, which can be determined based on precipitation and temperature data. Notifications can include a report of current precipitation type and precipitation accumulation estimates, such as estimates of snow, rain, or hail accumulation on a runway, as well as a predicted time for surpassing a threshold accumulation amount and can include a warning when accumulation reaches a threshold amount. Alerts can include notifications to warn aviation customers of potentially damaging weather events such as hail or lightning based on forecast generated data. [00628] An exemplary use case of the technology described herein includes determining, using precipitation intensity and other precipitation data derived from one or more computationally complex and/or high collection rate data sources, and reporting, to a customer, current runway visual range (RVR) and forecasted RVR for various points in time in the future. Customers can include an airline carrier, airport, or service provider such as a shipping vendor. Customers can use RVR predictions, and corresponding predictions of runway availability and usage, for making routing and other business decisions. 6.11 Conclusion

[00629] It will also be recognized by those skilled in the art that, while the technology has been described above in terms of preferred embodiments, it is not limited thereto. Various features and aspects of the above described technology may be used individually or jointly. Further, although the technology has been described in the context of its implementation in a particular environment, and for particular applications, those skilled in the art will recognize that its usefulness is not limited thereto and that the present technology can be beneficially utilized in any number of environments and implementations where it is desirable to improve the accuracy and timeliness of precipitation forecasts. Accordingly, the claims set forth below should be construed in view of the full breadth and spirit of the technology as disclosed herein.