3D Solar Potential in the Urban Environment: A Case Study in Lisbon

: The assessment of solar potential in the urban environment is an important instrument for policy decision regarding renewable energy deployment in the city. This paper presents an experimentally validated 3D solar potential model for rooftops and facades from LIDAR data considering anisotropic di ﬀ use irradiation. The data visualization is rendered in the ArcGIS platform using CityEngine to automatically generate 3D models from 2D geometries. The model is validated against summer and winter measurements of photovoltaic performance on a facade. A case study for two densely packed urban areas in Lisbon, Portugal, are presented. Facades are shown to increase the solar potential by 10 to 15%.


Introduction
The assessment of solar potential in the urban environment is an important instrument for policy decisions regarding renewable energy deployment in the city. There is a diversity of methods and tools available for this task, mostly for rooftops, although there is an emerging interest in the solar potential of facades and other vertical structures [1] as the fast decreasing cost of photovoltaics makes it more attractive for non-optimum inclination taking advantage of its ability for a better adjustment between solar electricity generation and local demand [2].
The assessment of the solar potential of building facades solar in the urban environment requires sophisticated methods to perform full 3D radiation operations in an intricate digital surface model (DSM). Moreover, the management of numerical results and their visual representation might not be trivial. A high degree of user-friendliness is also desirable for large-scale solar potential models, contributing to the successful dissemination of these models among users and the research community.
The state-of-the-art facade potential enables tools to stand out for allowing detailed analysis of irradiation over those surfaces and their subsequent use for more than just visualization purposes. Townscope [3] and Solene [4] are high surface spatial resolution GUI tools adequate for use up to the neighborhood scale. Their specific native functions for evaluating solar potential are usually non-editable, which might prevent the further use of results. Large-scale facade solar potential can be achieved using LiDAR data and GIS models such as v.sun [5] and customized ones such as SOL [6] and SEBE [7] that recreate vertical surfaces from elevation data. These might require parallel computing and simplifications to compute results in a timely manner. The tool SURFSUN3D [8] achieved a significant improvement with GPU acceleration and is able to create detailed facade potential georeferenced representations on-demand. Promising tools encompass parametric modeling and editing of building geometries coupled with energy simulation features, including DIVA [9] and LadyBug [10], which allow for simulating the building performance with several design alternatives as a function of the facade solar potential. In the latter, the user is free to adapt its source code, create new functions, and share with other users, which prompts faster development of the tool. The combination of LadyBug with the BIM and semantic database functionalities of Revit [11] can be considered the top state-of-the-art for facade solar potential modeling in the life cycle of the building. Yet, it is unable to easily scale up from a few buildings to the citywide context. Non-BIM models based on CityGML, such as SimStadt [12] and Bremer et al. [13], are also state-of-the-art because they feature complex radiation models, effortless computation for high spatial coverage, and establish relationships between the different elements represented.
Some of these models can help professionals of diverse fields evaluating the solar energy potential of their projects, even without having a deep knowledge of the physics behind it, nor advanced programming skills. When solar potential models evolve into online maps, estimating the revenue from a building applied solar system becomes accessible to all citizens, decision-makers, and local authorities, who might not be acquainted with solar radiation formulations nor have a solar energy systems background.
One critical point regarding the development of such models is their experimental validation. Indeed, as solar potential models are built on established solar irradiation models and geometry considerations (e.g., sky view factor), often, its validation is only assessed by comparing its results with other competing models, more as a means to identify possible coding errors than to quantify the uncertainties of its estimations. However, the building environment is a complex context, with multiple specular and diffuse light reflections, semi-transparent time-varying obstacles, such as trees and microscale textures on the building surfaces themselves, which together with modeling approximations, such as the simplification of the impact of partial shading on a modules' performance will lead to errors in the solar potential estimation. It is thus of critical importance to assess the uncertainty of solar potential models.
Redweik et al. [6] presented a model for solar potential assessment of the city landscape, including rooftops and facades of buildings. In this work, further developments of the model are presented, including the consideration of diffuse irradiation anisotropy based on the Perez model. Section 2 describes the solar potential assessment algorithm and the workflow for the representation and web publication of results. Section 3 presents the result of the experimental validation of the models and Section 4 summarises the results. Conclusions are drawn in Section 5.

