Open Data and Open Source for Rooftop Solar Community Estimation on the Fly: The Case of Spain

How to make a fast estimation of rooftop helio potential using available open data and open software.

The emergence of more comprehensive and higher quality data brings a variety of new opportunities for approaching the preliminary research on local community photovoltaic (PV) potential. This post demonstrates simple steps on how to make a fast but empirical estimation of rooftop potential on the fly using available open data (LiDAR files) and open software (QGIS + plugins), resulting in evidence-based results for a prefeasibility study on PV rooftop potential for neighborhood.

AI generated image

It is worth noting that advancements in open-source software and data availability have the potential to bridge the gap between detailed and simplified models, catering to users who are willing to explore the nuances in just a bit more details. While scholars have made significant contributions in this field, this post focuses on specific steps within a framework that can be valuable for evaluating rooftop potential.

It can be seen as simple step towards more advanced and efficient methods compared to manual analysis or generalized assumptions in terms of estimating the useful area of local community rooftops for solar technology installation and exploring potential trade-off scenarios. However, it should be noted that it falls short of comprehensive LiDAR studies and advanced ML and AI automated approaches.

The beginning

The example of Spain has a digital geographic information repository (Fig. 1), which, among other data, holds LiDAR data in various resolutions, covering a remarkably high percentage of the populated territory. In our case, we conducted a search by municipality and uploaded the available LiDAR cloud file (*.laz) of the selected territory with a specified resolution of 2 points/m².

Fig 1 . Repository of Geoinformation data of Spain (https://centrodedescargas.cnig.es)

Following that, we will use the following plugins:

1. QuickOSM — to export building footprints.
2. WhiteBox Tool — for cloud point processing, DEM (Digital Elevation Model) and DSM (Digital Surface Model) creation, and rooftop analysis.
3. Terrain Shading — providing extra features of ambient occlusion.

Cloud Point Processing

Having the cloud point file, we export it to QGIS through Layer > Add Point Cloud Layer. For the case of Spain, the proper coordinate system in QGIS is IGNF: ETRS89UTM30 — ETRS89 UTM Nord fuseau 30.

Important: It may happen that QGIS won’t render the *.laz file, even if the coordinate reference system is correctly inserted. A simple solution for that is to open the *.laz file in any other free program for LiDAR cloud points (such as CloudCompare or even in Whitebox Tools > LIDAR Tools > LazToLas) and save it to *.las format. After that, importing the *.las file (which is an uncompressed .laz file) to QGIS should render without a problem.

Using the Whitebox plugin (here are the steps to install plugin and resolution on possible error of dependencies) we will create the DSM selecting Processing Toolbox > WhiteboxTools > LIDAR Tools > LidarDigitalSurfaceModel. The Input file is our *.las file.

After receiving the output DSM, we can generate a hillshade file in QGIS on the fly by going to Symbology > Render type and selecting the ‘Hillshade’ option.

Additionally, with the help of the ‘Terrain Shading’ plugin, we can generate a representation of our territory’s DSM file with ambient occlusion mode by selecting Processing Toolbox > Terrain Shading > Ambient occlusion (skyview). This will give us Step 1 as shown in Figure 2.

Fig 2. Overall steps stages to the rooftop analysis

And the “cherry on top” is that by following WhiteboxTools > LidarTools > LidarRooftopAnalysis with the *.las file and the building footprint layer ( here exported from OSM using the QuickOSM plugin) as inputs, we can identify roof segments in a LiDAR point cloud only for our specific layer of buildings’ footprint.

It provides basic justified information on local building stock parameters, such as: slope of roofs, orientation ( ASPECT — azimuth angle in degrees), available useful rooftop area in m2, as it’s presented in Fig 3.

Fig 3. Demonstration example of results on the fly

Conclusions and Warnings

• All the plugins’ algorithms were executed with their respective reference parameters.
• The identification of rooftop constraints, such as ventilation tubes, HVAC (Heating, Ventilation & Air Conditioning) elements, or other rooftop constructions, is often limited and depends on the initial resolution of the cloud point file.
• Rooftop shapes are often identified with fuzzy borders and errors.
• The approach provides a significantly more justified data output for a semi-automatic feasibility trade-off study related to scenarios of different building use-purpose typologies.