Varför har bara 1 av 290 svenska kommuner öppen sopdata?
Det jag ville göra
Vi fick fler soptunnor. Det var inget vi valde. Det är en följd av EU:s reviderade ramdirektiv om avfall (2018/851), svensk lagstiftning (bl.a. förpackningsförordningen SFS 2022:1274 som flyttar ansvaret för fastighetsnära insamling av förpackningar till kommunerna) och lokala kommunala beslut om hur separationen ska verkställas. Samma politiska maskineri som fastslog att jag ska sortera i fyra fraktioner beslutade också om olika hämtningsintervall för olika fraktioner.
Resultatet: fyra kärl, fyra olika tömningsdagar, olika veckor för olika fraktioner. Att hålla koll i huvudet är hopplöst.
Det jag ville ha var enkelt: en iCalendar-prenumeration. Det är ett standardformatet som Google Calendar, Apple Kalender och Outlook har stött i över tjugo år. En URL, en gång, klart. Notis dagen innan. Fungerar på telefonen, datorn, klockan.
Det jag fick var något helt annat: en webbportal som kräver BankID varje gång, en app per kommun, en PDF som beskriver en "typisk vecka", eller en söksida som visar nästa hämtning som text på skärmen. Inget som en kalender kan konsumera. Inget som fungerar när jag är stressad, borta, eller bara vill bli påmind kvällen innan.
Det är en märklig asymmetri: staten kan ålägga mig fyra kärl, men inte ålägga sig själv att publicera schemat i ett format min kalender förstår.
Vad EU faktiskt kräver — även av datat
Det här är inte en teknisk gråzon. Det är reglerat, sedan flera år.
- Öppna data-direktivet (EU) 2019/1024 — offentlig information ska tillgängliggöras i maskinläsbart format, via API:er, utan onödiga tekniska eller juridiska hinder.
- Öppna data-lagen (SFS 2022:818) — den svenska implementeringen. Gäller myndigheter, kommuner och kommunala bolag.
- Genomförandeförordning (EU) 2023/138 — värdefulla dataset (HVD) — vissa datakategorier ska vara fria, avgiftsfria och tillgängliga via API. Miljö- och geodata står uttryckligen med.
- Interoperable Europe Act (2024) — offentliga digitala tjänster ska interoperera över gränser. Standardformat framför proprietära portaler.
Samma unionslagstiftare som skärpte avfallsdirektivet skärpte också datadirektiven. Riktningen är otvetydig: hämtningsscheman är exakt den sortens data som EU förutsätter att kommunerna publicerar öppet.
Verkligheten idag
Av Sveriges 290 kommuner har jag hittat en enda som gör det här rätt.
⭐ Sundsvall — så här ska det se ut
Sundsvall publicerar hela datasetet — samtliga 23 556 adresser, alla hämtningsscheman — som CC0 öppen
data på api.sundsvall.se/Garbage/2281/schedules. Med DCAT-metadata registrerad på
dataportal.se. Med OpenAPI 3.1-spec på /Garbage/api-docs. Utan
inloggning. Utan token. Utan mailkorrespondens.
Det är exakt så här öppna data-direktivet är tänkt att fungera. En utvecklare i vilket EU-land som helst kan bygga en tjänst ovanpå på en eftermiddag. sopkalender.se använder Sundsvalls data direkt — noll scraping, noll gissningar.
Resten av Sverige
För övriga 289 kommuner ser bilden ut så här:
| Mönster | Typiska exempel | Vad det innebär |
|---|---|---|
| BankID-låst "Mina sidor" | CGI BFUS (Stockholm Vatten, Vakin/UMEVA, Karlstads Energi, Alingsås Energi) | Ingen tredjepartsintegration möjlig utan att bygga BankID-flöde som då hamnar i personuppgiftshantering för data som inte är personlig |
| Internt widget-API | SiteVision Fetchplanner (Falun, Örnsköldsvik), Limepark, EDP Future (43 kommuner via Vafab, SSAM, Kretslopp Sydost, Remondis) | Fungerar bara så länge kommunens webbleverantör inte byter format. Ingen dokumentation, ingen SLA, ingen garanti |
| PHP 5.4 + ISO-8859-1 | Indecta (Östra Göinge, Osby, Sjöbo) | Måste percent-koda Å som %C5 på utvägen och sniffa encoding på inkommande. OMG!
Det här är skört men å andra sidan verkar det inte ändras särskilt ofta. |
| Proprietär mobilapp med Bearer-token | Avfallsappen/Bozzanova (~50 kommuner) | Kräver att man extraherar token ur den kompilerade mobilapp-binären och gör en register/bind-dans per tenant. Helt görbart men jag riskerar få en upprörd app leverantör efter mig. Av alla möjliga lösningar är det här den mest provocerande eftersom det verkar som att de då väljer att lägga pengar på app och integration med app som istället hade kunnat läggas på att faktiskt leverera öppna data. Jag har inget personligt emot appen men gör det i rätt ordning i så fall. Öppna data först och därefter en app som konsumerar öppna data. |
Datat finns — det är bara inlåst bakom portaler, appar och obskyra widgets. sopkalender.se täcker idag 54 kommuner. Varenda en av dem, förutom Sundsvall, är resultatet av att scrapea en webbsidas backend, hantera legacy-encodingar, eller reverse engineera vilken JSON-nyckel ett SiteVision-portlet råkar heta just i år. När en kommun byter leverantör går integrationen sönder utan förvarning.
Och för de kommuner vi inte täcker alls — hittills bekräftat Nacka och Malmö — har vi identifierat att den upstream de använder aktivt blockerar Google Clouds IP-adresser i brandväggen. Så även när ett bakvägs-API existerar kan det blockeras för molnbaserade tjänster. Data som betalats av skattebetalare är tekniskt oåtkomlig från infrastruktur som också används av skattebetalare.
Vad som borde hända
- Publicera hämtningsdata som HVD enligt (EU) 2023/138 — CC0, via API, utan autentisering. Sundsvall bevisar att det är trivialt.
- Standardformat, inte portaler. En iCalendar-feed är en helgeftermiddag för en junior utvecklare — om datat är öppet.
- Registrera på dataportal.se med DCAT-metadata — så att det går att hitta utan att gissa URL:er.
- Sluta gömma data bakom BankID när ingen personuppgift är inblandad. "Vilken vecka töms kärl 3 på Storgatan 5?" är inte en känslig uppgift.
- Sluta blockera moln-IP-adresser i brandväggen. Om datat är publikt är det publikt.
Om lagstiftaren kan besluta att jag ska ha fyra kärl, kan lagstiftaren också se till att jag får veta när de töms — i ett format som min kalender förstår.
Datat är redan betalt. Direktivet är redan på plats. Sundsvall visar att det går.
Frågan till resten av Sverige: vad väntar ni på?
Stöd FSFE:s kampanj för att offentligt finansierad mjukvara ska vara fri och öppen.
Logo: FSFE,
CC BY-SA 4.0.