Model
The 3D solar potential assessment model for rooftops and facades is based on the Redweik et al. model [6] which models elements of facades as hyperpoints.

Input Data
SOL is an algorithm developed in MATLAB, whose input is a digital surface model (DSM) obtained from aerial LiDAR data of an urban area with 1 m resolution, hourly horizontal solar irradiation data from a database, such as Solterm [14] or Meteonorm [15], the geographic location of the area (mean latitude and longitude), as well as the time zone. The typical dimension of the input DSM is 500 m × 500 m. For greater areas, the calculation must be performed for each tile. From the DSM, a slope and an aspect map are calculated. From the slope map, facade delineation is determined, and a binary facade map is produced (1 = facade, 0 = no facade).

The Shadow Algorithm
The core of the SOL algorithm is the shadow calculation in DSM profiles with the orientation corresponding to the sun azimuth plus 180 degrees. A spatial ray with an inclination equals the sun elevation is propagated from the height of the first pixel along with each profile losing height as it runs proportionally to the traveled way and the inclination angle ( Figure 1). All pixels of the DSM that are below the ray are in shadow (cast by the relief, buildings, or trees). Every time the ray reaches a point of the DSM higher than the actual ray height at that location, the ray assumes the height of the reached point (which is not in shadow) and continues to run the profile. Pixels in shadow are transferred to a map, building a binary shadow map after all profiles have been run. Additionally, every time the ray hits a facade (a pixel that equals 1 in the facade map), the height of the reached point is registered as the maximum shadow height on a shadow height map. This is a map similar to the facade map but containing the shadow heights on the pixels of the facade lines and zeros on the remaining pixels.
Energies 2018, 11, x FOR PEER REVIEW 3 of 13 a point of the DSM higher than the actual ray height at that location, the ray assumes the height of the reached point (which is not in shadow) and continues to run the profile. Pixels in shadow are transferred to a map, building a binary shadow map after all profiles have been run. Additionally, every time the ray hits a facade (a pixel that equals 1 in the facade map), the height of the reached point is registered as the maximum shadow height on a shadow height map. This is a map similar to the facade map but containing the shadow heights on the pixels of the facade lines and zeros on the remaining pixels. The shadow algorithm is applied not only to create the shadow map for each hour of each day, for a pair of solar azimuth and solar elevation calculated by astronomical equations but also for determining the sky view factor (SVF-the percentage of the skydome viewed from a certain position).

Hyperpoints
Prior to calculating the SVF for the urban area, the vertical facade faces must be reconstructed. SOL introduced the concept of the hyperpoints to model the facades in 3D. Each facade pixel in the facade map is considered a hyperpoint meaning that it represents several points with the same coordinates X and Y but with different Z, like a vertical column of points. Each point is named a hyperpoint element. The vertical distance between elements is equal to the DSM resolution, usually 1 m, and the number of elements of each hyperpoint depends on the height of the facade above ground on the position of the hyperpoint.
During the shadow calculation, the shadow height map indicates, for each hyperpoint, which elements are illuminated (point height above maximum shadow height) and, which are in shadow (point height below maximum shadow height). Hyperpoints are saved in MATLAB as a structure of cells for the whole urban area. Each cell is a hyperpoint and contains as many elements as the hyperpoint itself. The shadow algorithm is applied not only to create the shadow map for each hour of each day, for a pair of solar azimuth and solar elevation calculated by astronomical equations but also for determining the sky view factor (SVF-the percentage of the skydome viewed from a certain position).

