Come la mappa «Popolazione 2011–2021» confronta due censimenti

1 Il problema

Confrontare il censimento 2011 con il 2021 in Italia significa affrontare tre disallineamenti simultanei:

La mappa non «risolve» questi problemi in modo definitivo: li affronta con una strategia a due livelli territoriali e con aggregazione spaziale dipendente dalla scala, che è la vera chiave del metodo.

2 Architettura: due confronti, non uno

La mappa contiene due temi di confronto sovrapposti, mutuamente esclusivi per scala:

Il passaggio di consegne a 1:150.000 è la scelta progettuale centrale: il confronto per sezioni, che è geometricamente fragile, viene mostrato solo quando si è abbastanza dentro da poterlo leggere come pattern locale; il confronto comunale, robusto, copre tutte le scale superiori. Anche i poligoni delle sezioni hanno featureupper: "1:150000", e il caricamento delle basi territoriali è per regione, ricalcolato al volo quando il centro mappa cambia regione (ixmaps.htmlgui_onZoomAndPan → __checkNewRegion → map().replace("sezioni_2011"/"sezioni_2021", …)).

3 Struttura dei codici perché il join per ID è possibile

Nei file ISTAT degli indicatori la chiave di sezione è la concatenazione PROCOM + numero di sezione a 7 cifre, in entrambe le annate:

Il codice sfrutta esattamente questa regola per ricavare il comune da una sezione (layer_compare.js:135):

let procom = value.substr(0, value.length - 7);

Le sezioni «speciali» …8888888 (popolazione non localizzabile in una sezione) vengono eliminate in entrata (select("WHERE SEZ2011 NOT 888888")). Sono trascurabili: 0,02–0,06 % della popolazione regionale nei campioni verificati (VdA e TAA, entrambe le annate).

4 La pipeline di confronto

4.1 Livello comunale — query_data_procom_all() layer_compare.js:222

(1) Traduzione SITUAS (report 99) — ixmaps.__getSituasComuneTranslation() (layer_compare.js:78) legge ixmaps.__getSituasCodes() (layer_compare.js:54), che scarica una sola volta per sessione lo snapshot statico situas_codes.json da CDN (jsDelivr, repo ixmaps-data) e lo mette in cache — non interroga mai situas-servizi.istat.it dal browser. Lo snapshot è generato da ixmaps-data/scripts/fetch_situas_censimenti_2011_2021.py, che interroga situas-servizi.istat.it/publish/reportspooljson?pfun=99&pdatada=31/12/2011&pdataa=31/12/2021 (individuato tramite lo strumento ondata/opensituas) e lo ripubblica pre-elaborato. Il report 99 è una tabella di traduzione già risolta dall'ISTAT stesso — un solo lookup sostituisce sia il passaggio AP sia il passaggio CS/fusione, e in più risolve correttamente le 14 incorporazioni (tipo ES, § 7.1):

data_2011.column("PROCOM").map(function (value) {
    return newPROCOM[value] || value;
});

Un singolo lookup, non un ciclo che segue le catene: il report 99 dà già, in un'unica riga, il codice finale risolto per l'intero periodo richiesto. Seguire le catene non è necessario, e sarebbe anzi sbagliato: il report elenca anche gli oltre 7.600 comuni mai cambiati come auto-mappature ("1001" → "1001"), su cui un ciclo che insegue il valore successivo non terminerebbe mai. I codici SITUAS sono stringhe a 6 cifre con zero iniziali ("002114"); il CSV dei censimenti usa invece codici senza zero iniziali ("2114") — lo script di generazione normalizza entrambi i lati con la stessa convenzione String(Number(...))/str(int(...)) già in uso nel resto del file, così lo snapshot arriva già pronto per il lookup diretto.

Il periodo di traduzione (31/12/2011 → 31/12/2021, fissato nello script di generazione) deve coincidere con l'annata dei dati 2021: un periodo più ampio (es. fino a oggi) rimapperebbe i codici 2011 oltre il punto in cui si trova il lato 2021 del confronto, disallineandoli di nuovo — per esempio il riordino sardo 2026 (§ 4.2) non va applicato qui, perché i dati 2021 non lo riflettono.

Comuni nati da porzioni di territorio (Mappano, 001316, 2017; Misiliscemi, 081025, 2021) non hanno un codice sorgente 2011 per costruzione: SITUAS li lascia correttamente senza predecessore invece di inventarne uno.

