This page is the technical reference for the DeepPVMapper registry: one record per detected rooftop photovoltaic installation across metropolitan France, each carrying a footprint polygon and a set of derived characteristics. It's meant for anyone integrating the data programmatically — the interactive map on the Data page exposes the same schema described here through its CSV and GeoJSON exports, and the full registry is published on Zenodo and mirrored on Hugging Face (see Access the data).
For how the detections themselves are produced — the deep learning pipeline, imagery sources, and characterization models — see the Pipeline page. For how the different source datasets (AI detections, OpenStreetMap, registries) are combined into one registry, see OpenPVMapper.
The canonical geometry format is GeoJSON (RFC 7946),
the same format used for a custom-area export from the map. Coordinates are longitude, latitude
(in that order, per the GeoJSON spec) in WGS 84 / EPSG:4326 — no
projection or reprojection is needed to use them directly in a GIS tool, geopandas,
or a web map. Each installation's footprint is a Polygon or MultiPolygon.
Two export shapes are available from the map for a custom selection:
Feature per installation, with the real
footprint geometry and the full attribute table below in properties.lat, lng columns) plus the same attributes, for tools that
don't need the polygon shape.The full registry release (Zenodo / Hugging Face) ships as a single GeoJSON file with the same schema.
| Field | Type | Description |
|---|---|---|
| array_id | string | Stable identifier for the installation (e.g. "1024.0"). Distinct from the row's internal database id — this is the id to key off of across releases. |
| surface | float (m²) | Footprint area of the detected array. |
| kwp | float (kWp) | Estimated installed capacity (DC), derived from the footprint and panel characteristics. |
| tilt | integer (°) | Estimated panel tilt from horizontal (0° = flat roof-mounted, increasing towards vertical). |
| azimuth | integer (°) | Estimated panel orientation, clockwise from true north (0–360°) — the standard solar-industry convention. See the Pipeline page for how this is estimated. |
| first_seen | integer (year) | Earliest imagery vintage in which this installation was detected. |
| last_seen | integer (year) | Most recent imagery vintage in which it was detected. Used as the "year" filter on the map. |
| n_vintages | number | Number of distinct imagery vintages this installation was independently detected in, between first_seen and last_seen — a rough stability/confidence signal (an installation seen in every available vintage is on firmer ground than one seen once). |
| sources | string | Comma-separated list of source indices contributing to this record (e.g. "0,1"). See Source encoding below. |
| frpv_proba | float [0–1], nullable | Match probability against the FRPV reference source (see Source encoding) used in the Registry Audit, where a comparison was attempted. Null when no comparison was made (e.g. no candidate nearby). |
| false_positive | boolean, nullable | Set when this record has been flagged (by review or community annotation) as not a real installation. The map hides these by default. Null/absent means "not flagged" — not the same as a confirmed true positive. |
| false_positive_source | string, nullable | Who/what flagged it (e.g. a reviewer pass vs. a community submission), when false_positive is set. |
| insee | string | INSEE commune code the installation falls in. |
| dpt | string | Two-character département code ("2A"/"2B" for Corse). |
| rnb_id | string, nullable | Building identifier in the French Référentiel National des Bâtiments (RNB), when a confident building-level match was found — useful for joining against other RNB-referenced datasets. |
surface, kwp, tilt,
azimuth, and frpv_proba are model outputs, not ground truth — treat
them as estimates with the error characteristics described on the Registry Audit
page, not as surveyed or self-reported values.
sources is a comma-separated list of indices, since a single installation can be
corroborated by more than one source (e.g. an AI detection later confirmed by an OpenStreetMap
contribution). The indices map as follows:
| Index | Source | Description |
|---|---|---|
| 0 | DPVM | DeepPVMapper's own aerial-imagery detection pipeline. |
| 1 | FRPV | Matched against the FRPV reference dataset — see the Registry Audit page for the comparison methodology and how it relates to the public RNI registry. |
| 2 | OSM | Contributed via OpenStreetMap (see Interoperability below for the relevant OSM tagging conventions). |
| 3 | Manual correction | A manual correction submitted through the map's annotation tools. |
| 4 | Recall sample | Added from a recall-annotation sample — installations the automated pipeline initially missed, recovered through targeted review. |
STAC (SpatioTemporal Asset Catalog) is a widely-used specification for cataloging Earth observation data — its core unit, a STAC Item, is a GeoJSON Feature with a datetime and a set of linked Assets (imagery tiles, point clouds, and similar), organized under Catalogs/Collections. It's built to be broad, and isn't limited to raster imagery in principle.
DeepPVMapper does not currently conform to STAC, and that's a deliberate choice
rather than an oversight: this registry is a flat collection of 1.1M+ vector building-footprint
annotations, not a modest set of scene/asset items each pointing at external files with a
well-defined temporal extent. Forcing every installation (or even every département-level extract)
into a STAC Item/Asset/Catalog hierarchy would add real modeling overhead without buying much for
the people actually using this data — who overwhelmingly want it as plain vector features
with attributes, which is exactly what GeoJSON already gives them, natively readable by QGIS,
geopandas, PostGIS, and any modern GIS stack without any STAC awareness at all.
If cross-catalog discoverability (showing up in STAC-aware EO catalogs/browsers) becomes valuable later, a lightweight middle ground exists: wrapping the whole released file as a single STAC Collection + Item (one Asset = the GeoJSON download), without restructuring the underlying data at all. That's a cheap, optional addition on top of the current format — not a prerequisite for using the data today.
The OSM-sourced subset (sources index 2) is built from OpenStreetMap
contributions tagged along conventional lines. For readers comparing our schema against the OSM
tagging scheme directly:
azimuth field, though roof direction and panel azimuth aren't always the same thing (panels aren't always roof-aligned).See the Zenodo record (linked from Access the data on the Data page) for the dataset's license and the citation to use when referencing it in academic work. The DeepPVMapper codebase itself is MIT-licensed (see the footer below).