A Point-Cloud Solar Radiation Tool

Abstract

Current software solutions for solar-radiation modeling in 3D focus on the urban environment. Most of the published tools do not implement methods to consider complex objects, such as urban greenery in their models or they expect a rather complex 3D mesh to represent such objects. Their use in an environment that is difficult to represent geometrically, such as vegetation-covered areas, is rather limited. In this paper, we present a newly developed solar-radiation tool focused on solar-radiation modeling in areas with complex objects, such as vegetation. The tool uses voxel representations of space based on point-cloud data to calculate the illumination and ESRA solar-radiation model to estimate the direct, diffuse, and global irradiation in a specified time range. We demonstrate the capabilities of this tool on a forested mountain area of Suchá valley in the Hight Tatra mountains (Slovakia) and also in the urban environment of Castle Hill in Bratislava (Slovakia) with urban greenery. We compare the tool with the r.sun module of GRASS GIS and the Area Solar Radiation tool of ArcGIS using point-cloud data generated from the digital-terrain model of Kamenistá valley in High Tatra mountains in Slovakia. The results suggest a higher detail of the model in rugged terrain and comparable results on smooth surfaces when considering its purpose as a 3D modeling tool. The performance is tested using different hardware and input data. The processing times are less than 8 min, and 8 GB of memory is used with 4 to 16 core processors and point clouds larger than 100,000 points. The tool is, therefore, easily usable on common computers.

1. Introduction

Solar radiation, as a renewable energy source and a relevant factor in various natural phenomena, is a variable worth modeling. Solar-radiation data have many applications in various fields, including photovoltaics [1,2,3], urban planning [4,5,6,7], climatology [8,9], biology [10,11,12], and environmental sciences [13,14,15]. The modeling of solar radiation is based on clear-sky irradiance models that are combined with cloudiness data, which are often obtained from satellite measurements [16]. Clear-sky models simulate the atmospheric attenuation of solar radiation under cloudless skies. They usually distinguish between direct and diffuse components of solar radiation.

Clear-sky models vary in the number of input parameters and precision depending on the method of atmospheric attenuation modeling and the geographic location of their application [16]. Some of the well-known and best-performing clear-sky models, according to studies focused on their comparison [16,17,18,19], include the REST2 [20], SOLIS [21], McClear [22], and ESRA [23] models. Clear-sky models require the geometric parameters of the modeled surface and the corresponding relative position of the Sun in addition to the current atmospheric parameters [24]. Information on surface illumination is also required.

Current solar-radiation modeling methods are implemented within software tools or applications. They are available as standalone tools [6,7,25] or integrated within geographic information systems (GIS) [26,27]. Solar-radiation maps and databases [28], such as the Global Solar Atlas [29], PVGIS [30], and SoDa [31], focus on providing data on a global scale.

They provide modeled solar-radiation data with high temporal resolution and accurate atmospheric and cloudiness models; however, the spatial resolution of the data is low. Well-known GIS tools, such as the GRASS GIS r.sun module [26,32] and the Area Solar Radiation tool [27,33] implemented in ArcGIS, let the user specify the atmospheric parameters, time range, and time step for the location. Both solar-radiation maps and GIS tools use digital elevation models (DEMs) and are, therefore, limited in their representation of 3D landscape features.

To increase the vertical detail of solar-radiation models mainly in urban areas, standalone tools and applications, such as SORAM [7], SURFSUN3D [25], and Solar3D [6] have been developed. They combine DEMs with 3D building meshes or, in some cases, point-cloud data and other spatial data. The method used in SORAM [7] implements ray tracing to determine the illumination of the 3D mesh and adopts the solar-radiation model from [34].

It can be used to obtain solar-radiation estimates for predefined points on the 3D mesh. SURFSUN3D [25] also uses ray tracing to calculate the illumination and then uses the r.sun module to assess the solar radiation amounts in individual planes of the 3D mesh. Solar-radiation data can be obtained both at predefined points and on planes but only in small areas. The method presented in [35] uses a combined approach in which a 3D mesh is used to model buildings, a DEM is used to model terrain, and a point cloud is used to model vegetation.

