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 →

Download · CSV · 593 kB Explore with AI Report an Issue

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-rw/

├ .licensing-notes.md

https://datahub.io/logistics/postal-codes-rw/_r/-/.licensing-notes.md

├ .migration-notes.md

https://datahub.io/logistics/postal-codes-rw/_r/-/.migration-notes.md

├ ATTRIBUTION.txt

https://datahub.io/logistics/postal-codes-rw/_r/-/ATTRIBUTION.txt

├ README.md

https://datahub.io/logistics/postal-codes-rw/_r/-/README.md

└ datapackage.yaml

https://datahub.io/logistics/postal-codes-rw/_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-rw/_r/-/datapackage.yaml

README.md— documentation

https://datahub.io/logistics/postal-codes-rw/_r/-/README.md

Typical Usage

1. Fetch datapackage.yaml to inspect schema and resources
2. Download data resources listed in datapackage.yaml
3. Read README.md for full context

Data Files

Explore with AI

postal-codes-rw

Field	Type	Description	Title
country_code	string	ISO 3166-1 alpha-2 -- always RW	Country Code
postal_code	string	Always empty -- Rwanda has no operational postal code system. Not a data gap; see ATTRIBUTION.txt.	Postal Code
place_name	string	Locality/place name (GeoNames populated place)	Place Name
admin_name1	string	Province / City of Kigali -- all 5 covered; blank where GeoNames assigns a place to no province	Administrative Name 1
admin_code1	string	ISO 3166-2:RW code	Administrative Code 1
admin_name2	string	Not populated in this release	Administrative Name 2
admin_code2	string	Not populated	Administrative Code 2
admin_name3	string	Not populated	Administrative Name 3
admin_code3	string	Not populated	Administrative Code 3
latitude	number	GeoNames latitude (WGS84)	Latitude
longitude	number	GeoNames longitude (WGS84)	Longitude
accuracy	string	Not populated -- the GeoNames gazetteer dump carries no accuracy field	Accuracy
alternative_city_name	string	Not populated in this release	Alternative City Name

Download

Download CSV

About

Last updated: 6 October 2026
Total rows: 10,260
Format: CSV
File size: 593 kB
Sources: GeoNames main gazetteer dump -- Rwanda (RW); GeoNames admin1 codes table
License: Creative Commons Attribution 4.0 International

About this dataset

Rwanda (RW): 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.18
Commit: see git log -- datasets/rw/ (P6 rw 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

Input	URL	Notes
GeoNames gazetteer dump	https://download.geonames.org/export/dump/RW.zip	`RW.txt`, filtered to feature class `P`. The old builder read a local `sources/RW.txt` snapshot of this file
GeoNames admin1 table	https://download.geonames.org/export/dump/admin1CodesASCII.txt	Used to check GeoNames' province labels against the crosswalk. The old builder read a local `sources/geonames_admin1CodesASCII.txt` snapshot and joined on its names

Both URLs are stable, unversioned GeoNames URLs. The fetch date and sha256 are recorded in rw.inputs.json; --no-fetch reuses the cache.
Rwanda has no postal-code system and GeoNames has no postal export for RW (export/zip/RW.zip is a 404), so postal_code is empty on every row. pipeline.postal_code_required: false tells build.py this is intended.

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

Rows: 10,260 live and 10,260 fresh, none only on one side, 0 changed cells, no cell classes, 0 duplicate keys. Once CRLF is normalised to LF the fresh rw.csv is byte-identical to the live CSV, including row order. Live sha256 469f0f07…, fresh 2bd9f7db… (the only difference is line endings).

No discrepancies to explain. The GeoNames dump at migration time still has 10,260 populated places, 1 of them with a blank admin1 (Rutagara), as on 2026-09-17.

Decisions

Decision	By	Basis
Accept the CRLF→LF difference	Standing rule (P5 sign-off: row_order/CRLF-only pre-approved)	Equal rows, 0 changed cells
Drop the exact asserts (at least 9,000 places, exactly 1 unresolved row, exactly 5 buckets)	P6 brief	Replaced by structural checks: the 5 GeoNames buckets match the crosswalk, all 5 provinces present, primary key unique
Join on the GeoNames bucket code (RW.11–RW.15) and check each bucket's label, instead of joining on the label	Agent: port choice (same as bj)	Same output; a renamed or added bucket still stops the build, as the old unmapped-name assert did
A blank or reserved `00` admin1 ships blank; any other admin1 code not in the crosswalk stops the build	Agent: port choice	The old builder blanked unknown codes silently (only its exact unresolved-count assert caught them); blanking a real new province would hide a crosswalk gap
`latitude`/`longitude` typed `number`; `accuracy` stays `string`	Agent, per the brief	`accuracy` is empty on every row (the gazetteer dump has no accuracy field), so it isn't numeric data and doesn't get the GeoNames accuracy description
`primaryKey: [place_name, latitude, longitude]`	Agent, from the produced CSV	Unique in the produced CSV. The old builder's key was (place_name, admin_name1, latitude, longitude), also unique, but admin_name1 is blank on the unassigned row; the shorter key is stricter and matches bj. (place_name, admin_code1) is not unique
`pipeline.postal_code_required: false`	Agent, per the brief	postal_code is empty on every row
Add `admin1CodesASCII.txt` to the descriptor `sources`	Agent	It is a fetched input
Field descriptions taken from the old builder's datapackage.json (minus counts)	Agent	The P3 generic descriptions said "Postal code for the location", which is wrong for rw
Count dropped from the descriptor `description` ("10,260 localities")	P6 brief	Counts rule; the province count is kept
README.md rewritten	Orchestrator instruction (stale-README rule)	It was the generic "We don't have postal code data for Rwanda yet … No data is currently available" stub, contradicting the published locality directory. Rewritten from the old builder's README text, without counts, file/field tables or the `licence_status` line, keeping the CC BY 4.0 source line. README text confirmed by the user (2026-10-05)

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 → ISO 3166-2:RW via the crosswalk (Kigali→City of Kigali RW-01, Eastern RW-02, Northern RW-03, Western RW-04, Southern RW-05). GeoNames' numbering is not in ISO order; the crosswalk is explicit per bucket.
Blank admin1 → blank admin_name1/admin_code1.
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

Resolved (user, 2026-10-05): rewritten README.md confirmed.
.licensing-notes.md still carries dated counts and describes the pre-2026-09-17 empty placeholder; left for pc-hfz. There is no committed ATTRIBUTION.txt for rw (the README and field description point to one; the old builder wrote it into the zip only). Left for pc-hfz.