Weather Underground is where most personal weather station operators start publishing, and for a lot of them it is where they stop. It makes sense — the map is familiar, the app is popular, and the setup takes five minutes. But limiting yourself to a single network is like writing letters to one friend when you have a whole address book. Your station produces the same data whether one network consumes it or ten. The marginal cost of each additional destination is effectively zero, and the incremental value — scientific contribution, redundancy against platform changes, and exposure to different communities — is real.

I learned this lesson the hard way when Weather Underground changed ownership and rewrote their API terms in 2018. Stations that published exclusively to WU found themselves scrambling for alternatives overnight. Those of us who had been pushing to CWOP, PWSweather, and a personal website barely noticed the disruption. Diversification is not paranoia; it is good engineering.

This guide covers the networks beyond Weather Underground — APRS/CWOP, national and regional mesonets, citizen science projects, and the newer open-data platforms that are gaining traction. If you have not set up your first network yet, the sharing your data guide covers WUnderground, PWSweather, WeatherCloud, and CWOP from scratch. This article assumes at least one of those is running and builds outward from there.

Quick-Answer Summary

Network / Platform Type How You Contribute Why It Matters
CWOP / APRS-IS Scientific observation network APRS packets via station software Feeds NOAA MADIS; used by NWS forecasters
CoCoRaHS Citizen science — precipitation Daily manual rain gauge report Official NWS precipitation records
GLOBE Observer Citizen science — multi-variable App-based observations NASA-affiliated education and research
Windy.com Stations Public weather platform API push from station software Large audience, excellent visualisation
Ambient Weather Network Device ecosystem Native from Ambient hardware Community map, integration with Alexa/Google
Open-Meteo Open data API Varies by integration Free, open-source weather data access
National mesonets Regional observation networks Registration with network coordinator Hyperlocal forecasting, emergency management

APRS/CWOP: The Scientific Backbone

If you already publish to CWOP through the setup described in the sharing your data guide, you are part of the most scientifically impactful personal weather station network in existence. CWOP data enters NOAA's MADIS pipeline, where it is quality-controlled, cross-referenced against nearby stations, and made available to NWS forecasters and researchers.

The Ham Radio Heritage

CWOP is built on APRS — the Automatic Packet Reporting System developed by Bob Bruninga, WB4APR. Originally, weather data traveled over amateur radio VHF frequencies. Today, most personal weather stations submit data via the internet through APRS-IS (Internet Service), but the packet format retains its ham radio DNA: compact, structured, and unforgiving of format errors.

You do not need a ham radio licence to use CWOP (non-licensed operators get a CW/DW call sign), but understanding the APRS heritage helps explain why the format is the way it is. The METAR and CWOP basics guide dissects the packet structure byte by byte.

Maximising Your CWOP Impact

  • Submit every 10 minutes. More frequent is wasteful; less frequent creates gaps in the MADIS record.
  • Validate your position coordinates to arcminute accuracy. A wrong position means MADIS compares your data against stations in the wrong neighbourhood, leading to false quality flags.
  • Monitor your MADIS quality scores. MADIS publishes per-station quality reports. Check yours monthly. If your temperature or pressure consistently flags as an outlier, recalibrate or check sensor exposure.
  • Ensure station pressure, not sea-level pressure. MADIS applies its own elevation correction. Double-correcting produces systematically biased pressure data. The station data sanity checks guide covers how to verify which pressure value your software is reporting.

National Mesonets and Regional Networks

Beyond the global platforms, many countries and regions operate mesonets — dense observation networks designed for hyperlocal forecasting, agriculture, and emergency management.

What They Are

