The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/AI & Data/Data Science Tech Brief By HackerNoon
Data Science Tech Brief By HackerNoon artwork

How We Built a Per-Plant CO2 Dataset for 4,551 Power Stations Worldwide

Data Science Tech Brief By HackerNoon · 2026-06-25 · 5 min

0:00--:--

Key moments - from our scoring

Substance score

48 / 100

Five dimensions, 20 points each

Insight Density13 / 20
Originality12 / 20
Guest Caliber6 / 20
Specificity & Evidence15 / 20
Conversational Craft2 / 20

Building a comprehensive per-plant CO2 dataset requires reconciling fragmented emissions data across geography, ownership structures, and measurement methodologies. Ahiev's team constructed a single open dataset covering 4,551 power stations across the US, China, India, Japan, Australia, Saudi Arabia, Germany, Turkey, and dozens more countries by starting with the WRI Global Power Plant Database and Global Energy Monitor, then layering measured emissions from US EPA GHGRP (616 plants) and EU ETS (47 plants) alongside modeled estimates from Climate Trace (3,888 plants). The critical insight: only ~15% of power plant CO2 figures are independently measured; the rest rely on satellite data plus machine learning. Rather than obscure this distinction, they store a CO2_source field on every row, making provenance explicit. The Python ETL pipeline handles the messy 80% - matching plants across sources using geo-proximity and fuzzy name matching, normalizing diverse owner hierarchies, harmonizing units (MW, MWe, tons/year), and detecting double-counting where co-units are reported at both site and unit level. Each row includes location, fuel type, capacity, commissioning year, annual CO2 emissions, CO2 intensity (T/MWh), and Köppen climate zone, enabling analysis by environment as well as geography. The full dataset lives on Zenodo under CC-BY 4.0 with an interactive viewer at PowerAtlas; corrections and pull requests are actively welcomed.

Key takeaways

  • →Only 15% of power plant CO2 emissions in the dataset are directly measured (US EPA + EU ETS); the remaining 85% are modeled estimates from Climate Trace, and hiding this distinction is a liability.
  • →Geo-proximity with fuzzy name matching outperforms name-first matching for deduplicating plants across multiple data sources that use inconsistent naming conventions.
  • →Storing climate zone (Köppen classification) per plant enables analysis of how environment drives engineering outcomes like cooling penalties and atmospheric corrosivity without separate GIS work.
  • →Owner normalization (collapsing parent, subsidiary, and joint venture relationships) is essential for accurate portfolio-level emissions roll-ups.
  • →Unit harmonization and detection of double-counting (co-units reported at both site and unit level) are critical gotchas that silently poison intensity calculations.

Topics in this episode

EU ETSClimate TraceUS EPA GHGRPWRI Global Power Plant DatabaseGlobal Energy MonitorKöppen climate zonesPowerAtlasZenodoPython ETLFuzzy name matching

Questions this episode answers

What percentage of power plant CO2 emissions in the dataset are actually measured versus estimated?

Only approximately 15% are independently measured: 616 plants from US EPA GHGRP and 47 from EU ETS. The other 85% (3,888 plants) are modeled estimates from Climate Trace using satellite data and machine learning.

How does the dataset handle the fact that power plants don't share consistent IDs across different emissions data sources?

The team matches plants across sources using geo-proximity (distance-based lookup) as the primary key with fuzzy name matching as a tiebreaker, which outperforms name-first matching for handling variants like 'Saint-Agrieve' vs 'Saint-Agrieve-CCGT.'

Why is climate zone included in a power plant emissions dataset?

Environment directly drives real engineering outcomes - atmospheric corrosivity on outdoor equipment, cooling and efficiency penalties in hot zones, and heat loss behavior - so tagging Köppen climate zones lets users analyze fleet characteristics (e.g., coal plants in arid zones) without additional GIS work.

What are the most common data quality issues encountered when building a multi-source power plant dataset?

Name matching variants, owner normalization (parent vs. subsidiary), unit harmonization (MW vs. MWe vs. T/year), double-counting (units reported at both site and unit level), and coastal sites needing land-based fallbacks for climate zone lookup.

