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
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.yml to inspect schema and resources
- 2. Download data resources listed in datapackage.yml
- 3. Read README.md for full context
Data Files
Postal Codes Data Resource for Sweden, SE
| Field | Description | Title |
|---|---|---|
| country_code | ISO 3166-1 alpha-2 code for the country. | Country Code |
| postal_code | Postal code for the location. | Postal Code |
| place_name | Name of the city, town, or place. | Place Name |
| admin_name1 | Primary administrative division (e.g., state, region). | Administrative Name 1 |
| admin_code1 | Code for the primary administrative division. | Administrative Code 1 |
| admin_name2 | Secondary administrative division (e.g., county, district). | Administrative Name 2 |
| admin_code2 | Code for the secondary administrative division. | Administrative Code 2 |
| admin_name3 | Tertiary administrative division (e.g., municipality, borough). | Administrative Name 3 |
| admin_code3 | Code for the tertiary administrative division. | Administrative Code 3 |
| latitude | Latitude coordinate of the place. | Latitude |
| longitude | Longitude coordinate of the place. | Longitude |
| accuracy | Accuracy level of the latitude and longitude coordinates. | Accuracy |
| alternative_city_name | Alternative name(s) for the city or place. | Alternative City Name |
Download
Download sample CSVAbout
- Last updated
- 7 November 2024
- Total rows
- ...
- Format
- CSV
- File size
- 7.47 kB
- Source
- Multiple sources
About this dataset
Sweden (SE) — internal licensing notes
Status: confirmed live and pushed to R2 (2026-08-21). PostNord blocker resolved. One new, previously-undisclosed nuance found on re-check — see below.
The problem (datahub-next#941 §1.3, opened 2026-08-08)
"The register is administered by Postnummerservice i Norden AB, whose terms
state: 'Resale of data is not permitted' and 'Sublicensing to third parties
is not permitted'. Sweden is an EEA jurisdiction with a sui generis database
right, so this bites independently of copyright."
Recommended fix: withdraw as currently sourced; rebuild from GeoNames
SE.zip (CC BY 4.0, no country restriction listed) or licence from
Postnummerservice with an express redistribution right (not in their
standard tiers).
Status per the issue's own comment thread
2026-08-13: "currently working on rebuilding Chile and reviewing other permitted sources for Sweden aside from geonames." No completion comment follows — this reads as still in progress as of the issue's last update, not closed.
What I found in the codebase, 2026-08-19 (this session)
While auditing script self-containment/reproducibility across the
postal-codes product (unrelated task, didn't know this issue existed at
the time), I found se/scripts/fetch_source.py + build_base.py already
implement exactly the GeoNames-based rebuild the issue recommends — CC BY
4.0, no PostNord dependency. Fixed the scripts to be self-contained (they
hardcoded paths from a different repo) and verified them end-to-end: fresh
fetch of GeoNames SE.txt, rebuild produces 18,887 rows vs 18,858 live on
R2. diff_provenance.py (already present in the pipeline) confirms this is
benign upstream growth, not an error: 29 postal codes exist only in the
current GeoNames export (added since the original scrape), 0 rows exist only
in the live scrape — a strict superset, with 99.89%+ field agreement on the
18,858 shared rows.
This confirms the sourcing direction from the 2026-08-13 comment has been implemented in the actual pipeline.
Confirmed live on R2, 2026-08-21
Checked the actual live objects directly: se/se.csv, se/datapackage.json,
se/README.md, se/se.zip, all dated 2026-08-18 — this was published
three days after the "in progress" comment, closing the PostNord blocker in
practice even though no comment on the issue says so explicitly.
The live datapackage.json declares two licences:
CC-BY-4.0 — postal layer (GeoNames)
CC-BY-SA-4.0 — administrative layer (Wikipedia)
Initially read this as a live share-alike risk on the admin layer — traced
it further and it isn't. Checked the actual committed pipeline code
(se/scripts/build_base.py, package.py) that's supposed to produce this
data: there is zero mention of Wikipedia anywhere in the entire se/
folder. admin_name1/admin_code1 (län) come from a hardcoded dictionary
of the 21 official Swedish län names mapped to their ISO 3166-2:SE codes (a
public standard, not Wikipedia content); admin_name2/admin_code2
(kommun) come straight from GeoNames' own native postal-export fields.
package.py's own licence-writing code hardcodes only
[{"name": "CC-BY-4.0", ...}] — no CC-BY-SA entry at all.
Conclusion: the currently-committed pipeline is 100% GeoNames-sourced and produces no Wikipedia dependency. The CC-BY-SA-4.0/Wikipedia entry in the live datapackage.json is a leftover from an earlier build iteration (consistent with "reviewing sources aside from geonames" being in-progress on 2026-08-13) that predates this pipeline's current, Wikipedia-free form — never re-published after the pipeline moved off Wikipedia. Row values agree 99.89%+ regardless of which iteration produced them because län/kommun membership is a stable fact, not something that varies by source.
Fix needed is a republish, not a legal review: run the current
publish_r2.py --apply (already verified working this session, dry-run
confirmed) to push the corrected, Wikipedia-free metadata live, replacing
the stale CC-BY-SA declaration. Not yet done — this note only confirms the
pipeline is ready.
For the record, in case this pattern recurs elsewhere in the catalogue: checked Wikimedia's own Terms of Use directly. They state: "Where you own Sui Generis Database Rights covered by CC BY-SA 4.0, you waive these rights. As an example, this means facts you contribute to the projects may be reused freely without attribution." So even where Wikipedia genuinely is a source, pure factual extraction (name + hierarchy, not copied prose/table formatting) is very likely fine to sell — the share-alike concern applies to copied expression, not to facts, and Wikimedia's contributors have already waived the sui generis right that would otherwise attach.
Also still unresolved: whether GeoNames CC BY 4.0 attribution is shipping
anywhere a buyer would see it (product page, ATTRIBUTION.txt per issue
§4's general requirement), and whether anyone has formally closed this item
on the issue thread.
Source: datahub-next#941 (opened by @anuveyatsu, 2026-08-08), comment by @amautadev, 2026-08-13; pipeline verification, 2026-08-19 (this session); live-object check, Wikimedia ToU check, and pipeline-code trace, 2026-08-21.
CLOSED — 2026-08-24
Republished. README.md and datapackage.json on R2 no longer declare
CC-BY-SA-4.0/Wikipedia — both now state GeoNames CC BY 4.0 only, matching
what the committed pipeline (build_base.py, package.py) actually
produces. package.py updated to also write and zip a standalone
ATTRIBUTION.txt (issue §4's general requirement) — now live at
se/ATTRIBUTION.txt and inside se.zip. _meta/catalog.json's SE entry
rebuilt to include it. This closes the item flagged above as "still
unresolved."