A mesonet is a network of weather stations — typically spaced 10–50 km apart — feeding data into a centralised system that produces gridded analyses, drought monitors, or severe-weather alerts. State-level mesonets in the US (Oklahoma Mesonet, New York Mesonet, Iowa Environmental Mesonet) set the standard. European equivalents include national meteorological services that accept volunteer stations (Météo-France's Infoclimat contributors, KNMI's voluntary observers in the Netherlands, the UK Met Office's WOW — Weather Observations Website).

How to Contribute

Each mesonet has its own registration process, data format requirements, and quality standards. Some accept automated uploads from personal station software; others require manual data entry. The common requirements are:

  • Siting standards. Mesonets care about sensor exposure — distance from buildings, surface type, instrument height. If your thermometer is mounted on a south-facing brick wall, it will not meet the criteria. The observation standards guide details WMO-recommended siting.
  • Calibration records. Some mesonets require recent calibration certificates for your sensors. Others accept self-calibrated stations with the understanding that the data will be flagged at a lower quality tier.
  • Regular reporting. A mesonet that cannot count on your data is worse off than one that never had it. Commit to a reporting schedule you can sustain — daily at minimum, hourly or sub-hourly if your automation supports it.

Finding Your Regional Network

The best starting points are your national meteorological service's volunteer observer programme and any university-run mesonet in your state or province. Agricultural extension services also maintain observation networks for irrigation and pest management.

Citizen Science Projects

CoCoRaHS — Community Collaborative Rain, Hail and Snow Network

CoCoRaHS is a volunteer precipitation observation network that operates across the US, Canada, the Bahamas, and the US Virgin Islands. Observers use a standardised rain gauge (the 4-inch CoCoRaHS gauge) and report daily precipitation totals through a web form or mobile app.

Why it matters: CoCoRaHS data is used directly by NWS forecasters for hydrological predictions, drought monitoring, and flood warnings. The data supplements radar estimates, which are notoriously unreliable for light precipitation and snowfall.

The catch: CoCoRaHS requires a manual daily reading at a consistent time (typically 7:00 AM local). This is not something you can automate with your station's tipping-bucket gauge — the CoCoRaHS programme specifically requires the standardised gauge and the human observation that accompanies it (hail reports, snow-water equivalents, observation notes). If you are willing to commit to the daily ritual, the contribution is meaningful.

GLOBE Observer

NASA's GLOBE Observer programme collects citizen science observations of clouds, land cover, mosquito habitats, and trees. The cloud observation component is relevant to station operators: photograph the sky at a scheduled time, classify the cloud types and coverage, and the data is matched against satellite passes for validation.

This is a lower-commitment contribution — observations are opportunistic rather than daily — and it complements your automated station data with the kind of qualitative sky assessment that no sensor can provide.

Emerging Open-Data Platforms

Windy.com Stations

Windy.com has built a station contribution programme that is worth your attention. The visualisation layer is stunning — animated wind, temperature, and pressure maps with your station data overlaid in real time. Registration involves claiming a station ID and configuring your software to push data to Windy's API.

WeeWX supports Windy via a community extension. CumulusMX has built-in support. GraphWeather can push to Windy through a custom HTTP upload target — configure the API endpoint and parameters in the export settings, following the same pattern described in the custom templates and plugin development guide.

Ambient Weather Network

If you run Ambient Weather hardware (WS-2902, WS-5000 series), your station publishes to the Ambient Weather Network by default. The data is visible on a community map and integrates with voice assistants (Alexa, Google Home) for spoken weather reports from your own station.

For non-Ambient hardware, the network is not directly accessible — it is a closed ecosystem tied to their hardware platform. However, Ambient Weather stations can simultaneously publish to WU, PWSweather, and other networks, so running Ambient hardware does not limit your options.

Open-Meteo Integration

Open-Meteo is a free, open-source weather API that aggregates data from multiple national weather services. While it primarily serves forecast data, there is a growing community interest in integrating personal weather station data. The contribution path is still maturing, but it represents the direction the open-data weather community is heading.

Netatmo Community

Netatmo's Weathermap aggregates data from their consumer weather stations into a publicly visible map. If you run Netatmo hardware, your data is already there. For operators with non-Netatmo stations, there is no contribution path — but the Netatmo map is useful for cross-referencing your readings against nearby Netatmo stations.

Publishing to Multiple Networks Simultaneously

The key insight: your station software is the hub, not any single network. Configure every network you want to contribute to, and the software handles parallel submissions from a single data stream.

Architecture

Station Sensors
      │
      ▼
Station Software (GraphWeather / WeeWX / CumulusMX)
      │
      ├─→ Weather Underground (HTTP)
      ├─→ PWSweather (HTTP)
      ├─→ WeatherCloud (HTTP)
      ├─→ CWOP / APRS-IS (APRS packet)
      ├─→ Windy.com (HTTP)
      ├─→ Your own website (FTP/SFTP)
      └─→ MQTT broker → Home Assistant

Each destination is independent. A failure on one does not affect the others. If WU's API is down, your CWOP submissions continue. If your FTP server is unreachable, your network uploads are unaffected.

For the FTP and MQTT branches, the FTP publishing guide and the MQTT integration guide cover setup details.

Bandwidth and Resource Impact

Publishing to seven destinations simultaneously sounds resource-intensive. It is not. Each HTTP submission is a few hundred bytes — smaller than a single tweet. APRS packets are under 100 bytes. At a 5-minute interval across seven networks, total upload bandwidth is under 2 MB per day. CPU impact is negligible. Even a Raspberry Pi handles this workload with resources to spare.

Data Format Translation

Each network has its own unit expectations and parameter naming conventions:

Parameter WU PWSweather WeatherCloud CWOP
Temperature Fahrenheit Fahrenheit Celsius × 10 Fahrenheit
Pressure inHg inHg hPa × 10 hPa × 10
Wind speed mph mph m/s × 10 mph
Rain inches inches mm × 10 hundredths of inch

Your station software handles all conversions. But if you are debugging a rejected upload, knowing the expected units is essential — a temperature of "22" submitted to WU means 22 °F (−5.5 °C), not 22 °C. This mismatch is a frequent source of flagged data, especially when configuring a network for the first time.

Common Mistakes

  1. Not validating data quality before contributing to CWOP. MADIS runs rigorous quality control. Bad data gets flagged, and persistently bad data gets your station excluded from the quality dataset. Run the checks in the station data sanity checks guide before enabling CWOP uploads.

  2. Duplicating station registrations. If you register twice on WU (perhaps after rebuilding your station PC), you end up with two station IDs for the same physical location. This confuses the map, splits your history, and can flag your data as suspicious. Use the existing station ID when reconfiguring.

  3. Submitting to CWOP more frequently than every 5 minutes. The APRS-IS network has finite capacity. Over-frequent submissions waste bandwidth, clutter the raw feed, and may trigger rate-limiting or banning.

  4. Forgetting to update coordinates after moving the station. Even a 10-metre repositioning matters for CWOP. If you relocated your station from one side of the garden to the other, update the position on every network.

  5. Assuming all networks want sea-level pressure. WU and PWSweather want station-level pressure and apply their own correction. Sending sea-level-corrected pressure results in over-corrected readings at the network level.

Related Reading

FAQ

If I already publish to CWOP, why should I also publish to Weather Underground? Different audiences. CWOP feeds the scientific community — NWS forecasters and researchers. WU serves the general public. Your neighbour checking the weather app on their phone sees WU data, not CWOP data. Both contributions matter; they serve different purposes.

Will publishing to many networks cause my station software to slow down? No. Network submissions are asynchronous HTTP requests or TCP packets. Each takes milliseconds to send. The station continues reading sensors and logging data while uploads happen in background threads. Even on low-powered hardware like a Raspberry Pi, there is no perceptible impact.

How do I know which networks are actually using my data? CWOP/MADIS provides quality reports that confirm your data is ingested. WU shows your station on their map with a "Last Updated" timestamp. PWSweather and WeatherCloud have similar station status pages. For Windy.com, your station appears as a pin on the Windy map.

What if a network shuts down or changes its API? This is exactly why you diversify. When a network changes terms or shuts down, you disable that upload target and continue publishing to the others. Your own website (via FTP/SFTP) is the one destination you fully control — the FTP publishing guide and the security guide cover that self-hosted path.

Can I publish historical data to CWOP retroactively? CWOP accepts real-time data only. Historical backfills are not supported via the APRS-IS gateway. If you missed a period of submissions (station offline, software misconfiguration), that gap remains in the MADIS record. This is another reason to monitor your upload health regularly.