Hyperpoints
Prior to calculating the SVF for the urban area, the vertical facade faces must be reconstructed. SOL introduced the concept of the hyperpoints to model the facades in 3D. Each facade pixel in the facade map is considered a hyperpoint meaning that it represents several points with the same coordinates X and Y but with different Z, like a vertical column of points. Each point is named a hyperpoint element. The vertical distance between elements is equal to the DSM resolution, usually 1 m, and the number of elements of each hyperpoint depends on the height of the facade above ground on the position of the hyperpoint.
During the shadow calculation, the shadow height map indicates, for each hyperpoint, which elements are illuminated (point height above maximum shadow height) and, which are in shadow (point height below maximum shadow height). Hyperpoints are saved in MATLAB as a structure of cells for the whole urban area. Each cell is a hyperpoint and contains as many elements as the hyperpoint itself. The SVF in SOL is calculated for an equiangular division of the skydome. A set of light sources is distributed along quarters of vertical circles from 15º elevation till the zenith (90º). The circles present the same angular distance in the horizon as the sources along each circle. A SVF map for the ground and roofs and an SVF table for the hyperpoint elements are created and initialized with the total amount of light sources. Then, the shadow algorithm is run for every pair of azimuth and elevation of a light source generating each time a shadow map and a shadow height map. The number of times each point was in shadow is reduced from the total amount of light sources, yielding the number of sources visible from that point. The proportion of the result to the total amount of sources yields the SVF, varying between 0 and 1. The SVF will be needed in the calculation of the diffuse irradiation.
The number of light sources influences the results and processing time. A test was performed with several equiangular sky subdivisions comparing the subsequent diffuse irradiation on the facades on a winter and summers day, assuming an isotropic sky. The subdivisions corresponded to having a light source every 3 • , 5 • , 10 • , and 15 • (Figure 2). The results showed that taking the denser distribution of sources (every 3 • ) as a reference, the 5 • and 10 • distribution overestimated the diffuse irradiation by +1.5% and +1.8%, respectively. But for the 15 • source distribution, there was an underestimation by −4.5%. On the other hand, the processing time for the calculation of the SVF decreased significantly as the distance between sources increased (−63% of processing time for 5 • , −91% for 10 • , and −96% for 15 • ). The number of sources decreases meaning that the number of times the shadow algorithm must run over the DSM is reduced. The SVF in SOL is calculated for an equiangular division of the skydome. A set of light sources is distributed along quarters of vertical circles from 15º elevation till the zenith (90º). The circles present the same angular distance in the horizon as the sources along each circle. A SVF map for the ground and roofs and an SVF table for the hyperpoint elements are created and initialized with the total amount of light sources. Then, the shadow algorithm is run for every pair of azimuth and elevation of a light source generating each time a shadow map and a shadow height map. The number of times each point was in shadow is reduced from the total amount of light sources, yielding the number of sources visible from that point. The proportion of the result to the total amount of sources yields the SVF, varying between 0 and 1. The SVF will be needed in the calculation of the diffuse irradiation.
The number of light sources influences the results and processing time. A test was performed with several equiangular sky subdivisions comparing the subsequent diffuse irradiation on the facades on a winter and summers day, assuming an isotropic sky. The subdivisions corresponded to having a light source every 3°, 5°, 10°, and 15° ( Figure 2). The results showed that taking the denser distribution of sources (every 3°) as a reference, the 5° and 10° distribution overestimated the diffuse irradiation by +1.5% and +1.8%, respectively. But for the 15° source distribution, there was an underestimation by −4.5%. On the other hand, the processing time for the calculation of the SVF decreased significantly as the distance between sources increased (-63% of processing time for 5°, −91% for 10°, and −96% for 15°). The number of sources decreases meaning that the number of times the shadow algorithm must run over the DSM is reduced. Taking the results of the test into account, the 10° skydome subdivision was considered in the second version of SOL, SOL2.0, with 289 light sources instead of 1,081 sources considered in SOL 1.0, saving significantly on processing time without compromising on the accuracy.

