Philippines (PH) build pipeline
Single-source GeoNames PH rebuild — matches docs/PRICING_TIERS.md's own description
of PH as Tier B, "single-source normalisation of the GeoNames PH export… No second
source is consolidated onto it." (Do not confuse this with the FedEx-schema PHL build in
~/Desktop/Research/fedex-agents-prototype/countries/PHL/, which consolidates GeoNames
- PSGC admin + PSA district membership for a different product with a different pricing model — see CLAUDE.md "Two Output Formats" there.)
Fixed 2026-08-19: this pipeline used to be circular. build_base.py's SOURCE used
to point at sources/ph_r2_snapshot_2026-08-18.csv — a snapshot of data already live in
R2. It only cleaned known serialization bugs (literal "nan" strings, "4.0"-style
accuracy floats, an inconsistent NCR region code, redundant alternative_city_name
values); if R2 ever lost that data, this script reproduced nothing, because its own
input already depended on the thing it was supposed to independently regenerate.
fetch_source.py is new — it downloads GeoNames PH directly
(https://download.geonames.org/export/zip/PH.zip, CC BY 4.0, refreshed daily) and
writes sources/ph_geonames_live.csv. build_base.py's SOURCE now points there
instead. enrich_admin.py and the sources/psgc_*.json files look like leftovers from
an older, more ambitious approach that current build_base.py doesn't actually use —
flagging as unclear/possibly dead rather than assuming they're load-bearing; don't
delete without checking first.
Known, deliberate gap: alternative_city_name is emitted empty for every row. It
would come from GeoNames' separate alternate-names gazetteer dump, which isn't fetched
or joined here — out of scope for this fix, documented rather than faked.
Run order
python3 fetch_source.py # NEW — downloads GeoNames PH.zip fresh
python3 build_base.py # SOURCE repointed to fetch_source.py's output
python3 integrity_checker.py
python3 package.py
python3 publish_r2.py # dry run by default; --apply to publish
Sources
- GeoNames
PHpostal export — CC BY 4.0, refreshed daily
Verification (2026-08-19)
Fresh fetch returned exactly 2,317 rows (matches both live R2 and build_base.py's
own hard-coded row-count expectation). Cross-checked every row against live R2:
all 2,317 postal codes present in both, zero missing/extra. 403 rows show a
place_name text difference from the 2026-08-18 snapshot — sampled 5/5, all the same
pattern (GeoNames has appended historical-name parentheticals to some Ilocos Norte
municipalities since, e.g. "Banna" -> "Banna (formerly Espiritu)"). Same postal code,
same core name, same admin hierarchy on every one — upstream content drift, not a
pipeline defect.