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-hu-sample
| Field | Type | Description | Constraints | Title |
|---|---|---|---|---|
| country_code | string | ISO 3166-1 alpha-2 -- always HU | Country Code | |
| postal_code | string | Hungarian postal code (4 digits) | { "pattern": "^\\d{4}$" } | Postal Code |
| place_name | string | Locality/place name | Place Name | |
| admin_name1 | string | Megye (county) or Budapest -- 20/20 covered | Administrative Name 1 | |
| admin_code1 | string | ISO 3166-2:HU code | Administrative Code 1 | |
| admin_name2 | string | Not populated -- jaras (district) is genuinely absent from GeoNames' postal export for Hungary, and GeoNames' own general gazetteer covers only a small fraction of places at this tier, too sparse to close the gap; see ATTRIBUTION.txt | Administrative Name 2 | |
| admin_code2 | string | Not populated | Administrative Code 2 | |
| admin_name3 | string | Not populated in this release | 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 | 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
- 5.54 kB
About this dataset
Hungary (HU): 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.24 (closed 2026-10-02)
- Commit:
6f33a9d(worktree commitbfb4191, same content), landed in batch 2 - Parity verdict:
explained(row_order×1); signed off by the user - Producer:
custom, refresh disabled
Sources
| Input | URL | Notes |
|---|---|---|
| GeoNames postal export | https://download.geonames.org/export/zip/HU.zip | The only input the old builder used. Magyar Posta and KSH have no confirmed redistribution licence (2026-08-29 audit) |
Parity against the live zip (2026-10-02)
Rows: 3,571 live and 3,571 fresh, none only on one side, 0 changed cells. The one class is row_order: rows reordered within postal codes, consistent with GeoNames reordering its export. The agent took this from parity's classification and showed no example rows; it was not traced further.
The informational sample check against https://postal.datahub.io/hu/hu.csv came back unexplained. It is outside the gate and was not traced.
Decisions
| Decision | By | Basis |
|---|---|---|
Accept row_order | User, 2026-10-02 ("agree to all" to the batch 2 sign-off, session 2479b1c9-…) | Recorded in docs/parity/p5.md |
| Remove row and distinct-code counts from README and descriptor | Orchestrator instruction (user's README counts rule) | Also dropped the stale licence_status.decision sentence |
| "83 of 16,020 places" (GeoNames gazetteer coverage of the járás tier) → "a small fraction of places" | Agent; kept by the orchestrator | It counts GeoNames gazetteer places, so it is volatile like row counts. The agent asked the user to confirm; the orchestrator kept it without putting the question to the user |
| README lead "all 20 counties plus Budapest" → "all 19 counties plus Budapest" | Agent; kept by the orchestrator | Matches the coverage section (19 megye + Budapest = 20 units) |
accuracy wording admits undocumented values such as 3 | Orchestrator | Follow-up commit 5311ad3, reported in the batch 2 summary |
Transforms carried over
From build_postal_codes_product.py:
admin_code1→ ISO 3166-2:HU by addingHU-: GeoNames' 2-letter county code already is the ISO code (all 20 verified 2026-08-29). An unknown code is aProducerError.admin_name1keeps the source text (e.g. pre-2020 "Csongrád").- Literal "nan" → empty.
alternative_city_nameempty.- The old asserts are now
ProducerErrors: 12-column HU rows, known county code, all 20 counties present,admin_name2still empty (so the járás gap gets revisited if GeoNames fills it), no float-style accuracy, unique (postal_code, place_name). No row-count assert.
Open questions
- Resolved (2026-10-05, pc-28e.7.60): ATTRIBUTION.txt now says 19 counties. The counts stay for pc-hfz. Was: ATTRIBUTION.txt still says "3,571 rows" and "all 20 counties (megye) plus Budapest", which disagrees with the corrected README lead. It also cites the "16,020 populated-place entries" gazetteer figure. Left for the end-of-epic README/ATTRIBUTION sweep (pc-hfz).
Provenance
Reconstructed 2026-10-05 from the agent transcript 2479b1c9-c4dd-47e5-be82-34ccf8d49a80/subagents/agent-ae9ed63aef9c52923.jsonl, the orchestrator session 2479b1c9-…, the commit messages and the bd close reason.