Diffuse Irradiation
An anisotropic sky model was adapted to the SOL algorithm following the Perez model presented in [16], which is shown in the equation (Equation (1)).
Where GTI is the global tilted irradiation on a surface with β slope and Ψ aspect, BHI is the direct horizontal irradiation, θi [β, Ψ] is the incident angle of sun rays on a surface with β slope and Ψ aspect, θz is the Sun zenith angle, DHI is the diffuse horizontal irradiation, GHI is the global horizontal irradiation, ρ is the ground reflectivity, = max(0,cos( [ ,ψ])), = max(cos(85º), cos( ), F1 is the Taking the results of the test into account, the 10 • skydome subdivision was considered in the second version of SOL, SOL2.0, with 289 light sources instead of 1081 sources considered in SOL 1.0, saving significantly on processing time without compromising on the accuracy.

Diffuse Irradiation
An anisotropic sky model was adapted to the SOL algorithm following the Perez model presented in [16], which is shown in the equation (Equation (1)).
where GTI is the global tilted irradiation on a surface with β slope and Ψ aspect, BHI is the direct horizontal irradiation, θi [β, Ψ] is the incident angle of sun rays on a surface with β slope and Ψ aspect, θ z is the Sun zenith angle, DHI is the diffuse horizontal irradiation, GHI is the global horizontal irradiation, ρ is the ground reflectivity, a = max(0,cos(θ i[β,ψ] )), b = max(cos(85º), cos(θ z ), F 1 is the circumsolar anisotropy coefficient and F 2 is the anisotropy coefficient between the horizon and the zenith. The first parcel of Equation (1) describes the direct portion of the irradiation, the second the diffuse and the third, the reflected portion of irradiation reaching a point in a tilted surface. The reflected irradiation was not considered in SOL because it requires a better characterization of the surroundings, which is not available. The direct irradiation parcel was only computed for the points which were not in shadow at the time and day in question. The diffuse parcel has three terms. The first relates to the part of the sky that can be seen from a point on the tilted surface. In SOL, this is represented by the SVF. The second term is only applied when the point is not in shadow, since it represents the circum-solar component of diffuse irradiation. The third term is not considered in SOL because the influence of the horizon in an urban zone, where it is mostly covered by buildings or trees, is negligible. The adapted irradiation model for SOL is, therefore, described by Equation (2).
The circumsolar coefficient F 1 is calculated by Equation (3).
where ∆ is the sky brightness and F i,j are sub-coefficients of irradiance which values depend on the sky clearness ε and are can be collected from Sky brightness and clearness can be obtained from Equations (4) and (5).
where, I 0 is the extra-terrestrial irradiance that varies along the year, depending on the number of days J from January the 1st. BNI is the direct irradiance on a normal surface to the rays. Figures 3 and 4 show the workflow of SOL 2.0. Although separated for better understanding, both workflows are fused in the algorithm. For instance, the SVF is calculated once for roofs, ground, and facades, and shadow map and shadow height map are also calculated in the same step. The only fundamental difference is that for roofs and ground, every calculation is made on a grid, because the points are representable in the XY plan (a map), while for facades, every calculation is made on a structure of cells. Consequently, the basic output of SOL 2.0 consists of several maps for roofs and ground, one for each hour and variable (direct, diffuse, global, shadow, etc.), and. one table for the facades, for each hour, containing one line per hyperpoint element with all the information associated (X, Y, Z, direct irradiation, diffuse irradiation, global irradiation, SVF, incidence angle, aspect, shadow height, etc.). Optionally, sums and means can be calculated for other time intervals, from one day to one year, or for certain periods of the day along the year (e.g., from 9 h to 12 h every day along the year).

SOL 2.0 Workflow and Output
Energies 2018, 11, x FOR PEER REVIEW 6 of 13 Figures 3 and 4 show the workflow of SOL 2.0. Although separated for better understanding, both workflows are fused in the algorithm. For instance, the SVF is calculated once for roofs, ground, and facades, and shadow map and shadow height map are also calculated in the same step. The only fundamental difference is that for roofs and ground, every calculation is made on a grid, because the points are representable in the XY plan (a map), while for facades, every calculation is made on a structure of cells. Consequently, the basic output of SOL 2.0 consists of several maps for roofs and ground, one for each hour and variable (direct, diffuse, global, shadow, etc.), and. one table for the facades, for each hour, containing one line per hyperpoint element with all the information associated (X, Y, Z, direct irradiation, diffuse irradiation, global irradiation, SVF, incidence angle, aspect, shadow height, etc.). Optionally, sums and means can be calculated for other time intervals, from one day to one year, or for certain periods of the day along the year (e.g., from 9 h to 12 h every day along the year).

2.2.Representation
The produced grid and tabular data content produced by SOL 2.0 does not have geographic context associated to allow an object-based analysis of the solar radiation. The generated facade hyperpoints only host the information regarding the 3D spatial coordinates but no indication of which facade they belong to. Similarly, the roofs radiation maps are georeferenced but have no identification regarding the building. For further analysis and exploration of information through adapted spatial queries it is, thus, interesting to integrate these data with a 3D urban model into a GIS platform to geographically contextualize the results. In particular, it is important to be able to explore a range of spatial scales, from the 1 m 2 element in the facade or roof, the facade or roof themselves, and the building, as well as a range of temporal scales, from hourly to daily, monthly, and yearly sums.
For this purpose, the ArcGIS platform was used, with its desktop (ArcGIS Pro) and web (ArcGIS Online) components. CityEngine was used to automatically generate 3D models from 2D geometries. The process is composed of four distinct stages:  Pre-processing of tabular data: Because the results produced by SOL present the maximum spatial and temporal resolution, it was necessary to aggregate the data through summing operations for longer periods, in order to produce this information for a full year. This operation involves processing about 4030 files to produce a table with all values corresponding to a 500 m × 500 m LiDAR tile. For this purpose, a Python script was developed to automate the process. Also, during this phase, an additional field (FID) was created in each table to be filled with a unique identifier per hyperpoint element, which would later allow univocal association with each facade/roof element.

Representation
The produced grid and tabular data content produced by SOL 2.0 does not have geographic context associated to allow an object-based analysis of the solar radiation. The generated facade hyperpoints only host the information regarding the 3D spatial coordinates but no indication of which facade they belong to. Similarly, the roofs radiation maps are georeferenced but have no identification regarding the building. For further analysis and exploration of information through adapted spatial queries it is, thus, interesting to integrate these data with a 3D urban model into a GIS platform to geographically contextualize the results. In particular, it is important to be able to explore a range of spatial scales, from the 1 m 2 element in the facade or roof, the facade or roof themselves, and the building, as well as a range of temporal scales, from hourly to daily, monthly, and yearly sums.
For this purpose, the ArcGIS platform was used, with its desktop (ArcGIS Pro) and web (ArcGIS Online) components. CityEngine was used to automatically generate 3D models from 2D geometries. The process is composed of four distinct stages: • Pre-processing of tabular data: Because the results produced by SOL present the maximum spatial and temporal resolution, it was necessary to aggregate the data through summing operations for longer periods, in order to produce this information for a full year. This operation involves processing about 4030 files to produce a table with all values corresponding to a 500 m × 500 m LiDAR tile. For this purpose, a Python script was developed to automate the process. Also, during this phase, an additional field (FID) was created in each table to be filled with a unique identifier per hyperpoint element, which would later allow univocal association with each facade/roof element. or height attributes, the proceeding to assign a height value to each building consisted of three steps: i) Generate a digital terrain model (DTM) derived from the point clouds of the LiDAR survey. All points located less than 10 m from a road or rail were removed to avoid structures, such as bridges, for the interpolation process that followed; ii) generate a digital surface model (DSM) from the same point clouds; iii) extract the values for both DTM (base) and DSM (top) for each footprint polygon to compute the real-world building height as an attribute • 3D modeling and joining attributes: generation of 3D geometries in a GIS environment, from the base 2D footprint polygons using the (CityEngine) CGA scripts. These scripts extrude the buildings vertically from the footprints using the height attribute and successively divide its external faces in squares with a 1 m-side. The resulting 3D objects will then have to be associated, by means of either a spatial (proximity) join with the 3D points featuring irradiance values, or an extraction of the value from a raster tile. This phase also includes the intermediate statistics operations for calculating total accumulated/average values by building/face.

