Postal Codes Dataset for Uganda, UG

416
Updated:
Files:1
Size:626 kB
Rows:11,455
Formats:csv
License:CC-BY-4.0

Postal Codes Dataset for Uganda, UG including name of the city, town, or place, various administrative divisions and alternative city names.

Part of a Data Solution

  • Postal Codes Solution

    Every worldwide postal-code dataset in one bundle — the ultimate global reference for precise postal codes.

    Explore →

API Access

Access dataset files directly from scripts, code, or AI agents.

Browse dataset files
Dataset Files

Each file has a stable URL (r-link) that you can use directly in scripts, apps, or AI agents. These URLs are permanent and safe to hardcode.

/logistics/postal-codes-ug/
https://datahub.io/logistics/postal-codes-ug/_r/-/.licensing-notes.md
https://datahub.io/logistics/postal-codes-ug/_r/-/.migration-notes.md
https://datahub.io/logistics/postal-codes-ug/_r/-/README.md
https://datahub.io/logistics/postal-codes-ug/_r/-/datapackage.yaml
Key Files

Start with these files — they give you everything you need to understand and access the dataset.

datapackage.yaml— metadata & schema
https://datahub.io/logistics/postal-codes-ug/_r/-/datapackage.yaml
README.md— documentation
https://datahub.io/logistics/postal-codes-ug/_r/-/README.md
Typical Usage
  1. 1. Fetch datapackage.yaml to inspect schema and resources
  2. 2. Download data resources listed in datapackage.yaml
  3. 3. Read README.md for full context

Data Files

Explore with AI

postal-codes-ug

Download

Download CSV

About

Last updated
6 October 2026
Total rows
11,455
Format
CSV
File size
626 kB

About this dataset

Uganda (UG): migration notes

Internal record of the P6 migration from the old scripts to the producer: the discrepancies found, their causes, and who decided what. This is a dated record, so the numbers are as of the migration and not kept current. It is not shipped in the zip.

  • Issue: pc-28e.8.24
  • Commit: see git log -- datasets/ug/ (P6 ug commit on feat/single-source-of-truth, base e797eb1)
  • Parity verdict: format-only (gate: pass, exit 0); CRLF→LF only
  • Producer: custom, refresh disabled

Sources

InputURLNotes
GeoNames gazetteer dumphttps://download.geonames.org/export/dump/UG.zipUG.txt, filtered to feature class P. The old builder read a local sources/UG_dump.txt snapshot of this file
  • Stable, unversioned GeoNames URL. The fetch date and sha256 are recorded in ug.inputs.json; --no-fetch reuses the cache.
  • Uganda has no bulk-fetchable postal-code system and GeoNames has no postal export for UG (export/zip/UG.zip is a 404), so postal_code is empty on every row. pipeline.postal_code_required: false tells build.py this is intended.
  • The old builder used no admin1 table: its region names are a fixed table in the script, kept as-is in the producer.

Parity against the live public CSV (2026-10-05)

Rows: 11,455 live and 11,455 fresh, none only on one side, 0 changed cells, no cell classes. Once CRLF is normalised to LF the fresh ug.csv is byte-identical to the live CSV, including row order. Live sha256 aa7147c8…, fresh bf9a613d… (the only difference is line endings).

No discrepancies to explain. The dump at migration time has 2 populated places on the reserved admin1 code 00 (Kabende, Kagera), shipped with blank region as before; no populated place has a blank admin1 cell.

Decisions

DecisionByBasis
Accept the CRLF→LF differenceStanding rule (P5 sign-off: row_order/CRLF-only pre-approved)Equal rows, 0 changed cells
Drop the minimum-count assert (>= 9,000 places)P6 briefReplaced by structural checks: all 4 regions present, primary key unique, only known admin1 codes
A blank admin1 cell is treated like 00 (blank region)Agent: port choiceThe old builder's assert would have refused it; same handling as bj. Does not occur in the current dump
latitude/longitude typed number; accuracy stays stringAgent, per the briefaccuracy is empty on every row (the gazetteer dump has no accuracy field), so it gets no GeoNames accuracy description
primaryKey: [place_name, admin_name1, latitude, longitude]Agent, from the produced CSVUnique in the produced CSV; it is the old builder's own PK. (place_name, latitude, longitude) is also unique today, but the old key was kept
pipeline.postal_code_required: falseAgent, per the briefpostal_code is empty on every row
Field descriptions taken from the old builder's datapackage.json (minus counts)AgentThe P3 generic descriptions said "Postal code for the location", which is wrong for ug. The "134 district codes" count was dropped from the admin_name2 description
README: "11,455 places" → "populated places"P6 brief (count rule)Otherwise unchanged; it was not a stale stub and had no licence_status line

Transforms carried over

From build_postal_codes_product.py:

  • Feature class P only; place_name is the dump's name column; latitude/longitude copied verbatim.
  • admin_code1 = UG- + GeoNames admin1 code (C/E/N/W, identical to ISO 3166-2:UG); admin_name1 from the fixed region table.
  • Reserved admin1 00 → blank admin_name1/admin_code1; any other unknown code stops the build.
  • postal_code, accuracy, alternative_city_name and admin tiers 2–3 empty.
  • Sorted by (admin_code1, place_name), ties in dump order.
  • Not ported: the old builder's own datapackage.json, README, ATTRIBUTION and zip writing (build.py / committed docs handle those) and publish_r2.py.

Open questions

  • None needing the user. .licensing-notes.md still carries dated counts and an outdated "0-row placeholder" description; left for pc-hfz.