Units and unit conversions in emission factors

Every factor is emissions per one unit, and that unit is its denominator. The data stores each factor per one canonical unit (unit_code), converting the publisher's unit only when the conversion is exact. When a conversion would need a density, a heating value or any other assumption, it is not made.

The unit on a factor#

unit_code is the unit the value is per. unit_family is its dimension, and it is the filter you tick to see only mass factors, or only spend factors. You can compare or swap two factors only when their unit_code is the same. For a gas volume that is necessary but not sufficient, which is the one exception on this page: see gas volumes and metering conditions.

The unit families#

A family appears in the filter when factor search holds factors in it, so the list is read off the data rather than fixed. What one unit of each family is:

A family holds its qualified codes as well as its plain one: kwh_hhv is energy, kg_n is mass, m2_floor is area. area_time is the family whose only code is a qualified one, since a land-occupation factor needs both an area and a duration from you. So the family tells you the dimension and nothing more, and two factors in one family are still only interchangeable when the code matches. Every code, plain and qualified, is listed in the code lists, and units.xlsx holds the same list with the publisher labels each code was read from.

Filter factor search with unit or unit_family, for example energy factors.

The five transport bases#

Five families price a movement, and nothing crosses between them: a filter on one returns nothing from another, and no conversion links them.

• distance, km: per kilometre travelled, as the publisher published it. Among the libraries quoted on this site, DESNZ, ADEME and miterd file here, mostly car, motorcycle and road-freight rows, which are one vehicle's kilometre even though the label never says so. A few bus and rail rows sit here too, and for those only the publisher's own document says whose kilometre it is.
• vehicle_distance, vehicle_km: per kilometre of one vehicle, whatever it carries. A factor lands here by how the publisher wrote the unit, not by what it counts: EPA's kg / vehicle-mile does, folded onto the kilometre by 0.621371 (1 mile = 1.609344 km), and DESNZ's plain km for the same kind of car does not.
• passenger, p.km: one passenger moved one kilometre. One person on a 300 km flight is 300 p.km.
• freight, t.km: one tonne moved one kilometre. A 20-tonne load over 300 km is 6,000 t.km.
• freight_container, teu.km: one twenty-foot-equivalent container moved one kilometre. It is deliberately not folded into t.km, because converting a container-kilometre into a tonne-kilometre needs the payload in that container, which is per-lane data and not a constant anyone can publish.

The last three count something the first two do not: a passenger, a tonne, a container, each of which needs an occupancy or a load before it can answer a per-vehicle question. km and vehicle_km differ in a weaker way. They are one quantity under two labels, kept apart so that a factor a publisher priced per vehicle can never silently answer a query that asked for a plain distance. So if your quantity is vehicle-kilometres, query both: most of the car and road-freight factors you want carry plain km. If it is passenger-kilometres or tonne-kilometres, neither kilometre family answers it, and a per-vehicle number applied to a per-passenger quantity is wrong by the occupancy.

The conversions that are made#

A conversion is made when it is a fixed ratio between two units of the same dimension. The value is scaled once, at import, and the publisher's original label and the multiplier are kept with the value.

One gigajoule is 277.78 kWh, which is why a factor per GJ is multiplied by 0.0036 to give a factor per kWh.

The conversions that are refused#

Some units look alike but are not the same quantity. The data keeps them apart, because a wrong conversion corrupts a total silently, while a missing one is visible and can be fixed.

