[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.

 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?
 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.


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