[GRASS-user] r.sun problem

[Hamish]

dorothee spindelndreher wrote:
> You are right, I havent recognized the wrong shaddow at the
> southernmost building.... you have a good eye. I have
> realized that the shaddow at the edges seems to be deplaced
> more than in the middle of the area. But I hoped to change
> that by using a buffer around my area?

the buffer should at least be big enough to include important shadowing
features on the horizon, although just at sunrise/set the projected
radiation at any sq m is so low that you don't really have to go as far
as the visible horizon. ( km = sqrt(13*tallest building height above
ground in meters) )

> I am using the slope and aspect seed maps and not r.horizon.

It will take longer, but you might try without those and see if it improves.


> I thought I could get the best results by
> simulating every 0.5 hour from sunrise to sunset every 10th
> day.

see the r.sun wiki page re. showing effects of using 1/2 hour vs.
3 minutes step= size for Mode 2 (daily sums). I would start by getting
one day working well before moving on to looking at doing the full year.

You might want to install GRASS directly using the native WinGrass
installer, then in the MSys terminal run it in a loop for each day:
   http://grass.osgeo.org/wiki/R.sun#Automation

that might save you a bit of work if you have to run the module many
times by hand :)

One trouble with that loop trick is to feed it a changing linke number
as the days go by. In the past to solve that I wrote a little program
which you would give it the day-of-year and it would return a linke
value interpolated from the yearly table. I've just ported it to Python
and put it up on the grass-addons site. It's linked from the above wiki
page.


> I have a LIDAR DSM with a resolution of 1x1m and using
> QGis just for the visualisation and running the comands with
> GRASS (Txt) box. Before that I used the Grass shell (in QGis 1.0.0).
>
> The command line I am using is the one proposed in the shell box:

proposed by who/where?

> r.sun -s elevin=dsm slopein=dsm_slp aspin=dsm_asp
> day=5 lin=3.9 alb=0.2 beam_rad=beam5 diff_rad=diff5
> refl_rad=refl5 insol_time=insol5
> 
> do you recomand me to use additional inputs parameter?

try removing slopein= and aspin= and setting the step size to 0.05
(this will take 10 times longer, but the results will be nicer)

 
> Someone has compiled r.sun2 but it didnt make any
> difference. The results vary a bit but the shaddow is pretty
> the same. I am not sure if I use the newest svn version. I
> downloaded it  [http://download.osgeo.org/qgis/win32/QGIS-1.0.2-0-Setup.exe] 
> a few days ago and it is decribed as 6.4.0 svn (2009). I was
> a bit wondering why I have 3 more Icons on my Desktop now.
> So I guess it is pretty new. r.sun2 doesnt exit there.

r.sun2 is just a designation in the source code, to the user the name
is still the same "r.sun". 6.4.0 uses the new version. anyway I don't
think this is the issue and you can mostly ignore the r.sun versus
r.sun2 stuff, especially if you are running modern QGIS/GRASS
versions.


> What do you mean by avoiding "the slope and aspect bug" and
> testing *it? Are you talking about the GRASS version or the
> modul r.sun?

the r.sun module; see bug report linked from prior email. It is just
something to try, I do not know if it will pay or not.


> Has been in the older one an aspect and slope bug??

yes, but it is still there in the new version you use those options,
but in the old version you had no choice you had to used them.
I am not sure how much of a difference it really makes.


> So do you recomand me to use r.horizon in the newest version?

it sounds like you are using a modern enough version.
No, I do not recommend to use r.horizon until you fix the other problems
first. It is mostly useful if you want to speed things up, but at the
cost of accuracy. see the bug report notes.


regards,
Hamish