Una stima nazionale credibile non può nascere da una superficie media moltiplicata per il numero di immobili. Il modello Heiwit usa un frame geolocalizzato, un campione stratificato e stime solari riferite ai singoli elementi. Proprio per questo i passaggi non ancora replicabili devono essere dichiarati.
Il capitolo in 8 slide
Scorri il carosello originale realizzato per questo capitolo. Le immagini sono state ottimizzate per il web e caricate nella Libreria media di WordPress.
Su smartphone scorri lateralmente. Da tastiera usa le frecce destra e sinistra.
1. Il frame OpenStreetMap
L’universo di partenza è stato estratto da OpenStreetMap tramite Overpass API usando tag funzionali riconducibili a scuole, ospedali, municipi e altri servizi pubblici. L’attribuzione corretta è: © OpenStreetMap contributors, dati disponibili secondo ODbL 1.0, estrazione dichiarata aprile 2026.
Il termine «frame» è importante. Un elemento OSM non dimostra la proprietà pubblica e può rappresentare un punto, un edificio, un perimetro o una relazione. Scuole private, cliniche e strutture convenzionate possono rientrare nei tag funzionali. La query Overpass, le regole di deduplicazione e il mapping POI-edificio dovranno quindi essere pubblicati.
2. Il campione stratificato
Per contenere i costi delle interrogazioni, lo studio dichiara un campione di 10.000 elementi, pari al 24,2% del frame. Il campione è diviso in 20 strati ottenuti incrociando cinque macroaree e quattro tipologie funzionali. Il totale nazionale è stimato con il classico estimatore stratificato, moltiplicando la media di ogni strato per la numerosità dello strato nell’universo.
I materiali riportano però 9.318 record con dato valido. I 682 mancanti devono essere classificati: fallimenti API, duplicati, elementi non associabili a un tetto o altre esclusioni. Senza questa classificazione non si può escludere un bias di non risposta.
3. Google Solar API e PVGIS
Per gli elementi campionati è stato dichiarato l’uso dell’endpoint Building Insights della Google Solar API. L’attribuzione da mantenere vicino ai risultati è: «Fonte: include dati solari di Google. Elaborazioni aggregate Heiwit S.p.A.; Google non è autore né validatore dello studio».
La procedura definitiva dovrà documentare qualità richiesta e restituita, data delle immagini, capacità dei pannelli usata dal servizio, distanza tra coordinata richiesta ed edificio individuato e controlli sui campus multi-edificio.
Per gli elementi trattati con PVGIS devono essere pubblicate le ipotesi di superficie, coefficiente di utilizzo del tetto, orientamento e perdite. Attribuzione: PVGIS © European Union / European Commission, Joint Research Centre (JRC), versione 5.2; elaborazioni Heiwit S.p.A. I risultati non rappresentano necessariamente la posizione della Commissione europea.
4. Bootstrap e intervalli di confidenza
Lo studio dichiara un bootstrap non parametrico da 1.000 iterazioni. Anche qualora il calcolo fosse corretto, l’intervallo rappresenterebbe l’incertezza campionaria condizionata al frame e al modello. Non comprende errori di classificazione OSM, associazione al tetto, copertura delle immagini, fallback, dati mancanti o assunzioni economiche.
5. Confronto con GSE Atlaimpianti
È stato dichiarato un matching entro 80 metri con Atlaimpianti. Il confronto può essere utile, ma una distanza inferiore a 80 metri non dimostra che l’impianto appartenga all’edificio. Servono distribuzione delle distanze, controlli manuali, falsi positivi e outlier. Inoltre Atlaimpianti è un ampio insieme di impianti gestiti o incentivati dal GSE, non il censimento completo del fotovoltaico italiano.
Cosa manca per la piena replica
- query Overpass e regole di deduplicazione;
- dataset dei 10.000 record e lista dei 9.318 validi;
- log Google/PVGIS e motivi di esclusione;
- codice di campionamento, espansione e bootstrap;
- file del matching Atlaimpianti e controlli manuali;
- dataset regionale e modello economico.