The 3D tool v.sun described in [36] modifies r.sun’s approach to be used with 3D mesh data in combination with voxel-based illumination computation. The v.sun tool is focused on urban areas and has not yet been published within GRASS GIS. A method focused on urban greenery presented in [37] uses the 3D tree mesh and the Shadow Analysis [38] software extension of SketchUp to calculate the illumination; however, it does not allow the modeling of solar radiation.

Solar3D is one of the most recently published tools [6] focused on local 3D modeling. It combines multiple types of spatial data, such as 3D city models, DEMs, and GIS vector layers, to calculate solar radiation with the r.sun module. Solar 3D can be used to obtain solar-radiation data using its graphical user interface by clicking on specific points.

Light detection and ranging (LiDAR) is one of the most efficient techniques of spatial data collection, the products of which are point-cloud data, which are often used to produce elevation models of the Earth’s surface or 3D models of scanned objects. Point-cloud data are, therefore, often available in many countries as a product of national mapping using airborne laser scanning. These data also capture vegetation and can be used to model solar radiation in vegetation-covered areas. Currently, there are no tools available focused on solar-radiation modeling in a complex environment, such as vegetation-covered areas or urban areas with urban greenery that are capable of modeling solar irradiance in the entire modeling space, including the complex objects themselves.

This work aims to fill the gap through the development of a new solar-radiation modeling tool that is capable of modeling the illumination and solar radiation on point-cloud data in a predefined time or time range; uses a tested clear-sky irradiance model to calculate the direct and diffuse component of the solar irradiance; is suitable for vegetation-covered areas and also urban areas; is computationally efficient and easy to use in terms of input data availability; can be easily integrated within GIS or other software as a plug-in; and uses common file formats that can be processed and visualized by other available software.

In this paper, we describe the illumination and solar-radiation modeling methods used as well as the algorithm of the newly developed tool in Section 2. In Section 3, we present the implementation of the tool, its applications on different types of terrain, its performance on various hardware, and a comparison with the well-known GIS tools for solar-radiation modeling. We discuss the capabilities of the new tool, its further development, and the potential usage in various fields of research in Section 4.

2. Materials and Methods

In this section, we describe the method of illumination modeling on point-cloud data, the method used for solar-radiation modeling, and the algorithm of the newly developed tool.

2.1. Illumination Modeling

To determine the distribution of illuminated points among the point cloud at a given time, we use a voxel representation of the modeled space. The modeled space is divided into voxels with a fixed edge size, creating a regular voxel grid in which only the voxels containing cloud points are considered. The origin of the grid coordinate system is translated to fit the points regardless of the origin of the coordinate system of the point cloud. The method requires a horizontal metric coordinate system of the input point cloud and results in an array of voxels defined by their grid coordinates and the original points of the point cloud that belong to them.

The vector of illumination is defined by the Sun’s azimuth and altitude angles, which are related to the centroid of the point cloud and the current solar time. Voxels that are closest to the Sun in the direction of the Sun’s rays are defined as illuminated, and the rest of them, in line with the illumination vector passing through the top illuminated voxel, are in shadow. To evaluate the state of the voxels computationally, the grid axes are rotated using the azimuth and altitude angles of the Sun in such a way that the vertical axis is parallel to the Sun’s rays and points towards the Sun (Figure 1).

In this way, we obtain the rotated voxel coordinates in the Sun-oriented coordinate system. We define a square shadow grid on the plane defined by the horizontal axes of the rotated coordinate system with a side half the size of the voxel edge. The voxels projected in the same square are grouped together. The one with the highest vertical coordinate is evaluated as illuminated and the rest of them as in shadow.

We have chosen the half size of the sides of the squares in the shadow grid to reflect the voxels being partially in shadow. The accurate calculation of the shadowed section of the voxel is neglected in favor of the computation performance, considering that the voxel grid can always be refined to lower the impact of such simplification.

