Patent Publication Number: US-2012035897-A1

Title: Solar Energy Computation and Planning System

Description:
RELATED APPLICATIONS 
     The present application claims the benefit of U.S. Provisional Application Ser. No. 61/370,941, filed Aug. 5, 2010, the entirety of which is incorporated herein by reference. 
    
    
     THE FIELD OF THE INVENTION 
     The present invention relates to calculating and utilizing solar energy. More specifically, the present invention relates to an efficient and accurate method for calculating the available solar energy for specific areas within an actual geographic location. 
     BACKGROUND 
     Renewable and/or Green energy are gaining traction as energy sources. Unfortunately, renewable and green energy can be expensive to harvest and dependant on environmental factors and changes. In many cases, it can be difficult to plan and implement systems for harvesting renewable energy. 
     One type of green energy is solar energy. While solar energy is a desirable source of energy, it can be difficult to harvest as it is quite variable based on the season, geographic location, and the particular topography of a location. Total solar energy is based in the amount of light that reaches a location over time. Many different environmental factors may affect the available amount of light. Unfortunately, miscalculation or estimation of the amount of light available may result in magnitudes of difference of actual available light. Thus, miscalculations may result in a lower energy production or in a wasted investment. 
     Further, the amount of data available and necessary for calculating the amount of available solar power is often monstrously large-large to the point of being beyond the memory and processing capacity of a computer to compute the dataset at once. Thus, the accurate estimation of solar energy available at a location is a complex task that can take a large amount of computing power a long time to complete. In determining where to best utilize solar energy it is typically desirable to analyze and calculate solar data for a large area such as a city or a large plot of land. It is also desirable to obtain detailed and accurate information in order to best utilize solar power. It will be easily appreciated that trying to obtain detailed calculated solar information for a large area quickly exceeds the ability to calculate the desired information. 
     Current systems for making solar calculations may use different schools of thought. These schools of thought include simple estimation or a brute force and time-consuming computation. In some cases, the system uses simplistic assumptions, such as assuming a flat terrain and a one-size-fits all calculation, that allows for a quick estimation of solar energy, but may give bad data if the assumption is wrong. In the case of flat terrain assumption, a small building which is next to a large building may be shadowed for a significant period of time, making the assumption and resulting calculations clearly wrong. 
     Attempts to accurately calculate available solar power through brute force processing of the available terrain data have generally failed as the tremendous amount of data required for calculating an entire plot of land overwhelms available computational power. As mentioned, it is rarely desirable to analyze a single small section of land. More commonly, a city desires to analyze the entire city area or a company desires to analyze a large area of available land. The inability to process the entire data set for the desired section of land at once requires dividing the data into sections for calculation. Many problems arise from such a sectional calculation, however. If a border around a desired section is chosen at random, such as choosing a border of each surrounding section of land and processing these sections along with a desired section of land, the resulting calculation may be inaccurate or unnecessarily large. If too large of a border is selected, the calculation times may be unnecessarily large. If too small of a border is chosen, the results may be inaccurate, as adjacent land and structures cast shadows or reflections onto surrounding land and affect the available solar energy. Attempts to simply process the topographical data for smaller cities by brute force have taken several months or longer of continuous computer processing time to achieve the results. 
     Thus there is a need for a better way to determine the solar energy available for use with green energy planning. In particular, it can be seen how there is a need for a method of processing the geographic and topographical information for large areas of land in order to determine availability of solar energy for particular locations within the area. There is a need for a method of processing such data which allows for the use of detailed topographical information (including detailed information about trees, buildings and the like) at a high resolution for calculating available solar power while still achieving accurate results and reasonable computational times. 
     SUMMARY 
     Embodiments of the present invention provide an improved solar energy computation and advising system. Some embodiments of the present invention take detailed topographical information for an area such as a city and calculate available solar energy for detailed locations within the area. 
     According to one aspect of the invention, a large three dimensional dataset of the topography of a desired area is trimmed into representative height features, tiled into manageable pieces, with individualized buffers for each tile based on the solar effect of surrounding tiles, which may include height and reflection. This processing of the dataset reduces the redundant computation of tiles while providing a more accurate representation at the boundary of each tile. 
     According to another aspect of the invention, the buffers are re-defined for different times of the year depending on the solar angle and the effects of surrounding features outside of each tile. This allows the system to tailor each determination to only the solar effects that could provide a significant influence on a tile during a specific time of year. 
     These and other aspects of the present invention are realized in a solar energy computation and advising system as shown and described in the following figures and related description. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Various embodiments of the present invention are shown and described in reference to the numbered drawings wherein: 
         FIG. 1  shows an overview diagram of a solar energy computation and advising system; 
         FIG. 2  shows a diagram of interconnected modules of a solar energy processing system; 
         FIG. 3  shows a diagram for understanding LIDAR data; 
         FIG. 4  shows a resulting dataset of location and height coordinates; 
         FIG. 5  shows a diagram of a tiled selection of a dataset with height features; 
         FIG. 6  shows a diagram of a tiled selection upon which a height location determination has been performed; 
         FIG. 7  shows a diagram of a target tile adjacent comparison being performed; 
         FIG. 8  shows a diagram of a buffer size determination performed on a target tile; 
         FIG. 9  shows a uniform final buffer size determination; 
         FIG. 10  shows a varied square buffer size determination; 
         FIG. 11  shows a surface of influence for irregular buffer size determinations; 
         FIG. 12  shows an irregular buffer size determination with exemplary features; 
         FIG. 13  shows a diagram of selected tiles with buffers; 
         FIG. 14  shows the resulting valid data within selected buffers; 
         FIG. 15  shows an example of a dataset with shadow-mapping at a time of day; 
         FIG. 16  shows an example of a dataset with shadow-mapping at a different time of day; 
         FIG. 17  shows an example of a system providing derivative mapping and advice based in the solar energy mapping; 
         FIG. 18  shows an example of a solar heat-map derived from the solar energy data; and 
         FIG. 19  shows an example of available solar energy upon a stadium in Salt Lake City, Utah. 
     
    
    
     It will be appreciated that the drawings are illustrative and not limiting of the scope of the invention which is defined by the appended claims. The embodiments shown accomplish various aspects and functionality of the invention. It is appreciated that it is not possible to clearly show each element and aspect of the invention in a single figure, and as such, multiple figures are presented to separately illustrate the various details of embodiments of the invention in greater clarity. Similarly, not every embodiment need accomplish all advantages of the present invention. 
     DETAILED DESCRIPTION 
     The invention and accompanying drawings will now be discussed in reference to the numerals provided therein so as to enable one skilled in the art to practice the present invention. The drawings and descriptions are exemplary of various aspects of the invention and are not intended to narrow the scope of the appended claims. 
     Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. Modules are at least partially implemented in hardware, in one form or another. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. 
     Modules may also be implemented using software, stored on a physical storage device (e.g., a computer readable storage medium), for execution by various types of processors. Examples of a computer-readable storage medium include, but are not limited to, a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include a compact disk with read only memory (CD-ROM), a compact disk with read/write (CD-R/W), and a digital video disk (DVD). 
     An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module. 
     Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several storage or memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. Where a module or portions of a module are implemented in software, the software portions are stored on one or more physical devices which are referred to herein as computer readable media and/or electronic data storage devices. 
     In some embodiments, the software portions are stored in a non-transitory state such that the software portions, or representations thereof, persist in the same physical location for a period of time. Additionally, in some embodiments the software portions are stored on one or more non-transitory storage devices, which include hardware elements capable of storing non-transitory states and/or signals representative of the software portions, even though other portions of the non-transitory storage devices may be capable of altering and/or transmitting the signals. One example of a non-transitory storage device includes a read-only memory (ROM) which can store signals and/or states representative of the software portions for a period of time. However, the ability to store the signals and/or states is not diminished by further functionality of transmitting signals that are the same as or representative of the stored signals and/or states. For example, a processor may access the ROM to obtain signals that are representative of the stored signals and/or states in order to execute the corresponding software instructions. 
     Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. 
     Reference to a computer readable medium may take any physical form capable of storing machine-readable instructions, at least for a time in a non-transient state, on a digital processing apparatus. A computer readable medium may be embodied by a compact disk, digital-video disk, a magnetic tape, a Bernoulli drive, a magnetic disk, flash memory, integrated circuits, or other digital processing apparatus memory device. 
     Furthermore, the described features, structures, or characteristics of embodiments of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules (stored on a physical device), user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that embodiments of the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention. 
     The schematic flow chart diagrams included herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled operations are indicative of one embodiment of the presented method. Other operations and methods may be conceived that are equivalent in function, logic, or effect to one or more operations, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical operations of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated operations of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding operations shown. 
     Turning now to  FIG. 1 , an overview diagram of a solar energy computation and advising system  10  is shown. The system  10  may take in databases  2  containing solar information and parameters, process the data to obtain solar energy datasets, and then use the solar energy datasets to create various derivative datasets and charts including solar heat maps, interactive web services or recommendations for solar panel placement. 
     More specifically, various databases  2  related to solar energy are transferred to a solar energy processing system  3 . The solar energy processing system  3  prepares the data received for processing and outputs solar data sets, which may include duration of solar energy and watt-hour of solar energy. The output may then be sent to a service  4 , which may transform the data sets into derivative data sets  5 . The service  4  may be interactive with users or prepare a fixed end product. 
     The various databases  2  may include mapping data  6 , atmospheric parameters  7 , and solar parameters  8 . The databases  2  may be retrieved from external sources, such as a geographic information system (GIS), or be prepared internally, such as specially commissioned light detection and ranging (LIDAR) data. In one embodiment, the input data includes LIDAR data, a relevant time span, diffuse proportion of sunlight, atmospheric transmittivity, and a latitude/longitude correlation for the LIDAR data. 
     Turning now to  FIG. 2 , a diagram of interconnected modules of a solar energy processing system  3  from  FIG. 1  is shown. As the data is generally sufficiently large as to not fit within the memory or processing constraints of most computing systems, the data is reduced to a manageable computing level, while having reliable results. This may be accomplished by breaking apart the data into tiles, adding a buffer that represents neighboring tiles that have influence on that tile, computing the result of the buffered tile, discarding the buffer from the resulting output of the tile and stitching back together all of the computed tiles into a final data set, chart, or the like. 
     In the embodiment shown in  FIG. 2 , a control module  20 , such as a software module operating in a computer processor, requests terrain data from a database  30 . The terrain data is sent to a data preparation module  40  to be cleaned, divided into smaller geographic regions referred to as tiles, and buffered. In some cases, the data preparation module  40  may be further divided into a cleaning module, tiling module and a buffering module (not shown). The resulting dataset may then be stored in a source database  50 . The control module  20  may then request tiles and corresponding buffers from the source database  50 . Seasonal, geographical and atmospheric data information  55  with the data from the source database  50  may then be sent to the solar computational module  60 . The solar computational module  60  may then complete the solar energy computation and present the tile results to the output database  70 . The output database  70  may then be used to provide solar maps, recommendations or other solar applications by way of the application services module  80 . 
     Cleaning the terrain data reduces the computational complexity and may aid in the solar estimation accuracy and usefulness. An example of terrain data is shown in  FIG. 3 , which represents LIDAR data. An example of a four strike datapoint may be seen in the laser strikes  90   a ,  90   b ,  90   c ,  90   d  within the unit area  100 . The LIDAR data may be designated by groups of longitude (x-value), latitude (y-value) and a series of height values (z-values). In other cases, the LIDAR data may be a series of x,y,z values. As strikes  90   a ,  90   b ,  90   c ,  90   d  may be encountered in any order, the actual height of an object  110  within the unit area  100  may not be obvious. For instance, a set of LIDAR strikes may occur on a tree by striking on a leaf, branch, tree trunk and ground in the unit area. Thus, selection of a height value may affect the accuracy of the solar data, when the dataset gives large variances in z coordinates for the same x and y coordinates. The representation of LIDAR strikes is shown in an enlarged area for purposes of discussion. Often, the LIDAR data may have data points about three feet apart, providing a more detailed depiction of the desired terrain. 
     Several calculations may be used to select a height value. A simple calculation may be to accept the highest strike. A median value may be chosen. An average value may be chosen. The average value may refer to any statistical measure commonly understood as a form of describing centrality within a data set. One example of an average value is an arithmetic mean. The median is another example of an average value. A statistical analysis may be used to eliminate an outlier from the other data points. In one embodiment, the highest strike  90   a  is chosen as it represents the maximum solar influence of the unit area  100 . By choosing the highest strike  90   a , the resulting calculation may give the most conservative result. In other words, the highest strike  90   a  may accentuate any solar influence of a unit area  100 . For instance, if the highest strike was on a leaf, then selecting the highest strike (the leaf) is more likely representative of the shadow that the tree would cast. In other cases, it may be useful to examine the neighboring unit areas or neighboring z strike values to determine if a z-value is unreasonable. 
     Further cleaning of the data may be done in altering the selected values from the strike data. Frequently, the LIDAR height values include decimal or fractional portions. In some cases it may simplify the calculation if the fractional portion of the numerical height is removed through truncation or rounding to an integer value or conversion to a smaller measurement (such as inches or centimeters) and truncation to an integer value. In some cases, the selected values may further be normalized such that a selected z-value becomes zero. In one embodiment, the global minimum of the overall area being analyzed is chosen to be zero, and the original height value from the global minimum is subtracted from each height value to normalize the data set. 
     Turning now to  FIG. 4 , a three dimensional image  120  of a few city blocks resulting from a cleaned dataset of location and height coordinates as has been discussed is shown. Once the LIDAR data has been cleaned, the resulting dataset contains a representation of the heights over a geographic area. A three dimensional representation  120  of a resulting dataset is shown in  FIG. 4 . As the original data is a collection of points, assumptions may be made to convert the collection of points to a surface. In  FIG. 4 , extrusion of the points from a flat surface was chosen. However, other methods may be chosen, including other polygon surface, vertex, centroid or point assumptions or averages. The surface calculations may also be completed during the solar analysis discussed in  FIG. 13 . 
     In  FIGS. 5-12  and after cleaning, the dataset is broken into tiles and a buffer around the tiles is chosen according to the influence of the other tiles upon the tile of interest. As each tile receives a buffer only substantial enough to enable the reasonable calculation of solar energy, the amount of computing work may be reduced to allow for a faster processing of the entire dataset. The buffer may be determined by the shadow cast by neighboring tiles&#39; features into the tile of interest. 
     Turning now to  FIG. 5 , once the terrain dataset is cleaned, the cleaned dataset  130  may be tiled and reviewed for features such as tall objects referred to as height features which influence the available solar power.  FIG. 5  shows a diagram of a tiled selection of a cleaned dataset  130  with height features. The cleaned dataset  130  may be divided into tiles (such as  140   a ,  140   b ,  140   c , etc.). Each tile (such as  140   a ,  140   b ,  140   c ) may have a largest feature (such as  150   a ,  150   b ). In one embodiment, the largest feature may be defined in different ways, including the largest z-value in the dataset, or the largest difference between the max z-value and minimum z-value. 
     The dividing of the dataset  130  into tiles may be simplistic or algorithmic. In a simplistic choice, a standard tile size is chosen. In one embodiment, each tile is 1000 feet (or any other length) per side. In an algorithmic choice, the tile size is chosen by the features within the dataset. In one algorithmic embodiment, the tile size is chosen to be sufficiently larger than the height of the largest feature in the dataset. It appears that the larger the tiles, the smaller the buffer around the tile will be required. Thus, it may be useful to select a division for tiling that will allow for processing of the tile and buffer area within the limits of computer memory and processing power while using a division size that will reduce the buffer required. Determining the size of the buffer will be explained in conjunction with  FIGS. 6-8 . 
     For example, in Salt Lake City, Utah, a buffer size of 1000 feet per side may be appropriate. Few features (other than the mountains) rise to 1000 feet difference between the ground and the peak (the tallest building is believed to be about 422 feet). Thus the buffer size for most of the city (i.e., away from the mountains) should be less than one tile. 
     Turning now to  FIG. 6 , a diagram of tiled selection upon which a height location determination has been performed is shown in preparation for determining buffer sizes. Once the tiles (such as  140   a ,  140   b ,  140   c ) have been determined, the system  3  may then determine a maximum height (max z-value) and minimum height (min z-value) for each cell. Each set of values may be stored as associated with the cell, shown as a Δ (delta) in  160   a ,  160   b ,  160   c . In one embodiment, the z-values are normalized, and therefore the minimum z-value need not be calculated and assumed to be zero. These stored z-values may then be used to determine buffer sizes by comparing neighboring tiles. 
     In  FIG. 7 , the selected tile  170  is compared against the surrounding tiles  180   a ,  180   b ,  180   c ,  180   d ,  180   e  in preparation for determining buffer sizes. In one embodiment that results in a uniform buffer, the comparison includes comparing the maximum of the bordering tiles and selecting the adjacent tile with the maximum z value contained within the tile. This maximum z value may then be used to determine the uniform buffer size as shown in  FIG. 8 . However, it should be noted that if the tile-size is not sufficiently large (i.e. large in comparison to the height of the objects within the tile), it may be advantageous to include a larger number of tiles than just the tiles immediately adjacent. 
     In the embodiment described above, it should be noted that the northern tiles  190   a ,  190   b ,  190   c  have minimal influence on the solar energy within the selected tile  170  and therefore may be omitted from the calculation. However, there may be legitimate reasons to include the northern tiles  190   a ,  190   b ,  190   c  in some calculations (such as in the southern hemisphere or where there may be significant reflected sunlight from objects such as buildings in the tiles) and/or exclude other tiles. It is thus appreciated that knowledge of the geographic area being analyzed can allow a person to exclude buffer data from calculation and optimize the buffer size where used to significantly reduce the time and computer power necessary for calculating the available solar potential in a desired tile or geographic area. 
     Turning now to  FIG. 8 , a diagram of a buffer size determination performed on a target tile is shown. The buffer distance may equal the difference  200  in elevation between the minimum of the selected tile  170  and the maximum z height  210  of the neighboring tiles  180   a ,  180   b ,  180   c ,  180   d ,  180   e , divided by the tangent of the sun angle  220 . In the embodiment shown, only the Southern Hemisphere tiles  180   a ,  180   b ,  180   c ,  180   d ,  180   e  (as opposed to the Northern tiles  190   a ,  190   b ,  190   c ) are used because it was noted that, in the example of Salt Lake City, the northern tiles had minimal influence from the sun on the selected tile  170 . However, there may be legitimate reasons to include the northern tiles  190   a ,  190   b ,  190   c  depending on the geography, location, time of year and/or sun angle. 
     Turning now to  FIG. 9 , a uniform final buffer size determination is shown. When using a maximum z-value from the neighboring tiles, a buffer  240   a ,  240   b  will be applied uniformly around a buffered tile  250   a ,  250   b . The larger the difference between the z-value minimum of the selected tile and the z-value maximum of the neighboring tiles, the larger the buffer. Thus a small difference may result in a small buffer  240   a , while a large difference may result in a large buffer  240   b . This calculation to determine an appropriate buffer size yields a buffer which is sufficiently large to adequately account for the effect of objects in neighboring tiles without using a buffer which is overly large and unnecessarily adds to the computation time. 
     Turning now to  FIG. 10 , a varied rectangle buffer size determination is shown. In some cases, it may be more efficient to use a more complex buffer calculation and thereby further reduce the amount of solar energy calculation. Thus it may be useful to choose an individual buffer size for each side of the target tiles, or for each surrounding tile. In this case, the z-value of the western tiles  260 ,  270 ,  280  may be compared and the largest z-value may be used in the buffer computation of  FIG. 8  to determine the western buffer  285  size. Similarly, the z-value of the northern tiles  280 ,  290 ,  300  may be compared and the largest z-value may be used in the buffer computation of  FIG. 8  to determine the northern buffer  305  size. In the same way the eastern tiles  300 ,  310 ,  320  and southern tiles  320 ,  330 ,  260  examined and an appropriate buffer  325 ,  335  size may be computed. Thus, the computational complexity may be reduced from the large uniform buffer of  FIG. 9  to a smaller rectangle in  FIG. 10  with more pre-processing. 
     In  FIGS. 11 and 12 , an irregular buffer size is computed and shown to further reduce the required dataset. In some cases, where the solar calculating software requires a square dataset (or a dataset having another canonical shape), the unused space may be set to a minimum value to reduce the complexity of the calculation (see  FIG. 12  and the associated description below). Additional space which, when added to irregular buffer size, would result in square or rectangular size. 
     Turning now to  FIG. 11 , a surface of influence  340  is shown in relation to terrain features  350   a ,  350   b ,  350   c . In some cases, it may be worthwhile to reduce the buffer size further through more pre-processing. Using the calculation from  FIG. 8 , a height to distance ratio may be computed that results in a surface  340  of influence around the buffered tile  250   b . The surface  340  defines the minimum height by which a terrain feature  350   a ,  350   b ,  350   c  must obtain to influence the buffered tile  250   b  from a neighboring tile  355   a ,  355   b . Based on the height to distance ratio, the size of the surface  340  depends on the height of the surface  340 . For example, a surface  340  at a lower height (i.e., closer to the terrain level) would be smaller than a surface  340  at a higher height. In  FIG. 11 , this variation of the size of the surface  340  is illustrated by an approximately conical volume, which shows a range of sizes relative to different heights. In one embodiment, any terrain feature which intercepts any of the potential surfaces  340  within the volume will result in an influence on the buffered tile  250   b . Conversely, any terrain feature which does not intercept any of the potential surfaces  340  within the volume will not influence the buffered tile  250   b . The surface  340  may be skewed due to lesser influence by northern tiles (as may be the case in Salt Lake City). However, a distance from the buffered tile assumption may be appropriate to reduce the processing complexity. Features equidistant from the tile may be compared against a similar height requirement. 
     If a terrain feature has a z-value greater than the z-value at the surface (terrain features  350   b  and  350   c ), the feature may be included in the buffer. If the terrain feature does not exceed the surface z-value (terrain feature  350   a ), the feature may not be included in the buffer. In other words, terrain features which have a height that extends into the volume corresponding to the height to distance ration of the surface of influence  340  will influence the buffer, while other terrain features will not influence the buffer. 
     Turning now to  FIG. 12 , an irregular buffer size determination with exemplary features  360   a ,  360   b ,  360   c ,  360   d  is shown. This buffer may be achieved by determining which terrain features are tall enough based on their proximity to the selected tile to affect the sunlight in the selected tile. After pre-processing, the irregular buffer  370  may have an irregular form. In some cases, the solar calculation algorithm may require a rectangular buffered tile  380 , such that a bounding algorithm should be run on the irregular buffer  370  to result in a rectangular buffered tile  380 . In other cases, it may be advantageous to set the area outside the irregular buffer to a rectangular or irregular shaped minimum value to ease the calculation. 
     As shown in  FIGS. 13-16 , once the buffer is determined, the solar analysis may be performed on the buffered tile. Once the analysis of solar power striking the areas within the target tile is complete, the analysis data for the buffered portion of the output may be discarded and the output area corresponding to the original tile may be stitched back together with the information from other target tiles to form the complete output dataset. 
     Turning now to  FIG. 13 , a diagram of selected tiles with buffers is shown. Once the buffer  390  has been selected around the buffered tile  250   b , the processing tile  400  may be trimmed to the buffer  390 . The processing tile  400  may then be sent to a solar computational module such as ArcGIS Desktop 10.0, Spatial Analyst, Solar Radiation Toolset from ERSI at 380 New York Street, Redlands, Calif. 92373-8100. 
     Once the solar computational module&#39;s calculation is complete, the output tile  407  related to the buffered tile  250   b  is trimmed as shown in  FIG. 14 . The trimmed output tile  405  of the buffered tile  250   b  is then stored, while the extraneous data of the output tile  407  may be disposed. Each trimmed output tile  405  may then be stitched back together to form an output dataset representing the solar data relating to the original input geography. This output dataset may include duration of solar energy and watt-hour of solar energy. 
     The output dataset may then be used by a service, such as a web-service, to compute solar heat maps, advice on solar panel placement, advice/predictions on plant/structure placement for influence on the reduction of heat to a building, or other solar energy maps, advice or transformations of the output. 
     It should be noted that the buffer calculations may be repeated for different times of the year, as the solar angle (the angle of the sun relative to the specific location being analyzed) changes. In one embodiment, the calculations are repeated for each month of the year. The output dataset is thus stored for each month of the year, and may be combined in a yearly report or requested for certain times of the year that are found to be concerning. 
     Turning now to  FIGS. 15 and 16 , an example of a dataset with shadow-mapping at a time of day is shown. The processing tile  400  given to the solar computational module may be used to calculate solar energy available over a specific time frame. Seasonal variances, such as sun angle, may also be accounted for. In  FIGS. 15 and 16 , the shadow calculations have been overlaid on a map to show the importance of the buffering principle. For instance, building  410  may have significant influence in buffered tile  250   b . However, tree  420  may not have any effect on buffered tile  250   b.    
     In  FIGS. 17 to 19 , the system is shown to produce a solar output dataset that may then be used in various derivative dataset construction operations. These derivative datasets may include solar heat maps, solar panel advice, heat island effect analysis, or other static or dynamic constructions and combination of datasets. 
     Turning now to  FIG. 17 , an example of a system  480  providing derivative mapping and advice based in the solar energy mapping is shown. A solar energy processing server  430  receives data from multiple databases  440 ,  445 , which may include mapping data, atmospheric data, and solar data. The solar energy processing server  430  may process the data and return a solar output of the geographic area. In one embodiment, the solar energy processing server  430  outputs a solar output which includes an array of duration of solar energy and watt-hour of solar energy, where each element of the array represents one square meter of the geography. 
     The solar output may then be stored in a solar database  450  for retrieval by an application server  460 . The application server  460  may then create derivative information from the solar database  450 . This derivative information may include a solar heat map, available solar energy map, advice on solar panel placement, advice/predictions on plant/structure placement for influence on the reduction of heat to a building, or other solar energy maps, advice or transformations of the output. 
     In one embodiment, the application server  460  retrieves a map from storage  470  to use in a solar heat map overlay  510  (shown in  FIG. 18 ) created with the solar database  450 . The system  480  may further estimate changes in the solar heat map if a tree or structure is placed in the map. Thus an architect or landscape artist can use the system to estimate the heat reduction to a building by using different plants or structures. Alternatively, a person may determine where to best locate solar panels. A person may also best determine where to place accumulations of snow when clearing snow to allow the snow to melt. It can be seen how there are many end uses to the solar analysis. 
     Furthermore, the system  480  may limit itself to specific portions of the solar database  450 , such as times of the year. For instance, an architect may only be concerned about heat dissipation in the spring and summer months. Thus placement of plant or structures on the solar heat map may be limited to only reflect summer months. 
     In another embodiment, the application server  460  retrieves a map from storage  470  to use in a solar energy map overlay  520  (shown in  FIG. 19 , an example of available solar energy upon a stadium in Salt Lake City) created with the solar database  450 . A client computer  485  or mobile device  490 , may access the application server  460  through a network  500 , such as the internet. The client computer  485  may identify an area, such as a roof, and request the application server  480  to identify the amount of energy available to solar panels. The system  480  may also identify areas that would return a sufficient investment in the panels to warrant their placement. 
     In one embodiment, a web service (e.g., available in conjunction with the application server  460 ) may display data and advice based on the calculated solar energy. A user may visit the web service, search for their home or business and then select the desired area, such as a roof. The web service may give solar advice based on the selected roof size, useable roof percent and/or estimated system size. The web service may also show a comparison of system sizes. The system  480  may automatically calculate the square footage of the selected roof, amount of electricity generated, cost savings and carbon dioxide savings. In another window, the web service may also graph the expected solar duration or energy generation over time. The web service may also show results of a suggested system size, including benefits. 
     While the system has been described in terms of arrays, tiles, databases, servers and modules, it should be recognized that alterations to the structure may be obvious and anticipated. For instance, while the term database has been used, it is anticipated that other forms of data storage may be used, such as files, optical or magnetic media, cloud storage, database server or other forms of containing data, recalling data and data structures. While individual servers have been discussed for clarity, in some cases multiple servers may be used to perform the same task to increase performance. Similarly, a single server may also be used to perform multiple tasks. While module delineations have been discussed for clarity, it may be advantageous to join, split or reassign individual module task assignments. In fact, with multiple core computing, many tasks may be run in parallel, even though the task may appear linear in the description here. For example, the pre-processing step on a tile may be run in parallel with another tile that has been pre-processed and currently undergoing solar analysis. 
     There is thus disclosed an improved solar energy computation and advising system. It will be appreciated that numerous changes may be made to the present invention without departing from the scope of the claims.