•
Web publishing: uploading of the 3D models and creation of a web application that acts as a visualizer and allows the user to view the details for any of the features

WebGIS Platform
As a result of the modeling process, two main data sets were created: DSM and DTM, for the entire municipality of Lisbon, and 3D models composed by buildings and sub-entities (faces, elements) with their corresponding solar irradiation values. The 3D models were uploaded online, in a web scene that included the sample areas with the parishes of Lisbon as a base map layer.
The WebGIS viewer, in Figure 5, can be accessed through the project website at http://www.pvcity. com. The user is not required to install any specific software and only needs an updated browser to access the platform. This webgis allows the user to select an entity and query its attributes. In the case of faces (roofs/facades) and complete buildings, the radiation attributes correspond to accumulated and (spatial) average values for the selected entity. The user can search by area (parish names) and enable or disable the layers individually. The color scale presented symbolizes an annual radiation attribute, allowing one to visually compare the various buildings or areas belonging to the same facade or roof. A drag button allows for visualizing the shadows casted by each building in its surroundings.  Generation of intermediate geographic products: Because the buildings come from the 2D cartographic base, in a polygon vector structure, and do not have any associated elevation or height attributes, the proceeding to assign a height value to each building consisted of three steps: i) Generate a digital terrain model (DTM) derived from the point clouds of the LiDAR survey. All points located less than 10 m from a road or rail were removed to avoid structures, such as bridges, for the interpolation process that followed; ii) generate a digital surface model (DSM) from the same point clouds; iii) extract the values for both DTM (base) and DSM (top) for each footprint polygon to compute the real-world building height as an attribute  3D modeling and joining attributes: generation of 3D geometries in a GIS environment, from the base 2D footprint polygons using the (CityEngine) CGA scripts. These scripts extrude the buildings vertically from the footprints using the height attribute and successively divide its external faces in squares with a 1 m-side. The resulting 3D objects will then have to be associated, by means of either a spatial (proximity) join with the 3D points featuring irradiance values, or an extraction of the value from a raster tile. This phase also includes the intermediate statistics operations for calculating total accumulated/average values by building/face.  Web publishing: uploading of the 3D models and creation of a web application that acts as a visualizer and allows the user to view the details for any of the features