2.2. Solar Radiation Modeling

To calculate the direct and diffuse components of solar radiation and global solar radiation, we use the ESRA model [23]. The ESRA model expresses the scattering, absorption, and overall attenuation of solar irradiance in the atmosphere with the Linke turbidity factor and the Raylight scattering [23]. The Linke turbidity factor represents the number of clean dry atmospheres that produce the attenuation of solar radiation from the real atmosphere [39]. The effect of Rayleigh scattering is expressed with the relative optical air mass.

Since the relative optical air mass is the ratio between the length of the optical path described by the solar rays and the optical path in the zenith direction [40], it depends on the geometric parameters of the model. The amount of direct solar radiation on inclined surfaces depends on the angle of incidence [24]. The amount of diffuse solar radiation, while assuming the isotropic model of diffuse radiation [41], is affected by the slope of the incident surface.

The voxels do not accurately represent the incidence surface and, therefore, the incident planes need to be constructed based on the cloud points belonging to the voxels or in their vicinity. The minimum number of points to calculate regression planes is the average number of points per voxel and is no less than four points. The four-point minimum is set to prevent the case of constructing a plane from three points belonging to a single voxel and to make the change of orientation of adjacent planes smoother.

If the required points are not contained in the voxel, we search for additional points in adjacent voxels of the grid and check the minimum required points condition. We increase the search distance to a maximum of five layers of surrounding voxels to avoid potentially searching the whole point cloud. Five additional layers suffice in most cases considering a reasonable size of the voxel and sufficient density of the input point cloud. However, if the minimum required points are still not found, the incident plane is considered horizontal. Incident planes are represented by unit normal vectors since only the incident angle and slope are needed in solar radiation calculations.

2.3. Algorithm

The main algorithm of the newly developed point cloud solar-radiation tool (pcsrt) is shown in Figure 2.

The pcsrt function is designed as a command-line tool and starts with reading the input parameters, followed by preprocessing and the main processing of the point cloud. The usage of the tool as well as the description of the input parameters is documented in https://github.com/hblyp/pcsrt (accessed on 2 August 2022).

The input parameters required to run the tool include the path to the input and output file, the elevation and geographic coordinates of the centroid of the modeled site (or another reference point), the time range and time step in which the solar radiation is to be modeled, and the Linke turbidity factor. The pcsrt tool can read LAS or LAZ input files and write text or binary PLY files in addition to the LAS and LAZ output files.

The input and output file formats are specified by the file extension, except for the PLY text format, which can be specified with a special flag. The centroid is used to calculate the solar position for the time steps that fall within the time range. The elevation of the site is also used to calculate the relative optical air mass used in the ESRA model. The Linke turbidity factor can be specified for the whole time range or per month.

The size of the voxel, the desired average points in the voxel, the block processing parameters, and the height of the horizon are optional parameters. The pcsrt function uses the desired average points parameter to estimate the voxel size if it is not specified directly. If neither the desired average points nor the voxel size are specified, the default value of four desired average points in the voxel is used instead. The predefined value of the average points is introduced to make both of these parameters optional.

The block processing parameters include the block size and overlap and are used to process the cloud sequentially in multiple blocks to reduce the memory usage if needed. Omitting the block processing parameters results in processing the cloud in a single block. With the horizon parameter, the elevation mask of the reference point is specified and can be used to simulate surrounding objects that are not included in the point cloud.

In the following pre-processing phase, the voxel size and the average contained points in the voxel are computed in addition to the basic parameters of the point cloud, such as the point count and extent. The size of the voxel, if not specified directly, is calculated under the assumption that the volume of the voxel is linearly dependent on the average point count. This assumption applies only if the points are evenly distributed in the modeled space, and thus we only estimate the voxel size starting with 1 meter and iteratively recalculate the average points until they differ from the desired amount by no more than 0.5 points. This method does not need to be precise since it mainly serves as a helper feature if the density and the distribution of the points is not known.

