Czechia (CZ) — internal licensing notes

Tier-1/2 official source found, 2026-09-03 — stronger than GeoNames, larger engineering lift

A genuinely official, CC-BY-4.0 source exists and is worth pursuing as a future upgrade, but it is address-point granularity, not postal-code granularity — a real rebuild, not a drop-in swap. ČÚZK (the Czech Office for Surveying, Mapping and Cadastre — a government body, tier 1/2 in this project's Source Authority Hierarchy) publishes RÚIAN (Register of Territorial Identification, Addresses and Real Estate) — per-address-point CSV covering the whole country, via its Geoportal (geoportal.cuzk.cz).

Confirmed fields: address-point code, municipality code and name, postal code (PSČ), building/orientation numbers, and coordinates in the S-JTSK system (would need reprojection to WGS84) — genuinely richer and more current than GeoNames, and government-official rather than a third-party gazetteer.

Licence: CC BY 4.0, same family already used throughout this catalogue — no new licence complexity.

Why not switched to immediately — confirmed scope, 2026-09-03: fetched the actual file (vdp.cuzk.gov.cz/vymenny_format/csv/20260831_OB_ADR_csv.zip, 63 MB compressed, 354 MB uncompressed) to scope the real lift rather than guess. It is 6,258 separate per-municipality CSVs (cp1250-encoded, semicolon-delimited), one row per address point, with PSČ (postal code) but no district/region columns at all — only a bare municipality code. A real RÚIAN-based build needs: (1) parsing ~7-8M address-point rows across 6,258 files, (2) aggregating to postal-code level (mean coordinate, representative municipality), (3) a SEPARATE fetch of an official municipality→district→region crosswalk (not in this file) to reconstruct the kraj/okres hierarchy GeoNames already gives for free, and (4) reprojecting coordinates from S-JTSK (EPSG:5514) to WGS84 — a real transform, not a trivial swap. This is a multi-source GIS pipeline, not a drop-in replacement, and materially larger than every other build in this session's queue. Deferred, not because GeoNames is preferred by default, but because the confirmed scope here is disproportionate relative to a 10-country backlog — flagged as a genuine future upgrade for whoever has the time to build the aggregation + crosswalk + reprojection pipeline properly, not something to rush.

GeoNames research, 2026-09-03 (current fallback — clean and small,

just needs the crosswalk fix below)

Clean GO, with one dangerous false-friend crosswalk hazard flagged. GeoNames' postal export is clean and complete at 2 tiers, but its own admin_code1 numbering happens to also be 2-digit numbers that look like ISO 3166-2:CZ codes and are NOT — a naive prepend would silently ship wrong-but-plausible codes on every row.

The source — GeoNames CZ

https://download.geonames.org/export/zip/CZ.zip      # 15,507 rows

Licence CC-BY-4.0, verified against export/zip/readme.txt on 2026-09-03 — Czechia carries no per-country caveat (the readme's only restricted countries are GB, CL, CN, IE, MT, AR, BR).

Verified directly against the raw source file:

• admin_name1/admin_code1 — Kraj (region), 14/14 covered (13 regions + Prague). GeoNames' own codes (52, 78–90) are internal and numerically overlap ISO 3166-2:CZ's own numbering space without matching it — e.g. GeoNames 52 = Hlavní město Praha, but the real CZ-52 = Královéhradecký kraj, a completely different region. Verified against Wikipedia's ISO_3166-2:CZ page 2026-09-03. This is a more dangerous hazard than JP/IN's numeric mismatch, because both the wrong and right codes are valid-looking 2-digit numbers in the same range — a rebuild that doesn't check this by name would ship confidently wrong data. Requires a full name-based crosswalk (14 rows).
• admin_name2 — Okres (district), 77 distinct values: the real 76 okresy plus Prague itself, which stands outside the okres system as a district-equivalent statutory city. Not a data error, a real structural nuance worth stating plainly in the README.
• admin_name3 — empty on all 15,507 rows. Czechia's postal source has no third admin tier, same shape as LU.
• 0 exact duplicate rows, 0 (postal_code, place_name) collisions, 0 literal "nan" strings, clean integer accuracy values (1/3/4) at the source. Primary key is simply (postal_code, place_name) — cleanest structure in this research batch.

licence_status (proposed — needs a build pass before shipping)

{
  "channel": "postal-codes-r2",
  "source_url": "https://download.geonames.org/export/zip/CZ.zip",
  "licence_id": "CC-BY-4.0",
  "collected_at": "2026-09-03",
  "decision": "compatible",
  "decided_by": "claude-session-2026-09-03",
  "decided_at": "2026-09-03"
}

Proposed tier

B ($49). Single source, structurally the cleanest of this batch (0 collisions, 0 duplicates, 2 clean tiers), but the region-code false-friend crosswalk is real, disclosure-critical work — the kind of mistake that ships looking completely fine until someone checks the actual region names.

Build — 2026-09-03, GeoNames-only (RÚIAN path scoped and deferred, see above)

Built via datasets/cz/scripts/build_postal_codes_product.py.

All 14 admin_code1 values verified as the real ISO 3166-2:CZ codes (CZ-10…CZ-80), crosswalked by region NAME, not GeoNames' own numbering. Frictionless validation: valid: True. Zero literal "nan" strings, zero float-formatted accuracy, zero duplicates.

Status: built and validated locally only. Nothing published to R2, nothing committed to git yet. Existing live cz.csv (15,507 rows, bare CSV, no datapackage/README/zip) has the standard "nan" corruption seen elsewhere in this catalogue (introduced downstream of GeoNames, not present upstream).