WebGIS Platform
As a result of the modeling process, two main data sets were created: DSM and DTM, for the entire municipality of Lisbon, and 3D models composed by buildings and sub-entities (faces, elements) with their corresponding solar irradiation values. The 3D models were uploaded online, in a web scene that included the sample areas with the parishes of Lisbon as a base map layer.
The WebGIS viewer, in Figure 5, can be accessed through the project website at http://www.pvcity.com. The user is not required to install any specific software and only needs an updated browser to access the platform. This webgis allows the user to select an entity and query its attributes. In the case of faces (roofs/facades) and complete buildings, the radiation attributes correspond to accumulated and (spatial) average values for the selected entity. The user can search by area (parish names) and enable or disable the layers individually. The color scale presented symbolizes an annual radiation attribute, allowing one to visually compare the various buildings or areas belonging to the same facade or roof. A drag button allows for visualizing the shadows casted by each building in its surroundings.

Validation
The validation of the modified SOL model was done using measured data from a PV system integrated into the south-facing facade of the Solar XXI building, located in Lisbon, Portugal ( Figure 6). The assessment of the model is much more challenging for vertical facades, which are characterized by high incidence angles and complex shadowing events. Hence, it may be assumed that the model validation for rooftops would yield lower errors than those presented for the test on facades.