In the main section of the algorithm, pcsrt iterates over the blocks while computing the extent of the block with and without overlap. The extent with overlap is used to filter the points in the input file, and the extent without overlap is used to filter the points when writing the output file. Block points are used to build the voxel grid as described in Section 2.1. The hashmap data structure with voxel coordinates as keys is used to represent the voxel grid in pursuit of fast voxel access used in the computation of normal vectors or when writing the illumination and irradiation data for the voxels.

The computation of normal vectors is rather heavy since it requires one to search for points in the adjacent voxels if the current voxels do not contain enough points. However, since the adjacent-point search only needs write access for the affected voxel, it can be done in parallel without race conditions. With known incident planes, we can proceed to calculate the illumination and solar radiation components.

During the iterations over the time range with a defined time step, the solar azimuth and altitude are calculated. Time steps after sunset and before sunrise are skipped, as well as time steps with a solar altitude lower than the horizon height at the corresponding azimuth if specified. Individual time steps are processed in parallel. The illumination is computed by applying the rotation matrices calculated using the solar elevation and azimuth angles on the voxel coordinates.

The shadowing grid is represented by another hashmap. The voxels are inserted into the hashmap based on their rotated and doubled coordinates. The hashmap is used as a filter for the voxels in shadow. If the hashmap already contains a voxel with the same coordinates, the voxel with the higher vertical coordinate stays in the hashmap, and the other voxel is considered to be in shadow.

When all voxels have passed through the filter, only the illuminated voxels remain stored in the hashmap. Both direct and diffuse components of the solar irradiance are calculated for the illuminated voxels, and the diffuse component is also calculated for the voxels in shadow using the ESRA model. After the last time step has been processed, the voxel points are written into the output file with their illumination and solar radiation values. The pcsrt tool completes the solar-radiation modeling with the processing of the last block.

3. Results

To evaluate the accuracy and performance of the developed software tool, we test the software on different types of hardware and data representing various landscape features. We also compare the software with the well-known GIS tools for solar-radiation modeling. The modeled point clouds and DEMs presented in this section are visualized using CloudCompare and QGIS. The axis orientations in CloudCompare visualizations are: green north, red east, and blue zenith.

3.1. Implementation

