Denmark (DK) — internal licensing notes

Source research, 2026-08-29 — sellability + reproducibility audit

Clean GO. Official government source, unambiguous CC BY 4.0, complete coverage, no rival candidates needed. This is one of the strongest cases in the catalogue — closer to CA/PT than to the thin/blocked cases (ZA, SA).

The source — DAWA / Datafordeleren (Danish national geodata platform)

https://api.dataforsyningen.dk/postnumre     # postal districts, live-verified 2026-08-29
https://api.dataforsyningen.dk/kommuner      # municipality join table

Publisher: SDFI (Styrelsen for Dataforsyning og Infrastruktur), the Danish government geodata agency. Postal codes themselves originate from PostDanmark/PostNord and are kept current by SDFI's register.

Licence verified 2026-08-29 via SDFI's own terms documents:

• dataforsyningen.dk/asset/PDF/.../Vilkår for frie geografiske data og CC BY 4.0 licens.pdf
• datafordeler.dk/vejledning/brugervilkaar/ — "Users of free basic data from Datafordeler are subject to CC BY 4.0 licence… may freely download, share and adapt… must credit the responsible register in a suitable place."

CC-BY-4.0, unambiguous, commercial use explicitly permitted on attribution alone. No share-alike, no per-country carve-out (unlike GeoNames' GB/CL/CN/IE/MT/AR/BR restrictions).

DAWA shutdown — live but not durable, use Datafordeleren as the target

DAWA was announced to be retired ("DAWA lukkes 1. juli 2026") with data migrating to Datafordeleren, the platform's actual long-term successor. That date has already passed as of this research (2026-08-29), but a direct live check today still returned HTTP 200 with real JSON from api.dataforsyningen.dk/postnumre. Datafordeleren (datafordeler.dk) is also confirmed live (HTTP 200) and exposes the same underlying registries.

Do not build a reproducibility script that assumes DAWA stays up — it is explicitly a stopgap slated for retirement, just running later than announced. Target Datafordeleren's endpoint (or fail over to it) rather than treating the DAWA URL as durable. Same caution already recorded in the FedEx-schema research for this country (see below).

This country was already researched and built once, for the other product

fedex-agents-prototype/countries/DNK/ has a full, QA-PASSED 12-column build from the same DAWA source (research.json, approved 2026-07-31, qa_log.json shows 1089/1089 = 100% coverage, 0 duplicates, PASS). That research already resolved every hard question this rebuild would face:

• Admin structure: Region (5, ISO 3166-2:DK codes DK-81…DK-85) → Kommune/municipality (98, no ISO code — DAWA kommuner.kode, 4-digit) → Postdistrikt/postal district (1,089 — not a formal admin tier, just the town/area name DAWA associates with the code).
• Coordinates: DAWA's visueltcenter (visual center of the postal code's polygon) — real per-code points, not a shared centroid; equivalent to AREA accuracy in this project's tiering.
• Multi-municipality codes: DAWA's kommuner field is an array where a postal code straddles more than one municipality; the FedEx build's decision was to use kommuner[0] as authoritative and disclose the rest.
• Edge cases already decided: Greenland codes (3900–3999, administered via the Danish postal system) and 0xxx special/company codes (PO box/high-volume recipients, no polygon → no coordinate) are both kept in, each flagged rather than dropped or silently included as ordinary rows.
• One real data correction found in QA: postal code 2770 was miscoded to København and corrected to Tårnby.

None of this needs to be re-derived — the 13-column build can reuse the same source, same admin resolution, same edge-case handling, converted to schema (alpha-3→alpha-2, camelCase→snake_case, admin_code1 = ISO suffix, admin_code2 = kommune kode, no formal admin_code3 since Postdistrikt isn't an administrative tier).

licence_status (proposed — needs human sign-off before shipping)

{
  "channel": "postal-codes-r2",
  "source_url": "https://api.dataforsyningen.dk/postnumre",
  "licence_id": "CC-BY-4.0",
  "collected_at": "2026-08-29",
  "decision": "compatible",
  "decided_by": "claude-session-2026-08-29",
  "decided_at": "2026-08-29"
}

Proposed tier

B ($49). Single official source normalised in place — real work (region/kommune join, visueltcenter coordinate handling, multi- municipality disambiguation) but no second authoritative dataset consolidated onto it. Matches the AU/IT/PH shape in docs/PRICING_TIERS.md, not the CA/PT/SG multi-source shape.

Verdict

Build it. No licensing obstacle, no coverage gap, no rival source needed. The only real engineering task is the schema conversion + a Datafordeleren-target (not DAWA-target) fetch script, mirroring work already fully solved once in the FedEx-schema build.

Build — 2026-08-29 (local only, not published)

Built via datasets/dk/scripts/build_postal_codes_product.py, from raw snapshots of api.dataforsyningen.dk/postnumre and .../kommuner fetched the same day (still live, despite the announced 2026-07-01 DAWA shutdown).

Admin-left completeness check caught a real coverage hole. Taking DAWA's kommuner[0] as authoritative for every postal code — the naive approach — left 7 of 99 municipalities with zero rows: Christianso, Glostrup, Herlev, Hvidovre, Mariagerfjord, Rodovre, Soro. Each one only ever appears as a secondary member of a multi-municipality postal code in DAWA's own ordering, never first, so a first-listed join silently drops it — the same failure shape as Guinea's Dixinn/Matam miss this project already learned from. Fixed by re-pointing 8 specific postal codes (7 for the missing municipalities plus the pre-existing Tarnby correction) to the non-default listed municipality, each verified directly against DAWA's own kommuner array for that code — not invented. admin_code2 coverage is now 99/99, asserted at build time.

Results:

admin_name3/admin_code3 ship empty — Postdistrikt (place_name) is not a distinct third administrative tier in Denmark's own structure, it's synonymous with the postal district name already in place_name. alternative_city_name ships empty — DAWA carries no alternate-name field and adding a second source for this alone would turn a clean single-source build into a consolidation, out of scope for tier B.

Frictionless validation: valid: True.

Status: built and validated locally only. Nothing published to R2, nothing committed to git. datasets/dk/README.md and datapackage.yml updated in place (tier B, premium_source_key: dk/dk.zip, real sources/licenses, replacing the "Multiple sources" placeholder).