Postal Codes Dataset for Sweden, SE

297
0
Updated:
Files:1
Size:7.47 kB
Formats:csv

Postal Codes Dataset for Sweden, SE including name of the city, town, or place, various administrative divisions and alternative city names.

Part of a Data Solution

  • Postal Codes Solution

    Every worldwide postal-code dataset in one bundle — the ultimate global reference for precise postal codes.

    Explore →

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
20% off
$99.90$79.92
one-time payment

API Access

Access dataset files directly from scripts, code, or AI agents.

Browse dataset files
Dataset Files

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.

/logistics/postal-codes-se/
https://datahub.io/logistics/postal-codes-se/_r/-/.licensing-notes.md
https://datahub.io/logistics/postal-codes-se/_r/-/README.md
https://datahub.io/logistics/postal-codes-se/_r/-/datapackage.yml
Key Files

Start with these files — they give you everything you need to understand and access the dataset.

datapackage.ymlmetadata & schema
https://datahub.io/logistics/postal-codes-se/_r/-/datapackage.yml
README.mddocumentation
https://datahub.io/logistics/postal-codes-se/_r/-/README.md
Typical Usage
  1. 1. Fetch datapackage.yml to inspect schema and resources
  2. 2. Download data resources listed in datapackage.yml
  3. 3. Read README.md for full context

Data Files

Postal Codes Data Resource for Sweden, SE

About

Last updated
7 November 2024
Total rows
...
Format
CSV
File size
7.47 kB

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."