Where can the dataset be accessed and what license is it under?

The full dataset is published on Zenodo (DOI: 10.5281/zenodo.20723334) under CC-BY 4.0, with an interactive viewer at PowerAtlas (zonex.co.uk/poweratlas), and welcomes corrections and pull requests.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

13 / 20

For a 5-minute AI-narrated piece, the information density is high: the pipeline stages are enumerated with clear rationale, the gotchas (name matching, unit harmonization, double-counting, coastal fallback) are operationally specific and genuinely useful for anyone building similar data infrastructure. There is minimal padding.

Name matching. Saint-Agrieve, Saint-Agrieve-CCGT, Street. EGREVE, are the same plant in three sources. Geo-distance as the primary key with name as the tiebreaker beat name first matching every time.
Co units reported once at site level in one source and per unit in another

Originality

12 / 20

The provenance-per-row argument and the frank 15%-measured disclosure is a genuinely non-obvious and contrarian stance against industry norms of false precision; the climate-zone-per-plant angle as an engineering variable (corrosivity, cooling penalties) is a fresh framing not commonly seen in emissions data discussions.

any per plant CO2 product that hides that distinction isling false precision, so we store the source on every single row
Environment drives real engineering outcomes. Atmospheric corrosivity on outdoor equipment, cooling and efficiency penalties in hot zones.

Guest Caliber

6 / 20

There is no guest and no interview; this is an AI reading a written article by an author of unknown seniority. The author demonstrably built and published something real, which is practitioner credibility, but there is no way to assess scale, track record, or expertise beyond this single artifact.

By Dimitro Ahiev
The full dataset is on Zenodo with a doi

Specificity & Evidence

15 / 20

The piece is unusually specific: exact plant counts (4,551 total, 616 EPA, 47 EU ETS, 3,888 Climate Trace), named data sources (WRI Global Power Plant Database, Global Energy Monitor, Climate Trace, EPA GHGRP, EU ETS), a live DOI, and a concrete URL for the interactive view all constitute hard evidence rather than abstraction.

616 plants carry measured emissions from the US EPA GHGRP. 47 plants carry measured emissions from the EU ETS. 3888 plants carry modeled estimates from climate trace
https colon slash slash doi.org slash 10.5281 slash Zenodo.20723334

Conversational Craft

2 / 20

There is no conversation: this is an AI voice reading a written article verbatim, with no host, no guest, no questions, no follow-ups, and no opportunity for pushback or elaboration. The format structurally precludes any conversational craft.

Thank you for listening to this Hackernoon story, read by Artificial Intelligence.

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Most-used words

plant10measured9climate8slash8power5plants5emissions5dataset4data4plus4source4open4versus4match4name4stations3

Episode notes

This story was originally published on HackerNoon at: . An open dataset of 4,551 power stations: measured + modelled CO2, fuel, owner, capacity and climate zone. How we built it in Python, and the honest limits. Check more stories related to data-science at: . You can also check exclusive content about #data-engineering , #python , #global-energy-monitor , #greenhouse-gas-data , #carbon-accounting , #climate-analytics , #energy-infrastructure , #python-etl , and more. This story was written by: @dmytroah . Learn more about this writer by checking @dmytroah's about page, and for more stories, please visit hackernoon.com . The authors built and openly published a dataset covering 4,551 power stations worldwide, combining emissions, ownership, capacity, fuel type, and climate-zone data into a single schema. The project's central finding is that only about 15% of plant-level emissions data comes from direct measurements, while the remaining 85% relies on modelled estimates, making provenance and transparency critical for anyone working with emissions datasets.

Full transcript

5 min

Transcribed and scored by The B2B Podcast Index.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. How we built a per-plant CO2 dataset for 4,551 power stations worldwide. By Dimitro Ahiev. Most greenhouse gas data stops at the national or company level.

If you want to ask how much CO2 a specific power station emits, and what climate it sits in, for thousands of plants, in one consistent schema, you have to build it yourself. So we did, and published it openly with a doy. Here is the pipeline, the honest limitations, and the gotchas. The one number that reframes the whole thing.

