Field note · October 12, 2024

Reading pm10 before trusting it in city-air-quality

5,480 rows, 861 distinct values, and the one fact about pm10 that changes how you query it.

1 min read ·Data quality ·quality practice

Profiling pm10 on city-air-quality before anyone builds anything on top of it.

5,480 rows, 85 nulls (1.6%), 861 distinct values. PM10, µg/m³.

The five-number version: min 1.50, p10 10.50, median 29.50, p90 60.16, max 268.90. The mean is 33.09.

The p10 to p90 band — 10.50 to 60.16 — is where ordinary rows live, and it is the pair worth quoting when somebody asks what to expect. Min and max describe the two strangest rows in the table and nothing else; they are useful for spotting impossible values and misleading for everything else.

85 rows have no value at all here, which is 1.6% of the table. That is enough to move an aggregate and small enough that nobody notices it doing so — every average above is computed over 5,395 rows, not 5,480, and the two denominators produce different answers.

sql
select
  count(*)               as rows,
  count(pm10)            as present,
  count(*) - count(pm10) as nulls,
  count(distinct pm10)   as distinct_values
from city_air_quality;

Nothing dramatic: the mean and median are within 12.2% of each other, so an average is a fair summary. That is worth confirming rather than assuming — it is not true of most money columns.

Where this matters: a symmetric column is one you can average, threshold and chart without hedging, which makes it unusually cheap to work with. Knowing which of your columns are like this and which are not is most of knowing when to be careful.

The grain is one row per city per day, which is the context every one of those numbers depends on. None of them survive a change of grain, which is why "profile the column" and "profile the table" are the same job. Full schema, and the CSV, on the dataset page.