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)
On Wed, Jun 27, 2012 at 11:13 PM, Hamish <hamish_b@yahoo.com> 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)
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.
...
> 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.