Validation
The validation of the modified SOL model was done using measured data from a PV system integrated into the south-facing facade of the Solar XXI building, located in Lisbon, Portugal ( Figure  6). The assessment of the model is much more challenging for vertical facades, which are characterized by high incidence angles and complex shadowing events. Hence, it may be assumed that the model validation for rooftops would yield lower errors than those presented for the test on facades.
The PV system has a peak power of 12.16 kW provided by 76 p-Si modules connected to 3 inverters. The whole system architecture and the models employed in the validation procedure are fully described in [18]. The procedure takes into consideration the effect of the operating temperature and incidence angle losses on the efficiency of the PV modules as well as the technical specifications of the PV array, inverter, and cable losses.  Figure 7 compares the estimated PV production against the experimental records. Electricity generation reached higher levels in the winter month, as lower sun elevation leads to closer to normal incidence on the facade. The level of scattering is lower in summer, due to fewer cloud cover events.
The model overestimates PV generation in both months. There is better agreement with experimental data particularly for high production conditions-thus higher irradiance and therefore higher module temperatures. Electricity production from the strings connected to Inverter 3 is lower than the other strings. The shadow casted by the trees located near the easternmost part of the facade might be the cause for such differences.
The nMBE, nMAE, and nRMSE are shown in Table 2. Model performance features the highest errors for inverter 3, particularly in the winter. Overestimation of inverter 3 yields are attributed to c a b Figure 6. Shadow events in the facade PV system (a,b), global vertical irradiation measured in the facade (red dot), and calculated and measured PV production (c).
The PV system has a peak power of 12.16 kW provided by 76 p-Si modules connected to 3 inverters. The whole system architecture and the models employed in the validation procedure are fully described in [18]. The procedure takes into consideration the effect of the operating temperature and incidence angle losses on the efficiency of the PV modules as well as the technical specifications of the PV array, inverter, and cable losses. Figure 7 compares the estimated PV production against the experimental records. Electricity generation reached higher levels in the winter month, as lower sun elevation leads to closer to normal incidence on the facade. The level of scattering is lower in summer, due to fewer cloud cover events.
The model overestimates PV generation in both months. There is better agreement with experimental data particularly for high production conditions-thus higher irradiance and therefore higher module temperatures. Electricity production from the strings connected to Inverter 3 is lower than the other strings. The shadow casted by the trees located near the easternmost part of the facade might be the cause for such differences.
poorly modeled partial shading in the morning, due to the model low spatial resolution (1 m 2 , much coarser than the solar cell size) and overgrown trees. Errors for inverters 1 and 2 may also be attributed to shading events, associated to a building to the west and by another group of trees located southwest of the facade, casting shadows all over the facade in the late afternoon [19]. Figure 7. Comparison between the calculated and measured PV production by the inverter, for June (a) and November (b) 2012. Overall, PV production estimations produced using the SOL model fairly agree with the experimental data, featuring nMBE ranging from around −1% to 71%, nMAE from 21% to 73% and nRMSE from 28% to 92%-higher values observed for the winter month. Part of these errors are attributed to limitations of the solar radiation to PV generation conversion model, which is not included in the SOL model and was developed for this set of tests.

Summer Winter
The DSM 1 × 1 m 2 resolution, which is much larger than the dimensions of a solar cell, hinders the model ability to fine-scale rendering of shadows, underestimating partially shadowing electric losses. A more detailed PV cell model, including the bypass diodes would be needed to accurately simulate the behavior of the PV strings under such partial shading conditions, which is not appropriate to this type of model given the resolution of the DSM, which is 10 times lower than the solar cell dimensions-the propagation of errors would have increased, as well as the computation complexity.
The impact of a new anisotropic diffuse radiation model introduced slight improvement for the summer month, for inverters 2 and 3, which are connected to strings that more often experience partial shading. However, the overall model still seems to deliver poorer results for partially cloudy sky conditions. This points out the importance of matching the level of detail among all models and inputs, as well as inputting site-measured irradiance data.