The pcsrt function is implemented in the Rust [42] programming language mainly for its performance, memory-safety, and thread-safety and also because of the convenience of compiling software for different operating systems. In the development of pcsrt, a handful of external packages were used. The las (https://docs.rs/las/0.7.7/las/ accessed on 2 August 2022) and ply-rs (https://fluci.github.io/travis_docs/ply-rs/ply_rs/index.html accessed on 2 August 2022) packages are used for reading and writing LAS and PLY files.

The chrono (https://docs.rs/chrono/0.4.19/chrono/ accessed on 2 August 2022), nalgebra (https://www.nalgebra.org/docs/ accessed on 2 August 2022), and spa (https://docs.rs/spa/0.3.0/spa/ accessed on 2 August 2022) packages are used for time data, linear algebra, and solar-position calculations. We also used other supplementary packages, such as clap (https://docs.rs/clap/3.2.16/clap/ accessed on 2 August 2022) and log (https://docs.rs/log/0.4.17/log/ accessed on 2 August 2022), for parsing command line arguments and logging the state of the computation. The pcsrt source code, as well as the full list of packages used, is published on GitHub (https://github.com/hblyp/pcsrt accessed on 2 August 2022).

3.2. Applications

The main objective of pcsrt is to provide a means of modeling solar irradiation in areas with complex geometry, such as vegetation-covered areas; however, since the pcsrt algorithm is suitable for general point-cloud data, we also demonstrate its use in urban areas. We use point-cloud data provided by the Geodesy, Cartography and Cadastre Authority of the Slovak Republic (GCCA SR/the Slovak abbreviation used to denote the data is ÚGKK SR) [43]. All spatial data are in the JTSK03 (EPSG 8353) coordinate reference system and the Baltic Normal Height System.

As an example of a vegetation-covered area, we use the point cloud of the Suchá valley in the High Tatra Mountains in Slovakia (Figure 3). The valley is oriented in a north–south direction and is predominantly covered by a dense spruce forest. Solar radiation is modeled over a period of one year with an hourly time step and a calculated fit voxel size of 0.7 m for four average points per voxel. The monthly values of the Linke turbidity factor are taken from the SoDa database [31]. They take the values of 2.2, 2.5, 3.0, 3.1, 2.9, 3.9, 3.0, 2.8, 2.6, 2.5, 2.4, and 2.2 from January to December. The point cloud of 28,231,107 points was processed in one block and took 25 min and 54 s using the 16-core AMD Ryzen 9 5950X processor with 48 GB of memory.

The amount of modeled global solar radiation ranges from about 2.5 kWh/m² to 3 MWh/m². The dominant part of the visualized irradiance ranges from approximately 1 MWh/m² to 2 MWh/m². Lower amounts of solar irradiation can be seen below the forest canopy in a detailed view in Figure 4 that shows the annual direct and diffuse components of solar irradiation as well as the illumination hours. Higher amounts of solar irradiation are located on the tree tops and the boundaries of the point cloud since the shadows cast by the objects beyond the boundary are not included in the model.

The detail in Figure 4 also shows the difference in the illumination and direct solar irradiation on the south-oriented sides of the trees and parts of the meadow. The amount of diffuse irradiation depends mainly on the deviation of the incident surface from an ideally horizontal plane. This effect is also noticeable in the diffuse irradiation detail in Figure 4.

The efficiency of pcsrt’s method of modeling stands out also in the urban environment in which buildings are interspersed with greenery. For this use case, we chose Castle Hill in Bratislava, Slovakia (Figure 5). The modeled area contains different types of buildings, flat areas of the castle gardens, the greenery of the castle park and the nearby streets, and other structures. The monthly global solar irradiation is modeled in the solstice and equinox months (March, June, September, and December). The point cloud contains 15 M points, and, with a 0.7 m voxel size and hourly time step, the computation took approximately 80 s for each monthly period. The Linke turbidity factors took the values of 3.6, 4.1, 3.5, and 3.0, and were taken from SoDa [31].

In Figure 5, we can observe different amounts of solar irradiation at different times of the year.

The amount of solar irradiation during the summer is much higher than during the winter, and the sun’s elevation angles are also higher. The south-oriented roofs of the buildings show much higher amounts of solar irradiation compared to the north-oriented roofs. The effect of the orientation of the incident plains can also be seen in the conic rampart tower in detail in Figure 6. The amount of solar irradiation changes continuously from the northern to southern side as well as the visualized normal vectors. The shading of urban greenery can also be seen in the park near the castle and also on the nearby streets, showing the impact of the urban greenery on the solar irradiation in both the terrain and buildings.

3.3. Performance

To demonstrate the efficiency of pcsrt, we compare the memory utilization and computation times on different computers and with different point clouds. The following computers were used: (1) a desktop computer with an AMD Ryzen 9 5950X processor and 48 GB of memory, (2) a Dell XPS 9500 laptop with an Intel i7-10750H processor and 16 GB of memory, and (3) a desktop computer with an Intel i5-6700 processor and 16 GB of memory. The used hardware has been sourced from Bratislava, Slovakia.

As sample data, we used three point clouds with various numbers of points and densities. We measured the preprocessing time and solar radiation computation time while modeling the solar irradiation over a period of one month in August with an hourly time step. Since all point clouds were processed in a single block, the computation of normal vectors was included in the preprocessing time. Both the read and write operations of the input and output data were excluded from the measurement.

The measured times and data specifications are listed in

Table 1. Comparison of the performance with different types of point clouds and on different hardware.

. In all cases, the processing took minutes to complete, and the maximum memory usage was less than 9 GB. The decrease in computation times with the more powerful processor can be seen in both the preprocessing and solar radiation computation, mainly due to the parallel processing of normal vectors and time steps. The memory usage grows with the number of threads that require exclusive access to some of the data stored in memory.

In the case of a dense point cloud with more than 100 million points, in which most of the data stored in memory are the points themselves, the relative difference between the 16-core processor and the four-core processor is much lower. To reduce the amount of memory used, one can always split the point cloud into blocks using the relevant input parameter.

3.4. Comparison with GIS-Based Tools

In this section, we compare the pcsrt’s method of illumination and solar-radiation modeling with the results of well-known GIS tools. This approach was chosen due to the complexity of validation against measured data since pcsrt does not implement a model of cloudiness yet, and also because acquiring relevant data from simultaneous measurements in multiple points would be problematic and expensive. Most 3D tools, such as SORAM [7], SURFSUN3D [25], and Solar3D [6], use predefined points on surfaces for solar-radiation estimation, and their methods of illumination calculation differ.

Moreover, SURFSUN3D and Solar3D use the r.sun [26,32] module for solar radiation calculation. It would be problematic to define the source of potential differences between such results as they would incorporate differences in solar-radiation models, differences in illumination-modeling methods, and differences caused by the unification of the output data formats. Therefore, we compare pcsrt with the GRASS GIS tool r.sun and the ArcGIS tool Area Solar Radiation [27,33] directly.

The r.sun and Area Solar Radiation are used to model solar radiation in DEM. To compare these tools with pcsrt, we generate a point cloud from DEM, use pcsrt with the point cloud, and transform it back to DEM using CloudCompare. The DEM sample we chose for this comparison is from the Kamenistá valley in High Tatra Mountains in Slovakia. Both pcsrt and r.sun are based on the ESRA clear-sky model, which differs from the clear-sky model used in Area Solar Radiation proposed in [27], and we, therefore, compare them in a relative way.

With the ESRA model tools, we use the default value of 3 in the Linke turbidity factor, and with the Area Solar Radiation tool, we use the 0.3 value in diffuse proportion and the 0.5 value in transmissivity. All tools were set to model the global solar irradiation in an hourly time step for the 21 June 2022. The results are visualized in QGIS using quantiles and can be compared using Figure 7 and Figure 8.

The computation times using the 16-core AMD Ryzen 9 5950X processor were 1 minute 48 s with pcsrt, 2 min 34 s with r.sun, and 3 h 11 min and 24 s with Area Solar Radiation. The pcsrt and r.sun tools used 32 threads for the calculation, while the Area Solar Radiation tool used a single thread since it does not support multithreading.

In all cases, we can see great similarities in the more-insolated southern slopes and less-insolated northern slopes. The most noticeable difference between the pcsrt and DEM-based tools is the continuity that is visible on the smooth surfaces. The pcsrt tool uses a 3D illumination model, which results in a shading effect of the adjacent voxels even on smooth surfaces; however, in more rugged areas of the DEM, we can see higher detail of the pcsrt in comparison to the DEM-based tools.

Since pcsrt uses the same clear sky model as r.sun, and the same input parameters were used, we can also compare the resulting raster values directly (Figure 9). The root mean square error (RMSE) of the compared rasters is 800.6 Wh/m². The histogram of the differences also suggests that the differences are mainly the result of the illumination method since there is no major shift in the values. The greatest differences are in the rugged areas of the valley and consist of both higher and lower values of solar radiation calculated using pcsrt in comparison with the r.sun.

4. Discussion and Conclusions

The presented results demonstrate the applications of the newly developed tool for modeling solar radiation in 3D and its performance using various types of hardware. The pcsrt function can be, in general, used with any point-cloud data; however, it stands out in vegetation-covered areas and with urban greenery in urban areas, as shown in the use cases of Suchá valley and Bratislava Castle Hill in Slovakia.

Our approach is similar to the method presented in [36], which focused on urban areas and buildings in general, using 3D city model meshes. However, the voxel-based illumination modeling method presented can be used directly with point-cloud data without the need to create 3D meshes of trees as presented in [37]. A combination of these approaches could be implemented within pcsrt in the future in a similar way as presented in [35].

The pcsrt tool calculates the illumination and solar radiation components for every point in the input point cloud, making it more suitable for further analysis than similar 3D tools, such as Solar3D [6], SURFSUN3D [25] and SORAM [7], which are capable of modeling only in predefined points or surfaces.

The tool can be used with point clouds of buildings; however, it should be used with caution since it does not yet implement the calculation of reflected solar radiation, which is much more significant in urban areas. The main focus of pcsrt is geometrically complex areas and can be used directly on large point clouds of forests. The tool can be particularly helpful in analyzing environmental issues in which solar radiation plays a major role, such as bark beetle infestations [14,15]. For example, even according to [44], solar radiation is an important factor in the predictive modeling of bark beetle infestations.

The forest canopy changes during the year, especially with deciduous trees, and therefore the input point cloud should reflect the most up-to-date state of the forest when used with pcsrt. Currently, the pcsrt’s illumination algorithm resolves voxels as illuminated or in shadow and does not model transparency. This should be considered when modeling semi-transparent objects, such as tree canopies [45].

Based on the comparison with r.sun [26,32] and the Area Solar Radiation [27,33], we can assume that the difference in output rasters is mainly a result of different methods of illumination computation implemented within these tools. The greatest differences are located in rugged areas of the presented surface (Figure 9).

The source of these differences likely consists of considering the partially shadowed voxels using the shadow grid described in Section 2.1, the difference in time steps used, and also the difference in alignment of pixels in the case of r.sun with voxels in the case of pcsrt, which may cause different results in valleys [44]. Since the methods used in both approaches are different as is the representation of the terrain and focus of these tools, it is not possible to make a definite statement, although the assumption is that the 3D approach should be more accurate than the 2D.

pcsrt is a 3D tool, and the voxel illumination method causes a somewhat noisy effect on smooth surfaces; however, the general likeness of the results suggests the correct implementation of the computation method. Nevertheless, a more-complex validation method would be appropriate to verify the modeled solar-radiation data against the measured data or physics-accurate models, such as in [46].

However, the measurements in that case would be difficult and expensive as they would have to be performed simultaneously on many points to ensure the same conditions. The validation method would also need to consider the difference between the accuracy of the solar-radiation model (ESRA) itself and the modeling method using point-cloud data. Therefore, the development of a correct validation method is a subject of future research.

The pcsrt function performs sufficiently in terms of the computation speed and memory usage, making it easily usable even on common computers. Since pcsrt is a command line tool and can be used on Linux, macOS, and Windows operating systems, its integration to GIS software, such as QGIS, is uncomplicated and is subject to further development. Currently, point-cloud or mesh-focused software, such as CloudCompare, can be used to visualize or further process the output data.

The pcsrt tool implements an effective method of illumination calculation that could be used with multiple solar-radiation models. Extending the choice of ESRA model with other models would allow the user to pick the most suitable model for the use case. Models based on the Linke turbidity factor, such as [34], could be easily implemented in further development. The block processing feature of pcsrt solves the issue with insufficient memory and large point clouds; however, the implemented method uses a single point to calculate the position of the Sun.

The shadowing effect of the surrounding terrain, which would not be included in the input point cloud, is only partially considered while using the elevation mas implementation. In future development, a coordinate transformation library, such as PROJ [47], could be implemented to improve the capabilities of pcsrt. In this way, the input data would not need to be in a horizontal metric coordinate system. The reference point could be determined automatically, and combining point clouds with different input data, such as DEM representing the surrounding terrain, would be possible. To improve the vegetation-modeling capabilities, a transparency parameter for the voxels could be implemented to reflect the semi-transparent nature of tree canopies.