[GRASS-dev] r.sun and pj_do_proj() calls

[Hamish]

Yann Chemin wrote:
> > to make things faster (and maybe more consistent), it
> > may just be better to have lat and long rasters as input
> > to r.sun, instead of repeatingly calling for a function
> > to convert them.

it already has that, with the latin= and lonin= options.

It is my intention to remove those two options from r.sun in
trunk, as it turns out that the overhead of reading the
additional two maps and resampling them by libgis is on par
with just doing the proj calc on the fly (at least in my very
few tests). simple_xy location users speak up now if there's
some reason not to do that.

see http://grass.osgeo.org/wiki/R.sun
and https://trac.osgeo.org/grass/ticket/498

(but trac is broken right now due to server migration)

latin/lonin maps needlessly complicate the module + workflow
for very little gain.


Seth:
> I think that's the best solution for
> the OpenCL code I'm working on. However, with the normal
> code, computing the lat/long as needed may take less time,
> RAM, and hard drive space then pre-computing it. So either
> situation may be better, depending on how the code is run.

If we can figure out a way to do it without those maps it would
be better. :) but for now they are there so don't let it be a
blocker for your SoC efforts as the summer is short.


but... I see the input and output projection variables are
swapped in com_par(): the function is *reverse* projecting
from lat/lon back to Cartesian space, presumably so that the
sqrt(a^2+b^2) distance calc is done on axes of equal scale.

but maybe that trig could be fixed up and the dx dy trick to
find the displacement angle improved/replaced..?

(see one of the ps.map wiki page examples where it shows how
to get gedesic convergence angle using proj4 code [implemented
as 'g.region -n' (has memory bug!)] instead of the dx,dy offset
trick)


also note long-standing todo:
"""
Probably the sun position calculation should be replaced with 

 G_calc_solar_position()

currently used in r.sunmask. G_calc_solar_position() is based on
solpos.c from NREL and very precise.
"""


rsunlib.c is new for "r.sun2"; module history for earlier r.sun
can be found in svn in the grass6.5 raster/r.sun/ dir not the
g65 raster/r.sun2/ dir. (and earlier grass5 history in the old
cvs as pointed out by Paul; in trunk r.sun2/ is renamed r.sun/). 

(we are smarter about correct svn merging now, but that one
got past so the change history got split)


regards,
Hamish