Of 4,551 power stations, only approximately 15% have measured emissions, US EPA plus EUETS. The other 85% are modeled estimates, climate trace, any per plant CO2 product that hides that distinction isling false precision, so we store the source on every single row. What we built? A single open dataset of 4,551 power stations across the US, China, India, Japan, Australia, Saudi Arabia Germany Turkey and dozens more countries Each row carries location primary fuel capacity MW commissioning year operating status owner annual CO2 T per year the source of that CO2 figure CO2 intensity T per megawatt hour, and the plant's Copenhagen climate zone, so the data can be sliced by environment, not just geography.

The honest part. Measured versus estimated. Per plant CO2 is mostly not measured. In our dataset, 616 plants carry measured emissions from the US EPA GHGRP.

47 plants carry measured emissions from the EU ETS. 3888 plants carry modeled estimates from climate trace, satellite plus ML, so only approximately 15% is independently measured. Rather than hide it, we store a CO2 underscore source on every row, so any user can filter to measured only or treat estimates with caution. If you build emissions data and do not expose provenance per row, you are shipping a liability.

The pipeline. The build is a plain Python ETL, no orchestration framework 1 Backbone Start from an open plant inventory WRI global power plant database plus global energy monitor This gives the canonical list capacity fuel and geo 2 Join CO2 merge climate trace acid level emissions then overwrite with EPA GHGRP and EUETS where a measured match exists, measured always wins. 3. Match, the hard 80%.

Plants do not share IDs across sources, so we match on geo proximity plus fuzzy name. 4. Climate. Look up each plant's open zone from an offline 0.

5 degree grid by coordinate. 5. QA, de dupe, normalize owners, harmonize units, sanity check intensities. A simplified version of the match step.

Gotchas that cost us the most time. Name matching. Saint-Agrieve, Saint-Agrieve-CCGT, Street. EGREVE, are the same plant in three sources.

Geo-distance as the primary key with name as the tiebreaker beat name first matching every time. Owner normalization. Parent versus subsidiary versus joint venture. We collapsed to a canonical owner so portfolio roll-ups are honest.

Unit harmonization Mixed MW MW E and T per year versus not per year One silent unit bug poisons every intensity figure Double counting Co units reported once at site level in one source and per unit in another Coastal sites also need a nearest land fallback for the climate zone. Why climate per plant? Environment drives real engineering outcomes. Atmospheric corrosivity on outdoor equipment, cooling and efficiency penalties in hot zones.

Heat loss behavior. Tagging Coburn zones lets you ask what the coal fleet in arid zones looks like without a separate GIS step. Open data. Check it and find the gaps.

The full dataset is on Zenodo with a doi, https colon slash slash doi.org slash 10.5281 slash Zenodo.20723334 closing parenthesis under cc by 4.

0, and an interactive per plant view lives at PowerAtlas, https colon slash slash zonex.co.uk slash poweratlas slash closing parenthesis. It is a starting point, not gospel.

The estimated share is large and coverage is incomplete. Corrections and pull requests welcome, that is the point of publishing provenance per row. Thank you for listening to this Hackernoon story, read by Artificial Intelligence. Visit hackernoon.

com to read, write, learn and publish.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • Inside Southeast Europe's Power Markets with Dimitar Enchev of CWP GlobalThe Pexapark Podcast · on EU ETS82 / 100

More from Data Science Tech Brief By HackerNoon

All episodes →
  • Eliminating Data Latency with Event-Driven Pipelines at Enterprise Scale
  • Scaling Self-Service Analytics in Regulated Banking With Metadata-Driven Design
  • How to Rotate Proxies Without Breaking Login Sessions
  • I Built an Open-Source Firebase Analytics Alternative Because I Hit 1M Events/Day Once Too Many
  • Your Redshift Cluster Is Probably Idle 85% of the Time - And You're Paying for All of It
Explore the best B2B AI & Data podcasts →
All Data Science Tech Brief By HackerNoon episodes →