Part of a Data Solution
- Explore →
Postal Codes Solution
Every worldwide postal-code dataset in one bundle — the ultimate global reference for precise postal codes.
Premium
You're viewing a free sample
Get the complete dataset — all rows and files — delivered instantly after checkout, with lifetime access to the latest version.
- Secure checkout via Stripe
- Instant download after payment
- Lifetime access to the latest version
- Creative Commons Attribution 4.0 International license
API Access
Access dataset files directly from scripts, code, or AI agents.
Browse dataset files
API Access
Access dataset files directly from scripts, code, or AI agents.
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.
Start with these files — they give you everything you need to understand and access the dataset.
- 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
postal-codes-bd-sample
| Field | Type | Description | Constraints | Title |
|---|---|---|---|---|
| country_code | string | ISO 3166-1 alpha-2 -- always BD | Country Code | |
| postal_code | string | Bangladeshi postal code (4 digits) | { "pattern": "^\\d{4}$" } | Postal Code |
| place_name | string | Locality/place name | Place Name | |
| admin_name1 | string | Division -- 8/8 covered, including Mymensingh Division (corrected from GeoNames' stale 'Dhaka Division' label on the 77 rows GeoNames' own internal coding already separates, see ATTRIBUTION.txt) | Administrative Name 1 | |
| admin_code1 | string | ISO 3166-2:BD code | Administrative Code 1 | |
| admin_name2 | string | District -- 64 distinct, 100% populated | Administrative Name 2 | |
| admin_code2 | string | GeoNames' own internal district code (not an independently verified official code) | Administrative Code 2 | |
| admin_name3 | string | Thana/Upazila -- 483 distinct, 100% populated | Administrative Name 3 | |
| admin_code3 | string | Not populated -- no code accompanies this tier in the source | Administrative Code 3 | |
| latitude | number | GeoNames-estimated latitude (WGS84) | Latitude | |
| longitude | number | GeoNames-estimated longitude (WGS84) | Longitude | |
| accuracy | string | GeoNames accuracy code | Accuracy | |
| alternative_city_name | string | Not populated in this release | Alternative City Name |
Download
Download sample CSVAbout
- Last updated
- 11 October 2026
- Total rows
- 100
- Format
- CSV
- File size
- 8.54 kB
About this dataset
Bangladesh (BD): migration notes
Internal record of the P5 migration from the old script to the producer: the discrepancies found, their causes, and who decided what. This is a dated record (2026-10-11), so the numbers are as of the migration and not kept current. It is not shipped in the zip.
- Issue: datopian/postal-codes#41 (no builder scripts in the repo)
- Commits: the recovered builder, then the producer (this branch)
- Parity verdict:
format-only(gate: pass) - Producer:
custom, refresh disabled
Recovered builder
build_postal_codes_product.py (dated 2026-08-31) was found uncommitted in the working copy, together with its raw input BD.txt. It is committed unchanged in the commit before this one, then removed by the producer commit.
Re-run on 2026-10-11 against its saved inputs it reproduces the live bd.csv byte for byte (sha256 9b453d826c…). The producer was then checked the same way: its transform() on those saved inputs gives the live data, differing only in line endings.
Sources
| Input | URL | Notes |
|---|---|---|
| GeoNames postal export | https://download.geonames.org/export/zip/BD.zip | CC BY 4.0. The only source |
Parity against the live zip (2026-10-11)
Rows: 1,349 live and 1,349 fresh, none only on one side, 0 changed cells. The only difference is CRLF → LF.
GeoNames' file hasn't changed for Bangladesh since the live build, so there is no upstream drift to explain.
Decisions
| Decision | By | Basis |
|---|---|---|
| Port the recovered builder faithfully; no new source or logic | User, 2026-10-11 | The 2026-10-03 rule ("no producer from scratch when no builder exists") doesn't apply: the builder was found, and re-running it reproduces the live CSV byte for byte |
| LF line endings (the old script wrote CRLF) | Standing rule (user, 2026-10-02) | format-only verdicts pass; every shared producer writes LF |
| Drop the hardcoded row-count assert | P5 rule | Structural checks (columns, uniqueness, formats, full admin coverage) stand in |
| Keep README.md and ATTRIBUTION.txt from the repo; don't re-harvest them from the live zip | Agent, following PR #38 | The repo copies were corrected there (no hardcoded data, true sources); the zip copies still carry counts and the old wording |
refresh.enabled: false | Agent | Nothing publishes before the owner signs off; flip it when R2 is updated |
Transforms carried over
- GeoNames' own
admin_code1(81-87 andH) → ISO 3166-2:BD (BD-A…BD-H) with the official division name. - The 77 rows GeoNames labels "Dhaka Division" but codes
H(Jamalpur, Mymensingh, Netrakona, Sherpur, split off in 2015) become Mymensingh Division,BD-H. alternative_city_nameempty. Checks (4-digit codes, unique(postal_code, place_name), nonan, all 8 divisions, district and thana on every row) areProducerErrors.
Open questions
- The public sample at
postal.datahub.io/bd/bd.csvis an older build than the zip (admin_code181, notBD-C; 0 of its 100 rows match the zip's first 100). Publishing the new sample fixes this; nothing has been uploaded. - R2 is untouched. Publishing waits for the owner's sign-off.
Provenance
Written 2026-10-11 from the recovered script, the re-run against R2, scripts/parity.py bd (reads the live zip, writes nothing) and the Frictionless validation of the built zip.