[GRASS-user] error in r.sun with latin and longin maps

Hamish hamish_b at yahoo.com
Wed Jul 4 17:23:19 PDT 2012


Hamish wrote:
> ...
> > don't use the latin= and lonin= options. You don't need
> > them from a UTM source location, the values will be
> > calculated automatically. (which turns out to be no slower
> > than reading them off the disk)
Markus N:
> I'd suggest to disactivate them (make them "fake" along
> with a G_message() ) since this comes up regularly. Likewise 
> for other unneeded options of r.sun.

I threw the "UTM" in my comment as I'm not sure if you might
need them for other map projections where reverse projection is
not possible on-the-fly. Maybe it's ok, I haven't looked into it
deeply, but it needs to be verified before removing them.
Perhaps r.sun is not too interesting for mainly cartographic
projections like Winkel Tripel, but it may be quite interesting
to run it in e.g. high latitude polar stereographic regions
(is that projection reversible?).

wrt aspect and slope input maps the jury is still out/confused
on which cases are buggy or not. Seems both ways might be buggy
for different cases, and maybe it's a situation where all native
map resolutions and the current region resolution must match?
More work is needed here to figure that out..

My main priorities for r.sun are to get the slope and aspect map
issues understood+resolved, starting with the re-simplified (&
OpenCL'able) version of things in trunk.

see also
  http://grass.osgeo.org/wiki/R.sun#Seed_maps
  https://trac.osgeo.org/grass/ticket/498#comment:14


cheers,
Hamish


More information about the grass-user mailing list