top of page

Solar Radiation Conclusion

 

There are several problems we encountered in the duration of this project:

​

​

​

When calculating solar radiation, our output raster always had a striping pattern to it. No matter how we split the data, this effect could be noticed. Below is a list of things we tried and how we eventually solved this issue.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

  • Using Condor, we divided the jobs into 6 rows and 100 columns with a buffer of 600 meters around each edge. For solar radiation parameters, we used a 1 day and 1 hour time interval for the entire year. We also used a sky size of 200 and we did not input a value for the latitude. From this approach, the results that were returned have a striping effect. (image 1)

 

  • From the same approach as above we tried manually putting in an approximated average latitude value of 34 for the entire state instead of using the tool’s calculated value. It yielded a much more visually pleasing result. (image 2)

​

  • We followed a recommendation from ERSI and split the data into one pixel sized rows (30 meters) resulting in 11,807 pieces, and left the latitude blank to be calculated by the tool. The resulting map was similar to the first image, but rather the striping effect was much finer than that one. During this process we experimented with different buffer sizes ranging from 600, 60, to 30. (image 3)

​

  • At the Univeristy of Minnesota's team's recommendation, we tried splitting data into 1km squared blocksand split our DEM into 100,561 pieces. However, this approach also resulted in a striped pattern. During the process of this approach, we discovered that GalaxyGIS can only take 20,000 jobs per submission and a user can only have 100,000 jobs active in the cluster.

​

  • After more contacts with Minnesota, they corrected themselves on using 10km squared blocks rather than 1km. From researching their code we know that they used a fishnet to split their data rather than split raster. From this new information we rewrote our code to be compliant with these new change, however, after splitting our jobs into 884 pieces and submitting them to the cluster, the striping effect in the result still remains.

 

  • We experimented with calculating each county with splitting and Condor then mosaic them back, but the striping is still present. The two counties we tried were Beaufort county and Colleton county

 

  • We tried running the SR tool on each county without splitting, but it still has the shading issue. Not to mention that each individual calculation took more than 4 hours to run.

 

  • We tried using the default settings for the solar radiation tool rather than the ones previously specified. We used 200 for sky size, 14 for time interval, whole year calculation, and 0.5 for hourly interval. This resulted in a much more visually pleasing result. We used the DEM of South Carolina for testing purposes, splitting the DEM into 100 rows. (image 4)

 

  • From the results above we can still see some striping effect. Then we tried to improve the results even more by dividing the DEM into pixel sized rows and the results are great. (image 5)

6 Rows, 100 Columns split

Striping Problem

Conclusion

What we learned was that a sky size of 200 is only recommended for day intervals of 14 and greater. When the day interval is decreased, the sky size must be increased, but this dramatically affects the processing time. For example, with a day interval of 1, a sky size of 2800 is recommended. This increased the processing time of each piece from about 5 min to 5+ hours. Also, the tool is only recommended to run on areas no greater than 1 degree latitude in height. We can get around this by splitting our data into rows with 1 pixel height, and processing them in pieces. When we merge the data back together, we get a smooth and accurate result.

DEM Inconsistencies

Below is a list of the various tools and methods we tried in order to smooth out and remove the inconsistencies from the DEM:

  • ​Fills and Sinks - Hydro tools - GIS Stack Exchange - This tool did not do much about the abnormality. It made a minimal amount of changes to the overall image, but could not get rid of the inconsistency.

​​

  • Build Seamlines - as per ESRI’s recommendation, we tried the Build Seamlines tool over the phone with the assistance of an ESRI analyst. Similar to the last tool, It also made minimal amount of changes to the overall image, and also cannot get rid of the inconsistency.

​​

  • ESRI also tried several approaches, they created a polygon for the white line area and then clipped that area to erase it from the original raster. They extracted the desired area (excluding the white patch area) from the original raster with the help of the extract by mask tool, converted the raster to point, and then executed the IDW tool. However, this too produced an output raster with the white patch. None of these approaches fixed the issues that we had.

​

  • The Filtering tool was able to remove the inconsistencies, but only after two runs of the tool. This result is too inaccurate for us to comfortably use as the basis for our project.

​

  • Focal Statistics Suggested by GIS Stack Exchange - This tool effectively removed all consistencies while minimally effecting the accuracy of the DEM.

​​

​

bottom of page