Results
The 3D solar potential model was applied to two different densely packed areas in the city of Lisbon. Figure 8 presents details of the areas of the case study. One can observe the urban context, the average annual irradiation per building, per surface (i.e., roof and facades), and average annual irradiation per element of surface, both roofs and facades. The nMBE, nMAE, and nRMSE are shown in Table 2. Model performance features the highest errors for inverter 3, particularly in the winter. Overestimation of inverter 3 yields are attributed to poorly modeled partial shading in the morning, due to the model low spatial resolution (1 m 2 , much coarser than the solar cell size) and overgrown trees. Errors for inverters 1 and 2 may also be attributed to shading events, associated to a building to the west and by another group of trees located southwest of the facade, casting shadows all over the facade in the late afternoon [19]. Overall, PV production estimations produced using the SOL model fairly agree with the experimental data, featuring nMBE ranging from around −1% to 71%, nMAE from 21% to 73% and nRMSE from 28% to 92%-higher values observed for the winter month. Part of these errors are attributed to limitations of the solar radiation to PV generation conversion model, which is not included in the SOL model and was developed for this set of tests.
The DSM 1 × 1 m 2 resolution, which is much larger than the dimensions of a solar cell, hinders the model ability to fine-scale rendering of shadows, underestimating partially shadowing electric losses. A more detailed PV cell model, including the bypass diodes would be needed to accurately simulate the behavior of the PV strings under such partial shading conditions, which is not appropriate to this type of model given the resolution of the DSM, which is 10 times lower than the solar cell dimensions-the propagation of errors would have increased, as well as the computation complexity.
The impact of a new anisotropic diffuse radiation model introduced slight improvement for the summer month, for inverters 2 and 3, which are connected to strings that more often experience partial shading. However, the overall model still seems to deliver poorer results for partially cloudy sky conditions. This points out the importance of matching the level of detail among all models and inputs, as well as inputting site-measured irradiance data.

Results
The 3D solar potential model was applied to two different densely packed areas in the city of Lisbon. Figure 8 presents details of the areas of the case study. One can observe the urban context, These results highlight one of the challenges for assessing solar potential in urban areas: contiguous or neighboring buildings not included in the study area will cast shadows on the studied buildings and, therefore, for a large area study, it is required to define a mosaic of areas with significant overlapping, to avoid overestimation of incident irradiation. This procedure was taken for These results highlight one of the challenges for assessing solar potential in urban areas: contiguous or neighboring buildings not included in the study area will cast shadows on the studied buildings and, therefore, for a large area study, it is required to define a mosaic of areas with significant overlapping, to avoid overestimation of incident irradiation. This procedure was taken for these areas, as can be seen, for instance, on the south-facing facades of area 2, which feature different annual irradiation despite the same orientation.
For these densely packed urban areas, the contribution of facades is relatively minor compared to that of the rooftops. As listed in Table 3, for both areas, the average annual irradiance on facades is less than a third of that of rooftops whilst the total annual irradiance is in the range of 10-15% of the total annual irradiance in the studied areas.

Conclusions
In this paper, we have described a 3D solar potential assessment tool from a LIDAR survey. The model is based on the hyperpoint concept, including a raytracing shadow algorithm and an anisotropic diffuse irradiation description based on the Perez model.
The model was validated against experimental measurements of photovoltaic output on a south-facing facade in a summer and a winter month. Results showed a reasonable agreement between modeled and measured irradiation, with larger errors during the winter month, which are attributed to the need for finer scale rendering of shadows, underestimating partially shadowing electric losses.
The representation of the results is featured on ArcGIS web platform, allowing the user to explore annual averages and accumulated irradiation at different spatial scales, including fully identified buildings, facades, roofs and 1 m 2 elements of facades and roofs. Hourly data is also generated but it is not made available for visualization due to the massive amount of data required.
Two densely packed urban areas in the city of Lisbon were analyzed. Results show that, unlike previous studies, which have analyzed newer and less compact areas, facades increase the solar potential by 10 to 15%. Future work will encompass the extension of the validation to other urban locations, with different buildings, urban layouts, and climates. Furthermore, the identified limitations of the solar radiation to PV generation conversion model will be addressed, by using a more detailed PV model. When successful, the results of the PV model will be added to the standard output of the 3D model, adding one extra layer of data to the visualization step to display the electricity generation of buildings, roofs and facades, and surface elements.