(2) condense somma le righe 2011 che, dopo la rimappatura, puntano allo stesso comune 2021: è il passaggio che realizza materialmente l'aggregazione dei comuni fusi (5 comuni della Valsamoggia → 1 riga 2011 confrontabile con la riga 2021 di Valsamoggia).

(3) Data.Merger produce le colonne P1.1 (2011) e P1.2 (2021), ST1.1/ST1.2, ecc. La coppia di suffissi è ciò che i temi leggono come value: "P1.1|P1.2".

(4) ST1.12 (layer_compare.js:275) è la % di stranieri 2011 riproiettata sulla popolazione 2021: floor(ST1.1 × P1.2 / P1.1). Nessun tema attuale la usa — la tecnica value100 in coppia descritta al § 5 è corretta anche sotto aggregazione.

4.2 Livello sezione — query_data() layer_compare.js:99

Differisce in tre punti importanti:

1. applica solo la rimappatura AP, e la applica al prefisso dell'ID di sezione: 70010000001 → sostituzione del solo PROCOM iniziale. Le fusioni non vengono rimappate (il § 7.3 mostra che è la scelta giusta). La fonte è ixmaps.__getSituasApOnlyTranslation() (layer_compare.js:89), che legge lo stesso snapshot statico situas_codes.json di § 4.1 (sotto la chiave ap_only_translation, popolata dallo script di generazione dal report SITUAS 129 — «Variazioni amministrative e territoriali dei comuni dal 1991», tutta la storia dal 1991 a oggi in un'unica chiamata — filtrando su DESC_COD_VARIAZIONE.startswith("AP") e data evento (DATA_INIZIO_AMMINISTRATIVA) ≤ 31/12/2021, lo stesso limite superiore usato per il report 99, per non disallineare i due lati del confronto). Report 99 non è utilizzabile qui: è già una traduzione «appiattita» che mescola AP+CS+ES, e non può essere filtrata per tipo — userlo rimapperebbe anche le fusioni, sbagliato a livello di sezione (§ 7.3).
   
   Gli eventi AP entro il 31/12/2021 sono 314 successivi al 2011 (progressione: 1 nel 2017 — Sappada, BL→UD; 1 nel 2018 — Torre de' Busi, LC→BG; 2 nel 2021 — Montecopiolo e Sassofeltrio, PU→RN — oltre ai 157 del riordino sardo 2016). Un secondo riordino sardo, 155 eventi AP con decorrenza 01/01/2026, è escluso dal filtro sulla data perché posteriore all'annata 2021 dei dati;
2. non fa condense: la sezione è già l'unità minima;
3. esegue un padding bidirezionale che trasforma il merge in un full outer join (layer_compare.js:142–152):

var lookup1 = data_2011.lookupStringArray({key:"SEZ2011",  value:"P1"});
var lookup2 = data_2021.lookupStringArray({key:"SEZ21_ID", value:"P1"});
for (var i in lookup1) { if (!lookup2[i]) data_2021.addRow({"SEZ21_ID": i}); }
for (var i in lookup2) { if (!lookup1[i]) data_2011.addRow({"SEZ2011":  i}); }

Poiché Data.Merger accoppia solo chiavi presenti in entrambe le tabelle, il padding garantisce che l'unione delle sezioni delle due annate sopravviva al merge: le sezioni scomparse e quelle nuove restano nella tabella, con il lato mancante vuoto.

Effetto collaterale importante: le righe di padding hanno solo la colonna ID. Il filtro filter_compare = 'WHERE PROCOM.2 like "*"' — che nel motore ixmaps significa letteralmente «il campo non è vuoto» (maptheme.js:9418–9421: result = this.__szValue.length) — funziona quindi come test di esistenza nel 2021. Ne deriva un'asimmetria: nel tema a numeri assoluti le sezioni scomparse vengono scartate, mentre le sezioni nuove restano e appaiono come crescita da zero. È il punto più delicato del metodo a livello di sezione (§ 8).

5 Dove viene calcolata la differenza nel motore, dopo l'aggregazione

Il delta non è precalcolato nei dati: è il motore SVG a calcolarlo, e l'ordine delle operazioni è ciò che rende il confronto matematicamente corretto anche quando i poligoni non coincidono.

In maptheme.js (post-load processing, righe ~10937–11045) la sequenza è:

1. aggregazione spaziale delle righe (AGGREGATE|SUM): somma dei valori grezzi per unità di aggregazione;
2. se è definito value100, ogni valore viene convertito in percentuale del proprio denominatore: v[k] × 100 / v100[k];
3. DIFFERENCE: v[0] ← v[1] − v[0]; con RELATIVE: v[0] ← 100 / v[0]_orig × (v[1] − v[0]) (con guardia: se v[0]_orig ≤ nField100Min il risultato è 0, invece di infinito).

Ne seguono le tre formule effettivamente disegnate:

Rappresentazione: userdraw: "arrowChart" (plugin D3 usercharts/d3/arrow_chart.js) disegna una freccia la cui altezza è proporzionale al valore (normalizzata su normalsizevalue, con sizepow come esponente di percezione), verso l'alto/il basso secondo il segno, con i due colori di colorscheme (fadenegative attenua il ramo negativo) ed etichetta numerica se lo spazio basta.

6 L'aggregazione dipendente dalla scala

aggregationscale è una lista di coppie soglia di scala → unità di aggregazione; il motore (maptheme.js:7943–7962) scorre la lista e l'ultima soglia superata vince, quindi più si esce di zoom più l'aggregazione è grossolana. Valori non numerici sono nomi di campo, …px è una griglia in pixel schermo.

Tema comunale (aggregationscale: ["1:1","PROCOM.1", "1:10000","50px", "1:2000000","25px", "1:7000000","REGIONE.1"]):

Tema per sezioni (aggregationscale: ["1:1","0", "1:10000","50px"]): nessuna aggregazione al massimo zoom, griglia 50 px appena si esce. RELOCATE riposiziona la freccia aggregata nel baricentro geografico dei punti aggregati (non al centro della cella), così le frecce restano ancorate al tessuto costruito.

7 I due casi difficili

7.1 Aggregazioni di comuni fusioni, nuove province — quanto funziona

Confrontando le due tabelle censuarie con ciascuna strategia di allineamento dei codici, ho misurato quanti codici restano orfani (cioè quanta popolazione non entra nel confronto):

Con la traduzione SITUAS il confronto comunale è completo sul lato 2011: ogni comune del 2011 trova una controparte 2021. Rimane un solo tipo di residuo, sul lato 2021, ed è strutturale — non un limite del metodo di rimappatura (vedi sotto): report 99 risolve AP + CS + ES in un solo lookup già fornito dall'ISTAT, ed è sempre aggiornato alla data richiesta (§ 4.1).

Non gestite da SITUAS: le variazioni di tipo AQ (acquisizione di territorio, 197 comuni coinvolti su tutta la serie storica, § 9) e CE (cessione/permuta, 197 comuni). Sono comuni che restano con lo stesso codice ma con un perimetro diverso: il confronto li tratta come invariati. Il report SITUAS 129 (§ 4.2) elenca con data precisa quali comuni sono coinvolti da AQ/CE — utile per segnalarli — ma non fornisce (né potrebbe, essendo un cambio di perimetro e non di codice) un modo per correggere numericamente la popolazione spostata. L'errore resta locale e generalmente piccolo, ma silenzioso.

7.2 Riorganizzazione delle sezioni 2011 → 2021 quanto sono confrontabili gli ID

Misure su due regioni intere (dati e geometrie ufficiali, esclusi i codici …8888888):

Letture:

• L'ID è stabile per la grande maggioranza della popolazione. Il 2021 ha molte più sezioni, ma quelle nuove sono in media dieci volte più piccole: sono soprattutto sottodivisioni e sezioni poco o non abitate.
• E l'ID identifica davvero lo stesso posto. Confrontando i centroidi delle sezioni con ID uguale (geometrie topojson 2011 vs 2021): distanza mediana 8 m, p90 85 m in TAA; il 91 % si sposta di meno di un quarto del lato equivalente della sezione. Non è coincidenza di numerazione: è continuità reale.
• Ma la geometria cambia comunque, spesso. Sul rapporto tra area 2021 e area 2011 a ID uguale (Valle d'Aosta): mediana 1,000, però solo il 44,8 % delle sezioni resta entro ±1 %; il 24 % perde oltre il 10 % di superficie, il 20 % ne guadagna oltre l'1 %. Cioè: quando una sezione 2011 viene divisa, una delle figlie eredita il numero e le altre ricevono ID nuovi. Il confronto per ID su quella sezione registra un calo che è puro artefatto, bilanciato da una «sezione nuova» accanto che appare come crescita da zero.

Questo è precisamente il motivo per cui il tema per sezioni deve essere letto aggregato: dentro una cella di 50 px la sezione madre e le sue figlie tornano nella stessa somma e l'artefatto si elide (§ 5). Il confronto per sezioni non aggregato (massimo zoom, aggregationscale → 0) è attendibile solo dove la sezione non è stata toccata.

7.3 Perché a livello di sezione la mappa non rimappa i comuni fusi ed è corretto

La domanda ovvia è: perché applicare la rimappatura delle fusioni solo ai comuni e non anche al prefisso degli ID di sezione? L'ho verificato in Trentino–Alto Adige (76 comuni 2011 spariti per fusione, 69.540 ab., il 6,8 % della regione):

• rimappando il prefisso, 697 su 714 sezioni 2011 trovano un ID esistente nel 2021 — sembra funzionare;
• ma confrontando i centroidi, quell'aggancio è spazialmente sbagliato nella maggioranza dei casi: spostamento mediano 1,49 lati di sezione; solo il 41,9 % entro un quarto di lato; il 29,7 % oltre 5 lati di distanza.

Il motivo è che nel comune nato dalla fusione la numerazione delle sezioni riparte: la vecchia sezione 12 del comune A e la vecchia sezione 12 del comune B non possono essere entrambe la sezione 12 del comune fuso. L'ID esiste, ma indica un altro pezzo di territorio. Rimappare il prefisso a livello di sezione produrrebbe falsi accoppiamenti silenziosi: la scelta della mappa (lasciare gli ID intatti, far sopravvivere entrambi i lati con il padding e lasciare che l'aggregazione spaziale li ricomponga) è la più difendibile delle tre opzioni.

Il corollario, verificato nel codice, è che entrambe le basi territoriali (2011 e 2021) vengono caricate nello stesso gruppo di layer sezioni_censimento (__georef_sez2011(), __georef_sez2021()): così il posizionamento per position: "SEZ2011.1" può risolvere anche gli ID esistenti in una sola delle due annate — le sezioni scomparse sui poligoni 2011, quelle nuove sui poligoni 2021. (Questa è la lettura funzionale del perché entrambi i layer siano necessari; il meccanismo di risoluzione dell'id all'interno del gruppo non è documentato nell'API.)

8 Riepilogo problema → contromisura → residuo

9 Fonti dei dati

Sorgenti usate dalla mappa:

https://s3.eu-west-1.amazonaws.com/data.ixmaps.com/ISTAT/Censimenti/2011/all_indicatori_2011_procom.csv.gz
https://s3.eu-west-1.amazonaws.com/data.ixmaps.com/ISTAT/Censimenti/2021/all_indicatori_2021_procom.csv.gz
https://s3.eu-west-1.amazonaws.com/data.ixmaps.com/ISTAT/Censimenti/{anno}/R{NN}_indicatori_{anno}_sezioni.csv.gz
https://s3.eu-central-1.amazonaws.com/maps.ixmaps.com/Istat/basi_territoriali_{2011,2021}/R{NN}_{11,21}_P.topojson.gz
https://cdn.jsdelivr.net/gh/gjrichter/ixmaps-data@main/by-project/censimenti-2011-2021/situas_codes.json

I numeri di § 7.1 e § 7.2 sono ricalcolati scaricando queste stesse tabelle e applicando la stessa logica di rimappaggio e aggregazione descritta in § 4.

Il registro ISTAT SITUAS (report 129, tutta la serie storica dal 1991) elenca, oltre agli eventi AP usati in § 4.2, le altre categorie di variazione amministrativa: AQ 197, CE 197, CS 342, ES 348, CD 50, RN 222 comuni coinvolti. Queste categorie non sono usate dal codice attuale (report 99 le risolve internamente per AP+CS+ES, § 4.1); i conteggi AQ/CE sono citati in § 7.1 e § 8 per quantificare il residuo non gestito dal metodo.

10 In una frase

La mappa confronta i due censimenti allineando i codici comunali contro uno snapshot statico del registro ISTAT SITUAS (province, fusioni e incorporazioni risolte in un solo lookup, rigenerato periodicamente, § 4.1) al livello dei comuni, e rinunciando deliberatamente ad allineare le sezioni, affidandosi invece a un outer join per ID di sezione e all'aggregazione spaziale che precede il calcolo del delta: poiché si somma prima e si divide dopo, la riorganizzazione delle sezioni si annulla dentro l'unità di aggregazione. È un metodo solido — 0 % di popolazione fuori confronto a livello comunale (§ 7.1), residuano solo i 2 comuni nati da porzioni di territorio (Mappano, Misiliscemi), strutturalmente irrisolvibili con una tabella di codici — i cui limiti restanti sono circoscritti e noti: le variazioni di perimetro AQ/CE ignorate (nessun metodo di codici può correggerle), e l'asimmetria del filtro like "*" sulle sezioni comparse/scomparse.