> Long time back I added the SOLPOS support in r.sunmask. > Do you have a pointer to the SPA source code? Because implementing it > from a 40 pages PDF is expensive :-)
Sorry about that. Hahaha. Here's the actual C code: https://www.nrel.gov/midc/spa/ > You may consider to tile the data (r.tile) with sufficient overlap, > then process these tiles in parallel. I was choosing between r.tile or simply setting smaller computational regions. If I use r.tile and process the tiles in parallel, I assume I would need to set a different computational region per tile? The workflow would go something like this: Per tile (in parallel) set the computational region using the tile -> run r.horizon -> run r.sun Also, do you think I should compute the horizon rasters per tile or as a whole? I tested it once and it was faster when I called r.horizon per tile. > Yes, here some pointers: > > Hofierka and Zlocha, 2012 > A New 3-D Solar Radiation Model for 3-D City Models > http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2012.01337.x/abstract > > 3-D city modeling for sustainable energy applications > http://web.science.upjs.sk/hofierka/projekty/vega2_results.html I'll look into this, thank you. > In case you are interested in some more parallel r.sun examples you may have a look here: > https://github.com/NINAnor/sentinel4nature/blob/master/r_sun_parallel.sh > The shell script (based on the content from the GRASS wiki) basically uses the tiling approach Markus was suggesting and applies r.sun > (and r.horizon) in parallel using xargs... > Since my DEM has a lot of NoData within it`s bounding box I droped all tiles not covered by the DEM and used v.mkgrid for the tiling > (instead of splitting the DEM itself (but now I see that r.tile might have been more efficient). Thank you for this. Do you think I can do the same in Python? I don't mind working in bash but most of those I work with aren't really familiar with shell scripting. Again, thank you all for the help. Cheers, Ben Hur -- *Engr. Ben Hur S. Pintor* *Research Associate* Phil-LiDAR 2 Project 5: REMap UP Training Center for Applied Geodesy and Photogrammetry *Juris Doctor* College of Law *University of the Philippines Diliman* Quezon City 1101, PHL On Thu, Apr 28, 2016 at 8:35 PM, Blumentrath, Stefan < [email protected]> wrote: > Hi Ben, > > In case you are interested in some more parallel r.sun examples you may > have a look here: > https://github.com/NINAnor/sentinel4nature/blob/master/r_sun_parallel.sh > > The shell script (based on the content from the GRASS wiki) basically uses > the tiling approach Markus was suggesting and applies r.sun (and r.horizon) > in parallel using xargs... > > Since my DEM has a lot of NoData within it`s bounding box I droped all > tiles not covered by the DEM and used v.mkgrid for the tiling (instead of > splitting the DEM itself (but now I see that r.tile might have been more > efficient). > > BTW, are overlapping tiles required, when r.horizon considers a > user-defined distance outside of the current region? > > Cheers, > Stefan > > -----Original Message----- > From: grass-dev [mailto:[email protected]] On Behalf Of > Markus Neteler > Sent: 28. april 2016 14:12 > To: Ben Hur Pintor <[email protected]> > Cc: GRASS-dev <[email protected]> > Subject: Re: [GRASS-dev] [r.sun] > > On Thu, Apr 28, 2016 at 1:48 PM, Ben Hur Pintor <[email protected]> > wrote: > > Thanks for the response. I've seen a lot of literature and uses of > > r.sun which is one of the reasons why I chose it as my model aside > > from the fact that it's open-source. However, most of the uses are > > European setting which I understand since r.sun is based on ESRA. I > > wanted to see how well r.sun performs in a more tropical setting and > > from my initial findings and studies, it seems to be doing pretty well. > > > > r.sun and r.sunmask both seem to use the SOLPOS algorithm, the SPA > > (http://www.nrel.gov/docs/fy08osti/34302.pdf) is a more recent solar > > positioning algorithm by NREL and is much more precise than SOLPOS so > > I wondered if using SPA instead of SOLPOS might provide better results. > > Long time back I added the SOLPOS support in r.sunmask. > Do you have a pointer to the SPA source code? Because implementing it from > a 40 pages PDF is expensive :-) > > > With regards to using LiDAR-derived raster data, my machine can > > actually handle it but it just takes a lot of time. I have a 1m > > resolution LiDAR of a > > 500 sq km area (~5GB) and it really just takes a lot of time and disk > > space > > -- specially for horizon rasters. I'm looking into parallel processing > > to remedy this issue. > > You may consider to tile the data (r.tile) with sufficient overlap, then > process these tiles in parallel. > > > Lastly, I would also like to go into 3D urban solar energy modelling > > which is why I asked about v.sun or any other attempts in GRASS to > > develop a model for solar radiation received by 3D objects (i.e. > > buildings including facades and roofs). > > Yes, here some pointers: > > Hofierka and Zlocha, 2012 > A New 3-D Solar Radiation Model for 3-D City Models > http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2012.01337.x/abstract > > 3-D city modeling for sustainable energy applications > http://web.science.upjs.sk/hofierka/projekty/vega2_results.html > > Hope this helps for a start, > Markus > > -- > Markus Neteler > http://www.mundialis.de - free data with free software > http://grass.osgeo.org http://courses.neteler.org/blog > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- *Engr. Ben Hur S. Pintor* *Research Associate* Phil-LiDAR 2 Project 5: REMap UP Training Center for Applied Geodesy and Photogrammetry *Juris Doctor* College of Law *University of the Philippines Diliman* Quezon City 1101, PHL
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
