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-lu-sample
| Field | Type | Description | Constraints | Title |
|---|---|---|---|---|
| country_code | string | ISO 3166-1 alpha-2 -- always LU | Country Code | |
| postal_code | string | Luxembourg postal code (L- prefix + 4 digits) | { "pattern": "^L-\\d{4}$" } | Postal Code |
| place_name | string | Locality/place name | Place Name | |
| admin_name1 | string | Canton -- 12/12 covered | Administrative Name 1 | |
| admin_code1 | string | ISO 3166-2:LU code | Administrative Code 1 | |
| admin_name2 | string | Commune -- 105 distinct values | Administrative Name 2 | |
| admin_code2 | string | GeoNames' own per-canton commune sequence number (not globally unique) | Administrative Code 2 | |
| admin_name3 | string | Not populated -- Luxembourg's postal source has no third admin tier | Administrative Name 3 | |
| admin_code3 | string | Not populated -- Luxembourg's postal source has no third admin tier | Administrative Code 3 | |
| latitude | number | GeoNames latitude (WGS84) | Latitude | |
| longitude | number | GeoNames longitude (WGS84) | Longitude | |
| accuracy | string | GeoNames accuracy of latitude/longitude. GeoNames documents 1=estimated, 4=geonameid, 6=centroid of addresses or shape; other values (e.g. 3) occur upstream without documentation. Empty where GeoNames gives none. | Accuracy | |
| alternative_city_name | string | Not populated in this release | Alternative City Name |
Download
Download sample CSVAbout
- Last updated
- 6 October 2026
- Total rows
- 100
- Format
- CSV
- File size
- 6.55 kB
About this dataset
Luxembourg (LU): migration notes
Internal record of the P5 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.7.32 (closed 2026-10-02)
- Commit:
19eae9b, the P5 pilot, done directly in the orchestrator session (no subagent) - Parity verdict:
explained(row_orderonly); user signed off 2026-10-02 - Producer:
custom, refresh disabled
Sources
| Input | URL | Notes |
|---|---|---|
| GeoNames postal export | https://download.geonames.org/export/zip/LU.zip | The only input, as in the old builder |
Parity against the live zip (2026-10-02)
Rows: 4,519 live and 4,519 fresh, none only on one side. 0 changed cells. One class: row_order ×1.
| Change | Examples | Cause |
|---|---|---|
| A few neighbouring rows swapped | L-4994 Schouweiler and L-4999 Sprinkange (Dippach) each moved one line; L-8363 Leesbach (Septfontaines) moved | Attributed to GeoNames reordering its export since the 2026-09-02 build; the old builder also kept file order. Not traced to a specific earlier GeoNames file |
The public sample at postal.datahub.io/lu/lu.csv came out unexplained (informational only). It came from an older pipeline; for example its admin_code2 holds GeoNames ids.
Decisions
| Decision | By | Basis |
|---|---|---|
Accept row_order | User, 2026-10-02 (session 068ca403) | "i agree with everything", in answer to the pilot report; recorded in the sign-off section of docs/parity/p5.md |
Remove row and distinct-code counts from README and the descriptor description; keep admin-unit counts ("12 cantons, 105 communes") | Proposed by the orchestrator in the pilot, agreed by the user, 2026-10-02 (session 068ca403) | Became the README counts rule for all P5 datasets |
Keep ATTRIBUTION.txt verbatim (it still says "4,519 rows") | Orchestrator, agreed by the user in the same answer | Later the user said counts should leave ATTRIBUTION too, but not now (pc-3d2, folded into pc-hfz) |
| Accuracy description replaced with the shared GeoNames wording (1/4/6, other values undocumented) | Orchestrator, after the user's "fix the small doc problems" (session 2479b1c9) | b7fb93b, 5311ad3 |
Transforms carried over
From build_postal_codes_product.py:
admin_code1→ ISO 3166-2:LU by addingLU-(GeoNames' canton letters map 1:1, checked against Wikipedia 2026-09-02).alternative_city_nameempty.- Old asserts are
ProducerErrors: unknown canton, a canton with no rows, malformed row, duplicate key. The primary key is (postal_code, place_name, admin_name2), because Blumenthal (L-7639) is listed once per commune it touches. - Rows keep GeoNames file order.
Open questions
ATTRIBUTION.txtand the README still carry counts; left for the end-of-epic sweep (pc-hfz).
Provenance
Reconstructed 2026-10-05 from the orchestrator session 068ca403-0a16-4e07-a5d7-992ec519c699 (pilot work, parity diff, sign-off), session 2479b1c9-c4dd-47e5-be82-34ccf8d49a80 (doc fixes), the commit message and the bd close reason.