Postal Codes Dataset for Ethiopia, ET

246
Updated:
Files:1
Size:535 kB
Rows:11,114
Formats:csv
License:CC-BY-4.0

Postal Codes Dataset for Ethiopia, ET 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-et/
https://datahub.io/logistics/postal-codes-et/_r/-/.licensing-notes.md
https://datahub.io/logistics/postal-codes-et/_r/-/.migration-notes.md
https://datahub.io/logistics/postal-codes-et/_r/-/ATTRIBUTION.txt
https://datahub.io/logistics/postal-codes-et/_r/-/README.md
https://datahub.io/logistics/postal-codes-et/_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-et/_r/-/datapackage.yaml
README.md— documentation
https://datahub.io/logistics/postal-codes-et/_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-et

Download

Download CSV

About

Last updated
6 October 2026
Total rows
11,114
Format
CSV
File size
535 kB

About this dataset

Ethiopia (ET): 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 data.

  • Issue: pc-28e.8.8
  • Commit: see git log -- datasets/et/ (worktree commit, base c51b72a)
  • Parity verdict: unexplained (exit 1; the gate blocks on any row only on one side); accepted as upstream drift under the standing rule
  • Producer: custom, refresh disabled, postal_code_required: false

Sources

InputURLNotes
GeoNames gazetteer dumphttps://download.geonames.org/export/dump/ET.zipMember ET.txt. The main dump, not the postal export (export/zip/ET.zip is a 404)
GeoNames admin1 referencehttps://download.geonames.org/export/dump/admin1CodesASCII.txtRegion names for the ET.<code> keys (ASCII-name column, as the old builder read it)
  • Both are the URLs the old build_postal_codes_product.py docstring names for its local snapshots (sources/ET_dump.txt, sources/geonames_admin1CodesASCII.txt).
  • Neither URL is versioned: each always serves the current GeoNames build. The producer records bytes and sha256 in et.inputs.json.

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

Rows: 11,113 live and 11,114 fresh. 1 row only in live, 2 only in fresh, 0 changed cells (keyed on the new primary key). Ignoring CRLF→LF (live is CRLF), a line diff shows the same row order and only these three lines.

Cause: edits to the GeoNames dump after the live build (2026-09-04), i.e. upstream drift.

RowChangeCause
Jimma Rare (no admin1)coordinates 9.16667, 37.3333 → 9.17, 37.331geonameid 8643787 modified upstream 2026-09-21
Dedebit, Tigray (ET-TI)new row 14.06997, 37.76265new geonameid 13712885, modified 2026-09-25

Decisions

DecisionByBasis
Accept the 3 drift rowsStanding rule (upstream drift traced to source)Both geonameids carry modification dates after the 2026-09-04 build
Accept CRLF→LFStanding ruleFormat-only
primaryKey: [place_name, latitude, longitude]AgentThe old builder checked (place_name, admin_name1, latitude, longitude); admin_name1 is empty on unresolved rows, and the produced CSV is unique on the shorter key, so the producer checks that one instead (stricter)
latitude/longitude → number; accuracy stays stringAgent, per the P6 type ruleaccuracy is empty on every row (the gazetteer dump has no accuracy value), so it is not numeric. Its description now says it is always empty
postal_code_required: falseAgentEthiopia has no postal code system; build.py would otherwise reject the empty column
Removed the place count from the descriptor description and READMEStanding doc ruleRegion counts kept

Transforms carried over

From build_postal_codes_product.py (2026-09-04):

  • Feature class P only.
  • admin1 name crosswalk to display name + ISO 3166-2:ET (12 coded regions); Central Ethiopia and South Ethiopia (2023 reform) keep their name with admin_code1 empty.
  • Unresolved admin1 codes (00/blank) ship with empty admin_name1/admin_code1.
  • All other non-coordinate columns empty; coordinates verbatim.
  • Sort by (admin_code1, place_name), stable on dump order.
  • Old asserts are now ProducerErrors: country is ET, every ET region in the reference table is in the crosswalk, every ISO region has places, no literal "nan", PK unique. The >= 9000 places floor was dropped (no hardcoded counts).

Not ported

  • The old builder's own datapackage.json/README/ATTRIBUTION/zip output (build.py's job; free datasets get no zip).
  • publish_r2.py (deleted).

Open questions

  • None needing the user beyond the standing-rule drift above. .licensing-notes.md still holds dated historical counts; left alone for the pc-hfz sweep.