[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn
history
GRASS GIS
trac at osgeo.org
Mon Aug 10 23:57:32 EDT 2009
#498: r.sun2 out of sync / broken svn history
---------------------+------------------------------------------------------
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.sun
Platform: Linux | Cpu: x86-32
---------------------+------------------------------------------------------
Comment (by hamish):
I have been doing some experiments with r.sun + a simple gaussain mound as
the elevation:
{{{
g.region -d # spearfish dataset region
r.surf.volcano gauss method=gaussian # module from addons
DAY=355 # longest shadows
}}}
I have looked at the effect of using r.horizon and slope/aspect maps.
setup:
{{{
r.horizon elev=gauss horizonstep=30 dist=0.7 horizon=horangle
r.slope.aspect elevation=gauss aspect=guass.aspect slope=guass.slope
}}}
Q1) how small must the horizonstep be to recreate the beam_rad output map
effectively as good as e.g. seen in the r.sun wiki page example?
http://grass.osgeo.org/wiki/r.sun
By using a 30deg angle step are we trading time/maps for accuracy?
For some reason the lower east wing of the butterfly pattern is stunted
using that.
Running tests with horizonstep=1 degree now.
Q2) am I using aspin= correctly? should that be a map created by
r.slope.aspect? Using it the processing speeds up by 3x, but the results
seem a bit weird -- to the south of the mound is a depression in the light
which while possible for reflected light seems that it would be "upstream"
& incorrect for beam_rad.
defining a slopein= map (from r.slope.aspect result) doesn't change the
processing time appreciably. I haven't tested for its effect on the output
map yet.
?
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/498#comment:7>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list