[HughRunyan]

Output

SWEET can work out a place's population by year once, and grow a city's waste along that stored series later:

• city_params.city_population_trajectory(iso3, population_year, population, historic, future, city_points=None) returns a city's population in people for every model year (1970–2050), and what its shape comes from:

  • "UN city rates": a UN-listed city (300,000+ people, plausible rates) compounds its own two rates either side of its population year;
  • "country curve": any other city follows its country's WPP2024 population, year by year.

  This is the choice _city_growth already makes, so nothing it returns is new.

• city_params.country_population_trajectory(iso3) returns a country's WPP population in people. For the 12 places WPP has no series for (ALA, ATA, ATF, BVT, CCK, CXR, HMD, IOT, NFK, PCN, SGS, UMI), it returns the fallback rates a Custom Location there grows by ("country fallback rates"). Those places have no population to give it, so that trajectory is 1.0 in 2022. Kosovo has a WPP series (XKX).

• City.load_csv_new(..., population_series=) grows a city along a stored trajectory instead of the one _city_growth would pick now. The two growth rates it reports are unchanged.

• city_points ({year: people}, the UN's own points for one city) is where full UN city trajectories come in later. It grows at a constant rate between neighbouring points. Nothing passes it yet.

• dst_baseline_blank's fallback constants become module constants (FALLBACK_GROWTH_RATE_*, CUSTOM_LOCATION_POPULATION_YEAR). The values are the same.

Why

WasteMAP's cities stage and its API each re-ran _city_growth, so a SWEET pin change could make the city DST grow a city differently from the build behind it (#71 / WasteMAP #839 did). WasteMAP now stores each build's trajectories and hands them back through population_series. The WasteMAP PR that uses this follows once this is released.

Numbers

• No number moves in SWEET: nothing calls the new argument by default.
• A stored trajectory handed back grows a city as SWEET would have, to within ~1e-15 relative, not to the bit. SWEET's growth factor is series[year] / series[population year]. With the series in people, about 8% of city-years have no stored float that divides back to exactly the old factor (checked over WasteMAP's 0626 table, ±5 ULP). Storing growth factors would be exact; WasteMAP stores people by decision.

Acceptance criteria

• A big city's trajectory is population × rate^(year − population year) on each side; any other city's is population × P_country(year) / P_country(population year).
• load_csv_new grows a city along the series it is handed: a flat series stops its growth, and the stored series matches SWEET's own to 1e-14.
• Every country SWEET knows has a trajectory; a Custom Location in a country without WPP grows exactly along the fallback trajectory.
• Changelog updated.

Definition of Done

Acceptance criteria met · tests pass (pytest -m "not integration": 568 passed) · changelog updated · reviewed & merged · then a release (sweet/2026.10.4) for WasteMAP to pin.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Rounding exported populations changes SJM’s growth ratios instead of preserving the existing country curve.

1 open issue

• Rounding alters SJM growth curve and exported trajectory · New

What changed in this PR

Adds reusable population trajectories so WasteMAP can store growth curves and pass them back to SWEET.

Changes:

• Adds city and country trajectory helpers.
• Lets load_csv_new use a stored population series while preserving reported growth rates.
• Shares fallback constants and adds regression tests and release notes.

File	Description
tests/​test_population_trajectory.py	Tests trajectory generation and stored-series growth.
SWEET_python/​city_params.py	Adds trajectory APIs, stored-series input, and shared constants.
changelog/​2026-10.md	Documents trajectory storage and reuse.

_{Review effort: Balanced}