Cette page est la référence technique du registre DeepPVMapper : un enregistrement par installation photovoltaïque en toiture détectée en France métropolitaine, chacun portant un polygone d'emprise et un ensemble de caractéristiques dérivées. Elle s'adresse à celles et ceux qui intègrent les données par programme — la carte interactive de la page Données expose le même schéma que celui décrit ici via ses exports CSV et GeoJSON, et le registre complet est publié sur Zenodo et reproduit sur Hugging Face (voir Accéder aux données).
Pour savoir comment les détections elles-mêmes sont produites — le pipeline de deep learning, les sources d'imagerie et les modèles de caractérisation — voir la page Pipeline. Pour savoir comment les différents jeux de données sources (détections par IA, OpenStreetMap, registres) sont combinés en un seul registre, voir OpenPVMapper.
Le format de géométrie de référence est GeoJSON (RFC 7946),
le même que celui d'un export de zone personnalisée depuis la carte. Les coordonnées sont données en
longitude, latitude (dans cet ordre, selon la spécification GeoJSON) en WGS 84 / EPSG:4326
— aucune projection ni reprojection n'est nécessaire pour les utiliser directement dans un outil SIG,
geopandas ou une carte web. L'emprise de chaque installation est un Polygon
ou un MultiPolygon.
Deux formes d'export sont disponibles depuis la carte pour une sélection personnalisée :
Feature par installation, avec la géométrie réelle
de l'emprise et la table complète d'attributs ci-dessous dans properties.lat, lng) et les mêmes attributs, pour les outils qui n'ont pas
besoin de la forme du polygone.La publication complète du registre (Zenodo / Hugging Face) est fournie sous la forme d'un seul fichier GeoJSON, avec le même schéma.
| Champ | Type | Description |
|---|---|---|
| array_id | chaîne | Identifiant stable de l'installation (par ex. "1024.0"). Distinct de l'identifiant interne de la ligne en base — c'est l'identifiant à utiliser comme clé d'une version à l'autre. |
| surface | flottant (m²) | Surface d'emprise du champ détecté. |
| kwp | flottant (kWc) | Puissance installée estimée (DC), déduite de l'emprise et des caractéristiques des panneaux. |
| tilt | entier (°) | Inclinaison estimée des panneaux par rapport à l'horizontale (0° = posés à plat sur le toit, croissant vers la verticale). |
| azimuth | entier (°) | Orientation estimée des panneaux, dans le sens horaire à partir du nord géographique (0–360°) — la convention standard de l'industrie solaire. Voir la page Pipeline pour son estimation. |
| first_seen | entier (année) | Millésime d'imagerie le plus ancien dans lequel cette installation a été détectée. |
| last_seen | entier (année) | Millésime d'imagerie le plus récent dans lequel elle a été détectée. Utilisé pour le filtre « année » de la carte. |
| n_vintages | nombre | Nombre de millésimes d'imagerie distincts dans lesquels cette installation a été détectée indépendamment, entre first_seen et last_seen — un indicateur approximatif de stabilité/confiance (une installation vue dans tous les millésimes disponibles est plus solide qu'une vue une seule fois). |
| sources | chaîne | Liste, séparée par des virgules, des indices de sources contribuant à cet enregistrement (par ex. "0,1"). Voir Codage des sources ci-dessous. |
| frpv_proba | flottant [0–1], nullable | Probabilité de correspondance avec la source de référence FRPV (voir Codage des sources) utilisée dans l'audit des registres, lorsqu'une comparaison a été tentée. Nulle quand aucune comparaison n'a eu lieu (par ex. aucun candidat à proximité). |
| false_positive | booléen, nullable | Renseigné lorsque cet enregistrement a été signalé (par relecture ou annotation communautaire) comme n'étant pas une vraie installation. La carte les masque par défaut. Nul/absent signifie « non signalé » — ce qui n'équivaut pas à un vrai positif confirmé. |
| false_positive_source | chaîne, nullable | Qui/quoi l'a signalé (par ex. une passe de relecture ou une contribution communautaire), lorsque false_positive est renseigné. |
| insee | chaîne | Code INSEE de la commune où se trouve l'installation. |
| dpt | chaîne | Code du département sur deux caractères ("2A"/"2B" pour la Corse). |
| rnb_id | chaîne, nullable | Identifiant du bâtiment dans le Référentiel National des Bâtiments (RNB), lorsqu'un rapprochement fiable au niveau du bâtiment a été trouvé — utile pour croiser avec d'autres jeux de données référencés RNB. |
surface, kwp, tilt,
azimuth et frpv_proba sont des sorties de modèles, pas des vérités terrain —
considérez-les comme des estimations, avec les caractéristiques d'erreur décrites sur la page
audit des registres, et non comme des valeurs mesurées ou déclarées.
sources est une liste d'indices séparés par des virgules, car une même installation peut
être corroborée par plusieurs sources (par ex. une détection par IA confirmée ensuite par une
contribution OpenStreetMap). Les indices correspondent à :
| Indice | Source | Description |
|---|---|---|
| 0 | DPVM | Le pipeline de détection sur imagerie aérienne de DeepPVMapper lui-même. |
| 1 | FRPV | Rapprochée du jeu de référence FRPV — voir la page audit des registres pour la méthodologie de comparaison et son lien avec le registre public RNI. |
| 2 | OSM | Apportée via OpenStreetMap (voir Interopérabilité ci-dessous pour les conventions d'étiquetage OSM concernées). |
| 3 | Correction manuelle | Une correction manuelle soumise via les outils d'annotation de la carte. |
| 4 | Échantillon de rappel | Ajoutée à partir d'un échantillon d'annotation du rappel — installations initialement manquées par le pipeline automatique, retrouvées par une relecture ciblée. |
STAC (SpatioTemporal Asset Catalog) est une spécification très répandue pour cataloguer des données d'observation de la Terre — son unité de base, l'Item STAC, est une Feature GeoJSON dotée d'une date et d'un ensemble d'Assets liés (tuiles d'imagerie, nuages de points, etc.), organisés en Catalogs/Collections. Elle est conçue pour être large et, en principe, ne se limite pas à l'imagerie raster.
DeepPVMapper n'est actuellement pas conforme à STAC, et c'est un choix délibéré,
non un oubli : ce registre est une collection plate de plus de 1,1 M d'annotations vectorielles
d'emprises de bâtiments, et non un ensemble modeste d'items scène/asset pointant chacun vers des
fichiers externes avec une étendue temporelle bien définie. Forcer chaque installation (voire chaque
extrait départemental) dans une hiérarchie STAC Item/Asset/Catalog ajouterait une vraie charge de
modélisation sans apporter grand-chose à celles et ceux qui utilisent réellement ces données — qui
les veulent en immense majorité comme de simples entités vectorielles avec attributs, ce que GeoJSON
leur donne déjà, lisible nativement par QGIS, geopandas, PostGIS et toute pile SIG
moderne sans aucune connaissance de STAC.
Si la découvrabilité entre catalogues (apparaître dans les catalogues/navigateurs EO compatibles STAC) devient utile plus tard, il existe un compromis léger : envelopper l'ensemble du fichier publié dans une seule Collection + un seul Item STAC (un Asset = le téléchargement GeoJSON), sans restructurer les données elles-mêmes. C'est un ajout peu coûteux et facultatif par-dessus le format actuel — pas un prérequis pour utiliser les données aujourd'hui.
Le sous-ensemble issu d'OSM (indice 2 de sources) est construit à partir de
contributions OpenStreetMap étiquetées selon les conventions usuelles. Pour celles et ceux qui
comparent notre schéma directement au schéma d'étiquetage OSM :
azimuth, même si la direction du toit et l'azimut des panneaux ne sont pas toujours la même chose (les panneaux ne sont pas toujours alignés sur le toit).Voir la notice Zenodo (accessible depuis Accéder aux données sur la page Données) pour la licence du jeu de données et la citation à utiliser dans un travail académique. Le code de DeepPVMapper lui-même est sous licence MIT (voir le pied de page ci-dessous).