• Volume to mass, or volume to energy. A litre of fuel becomes kilograms only through a density, and kilowatt-hours only through a heating value. Both vary by fuel and by publisher. DESNZ butane therefore stays as four separate factors.
• Gross and net heating value. A fuel's energy counted on the gross (higher) heating value is larger than on the net (lower) value, by up to about 11 % depending on the fuel. The same fuel therefore gives a smaller factor per gross kWh. Gross-basis factors carry kwh_hhv, never kwh.
• Mass of a nutrient versus mass of product. kg_n is a kilogram of nitrogen, not a kilogram of fertiliser. Treating it as plain kg is off by the nitrogen content. The same holds for kg_p2o5, kg_k2o and kg_active_substance.
• Currencies. A spend factor stays in the currency the publisher used. Converting it to another currency is a step you take, with an exchange rate for the right year.
• One gas metering condition to another. A cubic metre of gas converts to litres by the exact 1,000 ratio, but how much gas that volume holds depends on temperature and pressure, and nothing in the data restates one publisher's conditions in another's. See gas volumes below.
• Lookalike units. A unit with no fixed ratio to a canonical one keeps its own code, or is not imported. It is never filed under the nearest plain unit.

Worked example: butane in DESNZ#

DESNZ publishes UK butane combustion per four different units. The data keeps all four:

If your fuel bill is in litres, use the litre factor. If it is in kWh, check whether your invoice states gross or net heating value: the two kWh factors differ by 8 %. See the litre factor page.

Note. Qualified codes such as kwh_hhv, kg_n or m2_floor exist so that they never match a plain unit by accident. If your quantity is in plain kWh or kg, a qualified factor is not a match.

Gas volumes and metering conditions#

Gas is the one designed exception to that note. A cubic metre of gas is a cubic metre, so it folds onto litres by the same exact ratio as any other volume: a gas factor's unit_code is the plain l and its unit_family is volume, with no qualifier to warn you. What the ratio cannot carry is how much gas the volume holds, which depends on the temperature and pressure it was metered at. A normal cubic metre (0 C) holds about 5.5 % more gas than a standard cubic metre (15 C), which is the ratio of the two absolute temperatures (288.15 / 273.15) rather than anything measured in factor search, so two gas factors that are both per litre can differ by that much before anything else about them differs at all.

Publishers spell the difference in their own units, and not always at all. Whether a condition is stated at all is read from the spelling itself: Nm3, Nm³ and ADEME's m3 (n) are a normal cubic metre, 0 C. There is no code for a single standard cubic metre: the one standard-metre spelling that is recognised, 103 stdm3, is a thousand of them, so it folds onto the litre a thousand times smaller than an m3 does. scf is a standard cubic foot, 28.316846592 litres exactly, and it is stored with its conditions unstated, because the spelling does not say which standard. A bare m3, "cubic metres", or "normal m3" written out in prose says nothing to the importer and is stored as saying nothing; where a source states its conditions somewhere other than the unit cell, the importer for that source attaches them.

The conditions are kept on the factor rather than in the unit code. emission_factor.reference_basis holds a gas_volume descriptor with the publisher's temperature_c and pressure_kpa, or the literal unstated where the publisher named none. A missing condition is never filled in with a guess: US federal reporting rules alone allow more than one temperature for a standard cubic foot, so any assumed value would be a claim the source never made.

Four gas volume spellings from three libraries, and what each one stores:

Watch out. None of that reaches you on a served row. These factors are basis_kind = 'canonical', because the litre really is a litre and the conversion really was exact, so they carry no qualified code and no context-dependent flag. reference_basis is not a column of factors_flat, the API does not return it, factor search does not show it, and the publisher's own spelling (unit_raw) is not served either. A SQL reader joins open_ef.emission_factor on factor_id to read it, the same join how factors are cleaned uses for basis_kind.

Three rules follow, and they are the whole of what the data promises here:

• Compare or swap two gas volume factors only when their stored conditions match. Same unit_code is not enough for a gas.
• Read unstated as unknown, not as your own meter's basis. Most gas rows in the libraries quoted on this site are unstated, and the honest reading of that is that the publisher's document is the place to look.
• Bridging a gas volume to energy or to mass is the volume-to-energy refusal above, with an extra turn: the calorific value belongs to that publisher's gas at that publisher's conditions, and there is no site-wide constant standing in for it.

Related#

• units.xlsx: every unit code, its family, its basis and the publisher labels behind it
• Glossary: unit basis
• Calculate emissions for a quantity
• How factors are cleaned
• Spend-based vs activity-based factors