[GRASS-user] r.sun problem

GRASS GRASS user
1

Hi all.

I am using r.sun -s to calculate solarmaps for each month. I wrote a shell script which calculates every 10th day (including the shaddowing effect). But something is going wrong. I looks like the shaddows are displaced somehow (see attachement). Using r.sun2 -s didnt make any difference.
Curiously once it worked! But although I'm using the same projection, location, mapset and DSM - it doesnt work anymore.

I hope anybody could help me out or have any ideas how I could solve this problem....I really need these maps.

Thanks in advanced!
  
Regards
Doro
  
I am using Quantum Gis Version 1.0.2 and GRASS 6.4.0 svn
  
The region of my investigation area is:

$ g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232
ellipsoid: bessel
north: 281981.20714553
south: 281612.20714553
west: -29172.52857137
east: -28383.52857137
nsres: 1
ewres: 1
rows: 369
cols: 789
cells: 291141

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

(attachments)

r.sun_shaddow.pdf (73.1 KB)

2

Hi,

I am using r.sun -s to calculate solarmaps for each month.
I wrote a shell script which calculates every 10th day
(including the shaddowing effect). But something is going
wrong. I looks like the shaddows are displaced somehow (see
attachement). Using r.sun2 -s didnt make any difference.
Curiously once it worked! But although I'm using the same
projection, location, mapset and DSM - it doesnt work
anymore.

I hope anybody could help me out or have any ideas how I
could solve this problem....I really need these maps.

.....

I am using Quantum Gis Version 1.0.2 and GRASS 6.4.0 svn

The region of my investigation area is:

$ g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum:
towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232
ellipsoid: bessel
north: 281981.20714553
south: 281612.20714553
west: -29172.52857137
east: -28383.52857137
nsres: 1
ewres: 1
rows: 369
cols: 789
cells: 291141

could you provide the exact command line you were using?
are you using r.horizon seeds, or slope and aspect seed maps?
what time step?

By chance I noticed in xpdf if I dragged with the left mouse
button instead of the middle one (to pan) I got an inverse
image which made the effect a bit clearer. With that I notice
that the center-southmost building in the "ok" map actually
isn't.

how do you run the two different versions? did you compile the
old one? is this the latest SVN? (like younger than a week?)
is QGIS only used for visualization or do you run grass from
the toolbox?

lately we have been running some tests with it*, but in general
I think the new version (ie really upgrade) is in fact better
than the old, if just because you can avoid the slope/aspect
bug now.

[*] see http://grass.osgeo.org/wiki/r.sun
and https://trac.osgeo.org/grass/ticket/498

building shadows is something I'd always wanted to try with
r.sun, interesting to see some results! May I ask if it is
LIDAR elevations or simply by e.g. number of storeys?

also, may I suggest "r.colors map color=grey -e", where the -e
flag may help mute the contrasts a bit.

Hamish

3

All this recent talk about bugs in r.sun / r.sun2 has made me a bit
concerned about recent research built on r.sun. Should I be concerned
about incorrect results from r.sun when supplied with an aspect +
slope map, as run on GRASS 6.4, about 2 years ago?

Thanks,

Dylan

On Sat, Aug 22, 2009 at 6:56 AM, Hamish<hamish_b@yahoo.com> wrote:

Hi,

I am using r.sun -s to calculate solarmaps for each month.
I wrote a shell script which calculates every 10th day
(including the shaddowing effect). But something is going
wrong. I looks like the shaddows are displaced somehow (see
attachement). Using r.sun2 -s didnt make any difference.
Curiously once it worked! But although I'm using the same
projection, location, mapset and DSM - it doesnt work
anymore.

I hope anybody could help me out or have any ideas how I
could solve this problem....I really need these maps.

.....

I am using Quantum Gis Version 1.0.2 and GRASS 6.4.0 svn

The region of my investigation area is:

$ g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum:
towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232
ellipsoid: bessel
north: 281981.20714553
south: 281612.20714553
west: -29172.52857137
east: -28383.52857137
nsres: 1
ewres: 1
rows: 369
cols: 789
cells: 291141

could you provide the exact command line you were using?
are you using r.horizon seeds, or slope and aspect seed maps?
what time step?

By chance I noticed in xpdf if I dragged with the left mouse
button instead of the middle one (to pan) I got an inverse
image which made the effect a bit clearer. With that I notice
that the center-southmost building in the "ok" map actually
isn't.

how do you run the two different versions? did you compile the
old one? is this the latest SVN? (like younger than a week?)
is QGIS only used for visualization or do you run grass from
the toolbox?

lately we have been running some tests with it*, but in general
I think the new version (ie really upgrade) is in fact better
than the old, if just because you can avoid the slope/aspect
bug now.

[*] see http://grass.osgeo.org/wiki/r.sun
and https://trac.osgeo.org/grass/ticket/498

building shadows is something I'd always wanted to try with
r.sun, interesting to see some results! May I ask if it is
LIDAR elevations or simply by e.g. number of storeys?

also, may I suggest "r.colors map color=grey -e", where the -e
flag may help mute the contrasts a bit.

Hamish

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

4

Dylan:

All this recent talk about bugs in r.sun / r.sun2 has made me
a bit concerned about recent research built on r.sun. Should I
be concerned about incorrect results from r.sun when supplied
with an aspect + slope map, as run on GRASS 6.4, about 2 years
ago?

short answer: probably they are fine, but I will run some
checks to quantify that.

I am mostly focusing in on the problems on purpose, in pursuit
of the last 2-3% and to figure out what are the best time vs.
quality choices for using or not using the seed maps. e.g. by
using r.horizon maps you can reduce the processing time from
4:30 to 0:30, but at the cost of quality. Also the more horizon
maps the better quality, but if you make 1 for each degree of
the compass that's 360 maps and due to the cost of loading them
all the time to complete starts to rise again. .... as always,
life's a compromise.

Many of the screenshots I've made use the r.colors -e flag
to highlight detail. often the artifacts that show up in that
will be mostly hidden as noise when considering the map in its
entire range. ie it is very likely to fall within the margin of
error & limits of the input data.

I've already figured out that the lat and long seed maps only
save you about 1-2% over just using the internal proj.4
calculation, so I am considering removing those to simplify
the already complex code. I am doubtful of real world cases
using the module in a simple XY location with real lat/lon
seed maps. I don't see the utility in it.

Hamish