Solar wizard PV model

The rooftop solar PV suitability model backing solarwizard.org.uk.

The model is documented at documents/pv_model.md.

Dependencies and setup

The main entrypoint of the model is the function model_solar_pv in module solar_pv.model_solar_pv. The docstring for that function has documentation for how to use it and the meaning of each parameter.

Results are inserted into 2 postgres tables:

• models.pv_building contains LiDAR-derived building height, and a reason (if any) why the building has been skipped in PV modelling, which can be one of 4 things: NO_LIDAR_COVERAGE, OUTDATED_LIDAR_COVERAGE, NO_ROOF_PLANES_DETECTED, or ALL_ROOF_PLANES_UNUSABLE.
• models.pv_roof_plane contains the slope and aspect of the roof plane, per-modelled-panel monthly and yearly predicted kWh, and a horizon profile. A building can have 0 to many of these.

The model has the following software dependencies:

• various python libraries (see requirements.txt, can also be installed using nix - see default.nix)
• postgreSQL and postGIS
• PVMAPS (a GRASS GIS plugin written in C) - this can be installed using default.nix using nix

The model has the following data dependencies:

• building footprint geometries
• LiDAR elevation rasters
• irradiation raster data, which can be downloaded from the PVMAPS link above, or from https://re.jrc.ec.europa.eu/pvmaps/pvgis_data.tar. The tar file should be placed in the directory referenced by the environment variable PVGIS_DATA_TAR_FILE_DIR.

We have tried to make the model as independent as possible from our internal infrastructure where it runs, but this has not been our main priority when developing and you may find things that don't work, or design decisions that don't make sense when viewed without the context of knowing how we run the model.

postgres and postGIS

You will need a postGIS (postgres version >= 12; postGIS version >=3) database with some data in it (see below).

The postGIS install will also need to have access to some proj datum grids, which are used for more accurate transformations between long/lat and easting/northing.

To test your postGIS install, try the following:

SELECT  ST_AsText(
            ST_Transform(
                'POINT(-3.55128349240 51.40078220140)',
                '+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs',
                '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +nadgrids=@OSTN15_NTv2_OSGBtoETRS.gsb +units=m +no_defs'
            )
        )
;
                st_astext                 
------------------------------------------
 POINT(292184.870542716 168003.465539408)     -- Test point: 292184.870 168003.465

(test source: https://gis.stackexchange.com/a/396980)

If the proj being used by postGIS doesn't have the datum grids, the result will be way off. It will only be correct if the file OSTN15_NTv2_OSGBtoETRS.gsb is in the directory indicated by the environment variable PROJ_LIB (or its default location of /usr/share/proj or /usr/local/share/proj, depending on distro, if PROJ_LIB is unset). If your proj version is < 7, this file is found in the project proj-datumgrid. If it is >=7, it is found in the project proj-data. Run SELECT PostGIS_PROJ_Version(); To get the proj version.

The postGIS in some distro package managers (e.g. debian-based ones) do include the datum grids by default; however the nixpkgs postGIS does not.

There will need to be at least the following table in the postGIS install:

• schema: mastermap
• table: building_27700
• columns: toid TEXT, geom_27700 geometry(Polygon,27700). It can have others but these are the only ones required.

Optionally, this table will also be used if present. It is only used to burn in buildings missing from the LiDAR as obstacles to be used when detecting the horizon profiles of present buildings.

• schema: mastermap
• table: height
• columns: toid TEXT, abs_hmax, abs_h2. It can have others but these are the only ones required.

We use the unique building ID (TOID) and building footprint geometry from OS mastermap (hence the table names) - however this is not necessarily required: as long as the polygons align properly with the LiDAR used, any building geometry and height data could be used. TOIDs are open-licensed data but height and geometry are not.

LiDAR

The model can use LiDAR in geoTIFF format at resolutions 50cm, 1m or 2m. 1m is ideal as 2m is too low-resolution to pick up many features and 50cm increases the time taken to fit planes to LiDAR. The model expects LiDAR tiles to be pre-loaded as out-of-band rasters into postGIS in the tables models.lidar_50cm, models.lidar_1m, and models.lidar_2m.

Two Python modules are included which perform this task in different ways - see solar_pv.lidar.bulk_lidar_client and solar_pv.lidar.defra_lidar_api_client, but as long as the LiDAR ends up in the right tables any other method is fine too.

Environment variables

Required variables:

• PVGIS_DATA_TAR_FILE_DIR - The directory containing the pvgis_data.tar file
• PVGIS_GRASS_DBASE_DIR - where to create the GRASS dbase for PVMAPS

Optional variables:

• BULK_LIDAR_DIR - This can be ignored unless using solar_pv.lidar.bulk_lidar_client to load LiDAR. This is the directory containing bulk LiDAR for England, Scotland and Wales. This should have the following directory structure:
  • 206817_LIDAR_Comp_DSM
    • LIDAR-DSM-50CM-ENGLAND-EA
    • LIDAR-DSM-1M-ENGLAND-EA
    • LIDAR-DSM-2M-ENGLAND-EA
  • scotland
  • wales

Tests

Some of the tests require the PVMAPS irradiation data.

• Download the 10GB tar file from https://re.jrc.ec.europa.eu/pvmaps/pvgis_data.tar and either place it at, or symlink to it from, test_data/pvmaps/pvgis_data_dir/pvgis_data.tar
• run python3 -m unittest