[GRASS-user] r.sun problem

[Hamish]

Dylan:
> All this recent talk about bugs in r.sun / r.sun2 has made me
> a bit concerned about recent research built on r.sun. Should I
> be concerned about incorrect results from r.sun when supplied
> with an aspect + slope map, as run on GRASS 6.4, about 2 years
> ago?

short answer: probably they are fine, but I will run some
checks to quantify that.

I am mostly focusing in on the problems on purpose, in pursuit
of the last 2-3% and to figure out what are the best time vs.
quality choices for using or not using the seed maps. e.g. by
using r.horizon maps you can reduce the processing time from
4:30 to 0:30, but at the cost of quality. Also the more horizon
maps the better quality, but if you make 1 for each degree of
the compass that's 360 maps and due to the cost of loading them
all the time to complete starts to rise again. .... as always,
life's a compromise.

Many of the screenshots I've made use the r.colors -e flag
to highlight detail. often the artifacts that show up in that
will be mostly hidden as noise when considering the map in its
entire range. ie it is very likely to fall within the margin of
error & limits of the input data.

I've already figured out that the lat and long seed maps only
save you about 1-2% over just using the internal proj.4
calculation, so I am considering removing those to simplify
the already complex code. I am doubtful of real world cases
using the module in a simple XY location with real lat/lon
seed maps. I don't see the utility in it.


Hamish