Re: [GRASS-user] r.sun problem
dorothee spindelndreher wrote: You are right, I havent recognized the wrong shaddow at the southernmost building you have a good eye. I have realized that the shaddow at the edges seems to be deplaced more than in the middle of the area. But I hoped to change that by using a buffer around my area? the buffer should at least be big enough to include important shadowing features on the horizon, although just at sunrise/set the projected radiation at any sq m is so low that you don't really have to go as far as the visible horizon. ( km = sqrt(13*tallest building height above ground in meters) ) I am using the slope and aspect seed maps and not r.horizon. It will take longer, but you might try without those and see if it improves. I thought I could get the best results by simulating every 0.5 hour from sunrise to sunset every 10th day. see the r.sun wiki page re. showing effects of using 1/2 hour vs. 3 minutes step= size for Mode 2 (daily sums). I would start by getting one day working well before moving on to looking at doing the full year. You might want to install GRASS directly using the native WinGrass installer, then in the MSys terminal run it in a loop for each day: http://grass.osgeo.org/wiki/R.sun#Automation that might save you a bit of work if you have to run the module many times by hand :) One trouble with that loop trick is to feed it a changing linke number as the days go by. In the past to solve that I wrote a little program which you would give it the day-of-year and it would return a linke value interpolated from the yearly table. I've just ported it to Python and put it up on the grass-addons site. It's linked from the above wiki page. I have a LIDAR DSM with a resolution of 1x1m and using QGis just for the visualisation and running the comands with GRASS (Txt) box. Before that I used the Grass shell (in QGis 1.0.0). The command line I am using is the one proposed in the shell box: proposed by who/where? r.sun -s elevin=dsm slopein=dsm_slp aspin=dsm_asp day=5 lin=3.9 alb=0.2 beam_rad=beam5 diff_rad=diff5 refl_rad=refl5 insol_time=insol5 do you recomand me to use additional inputs parameter? try removing slopein= and aspin= and setting the step size to 0.05 (this will take 10 times longer, but the results will be nicer) Someone has compiled r.sun2 but it didnt make any difference. The results vary a bit but the shaddow is pretty the same. I am not sure if I use the newest svn version. I downloaded it [http://download.osgeo.org/qgis/win32/QGIS-1.0.2-0-Setup.exe] a few days ago and it is decribed as 6.4.0 svn (2009). I was a bit wondering why I have 3 more Icons on my Desktop now. So I guess it is pretty new. r.sun2 doesnt exit there. r.sun2 is just a designation in the source code, to the user the name is still the same r.sun. 6.4.0 uses the new version. anyway I don't think this is the issue and you can mostly ignore the r.sun versus r.sun2 stuff, especially if you are running modern QGIS/GRASS versions. What do you mean by avoiding the slope and aspect bug and testing *it? Are you talking about the GRASS version or the modul r.sun? the r.sun module; see bug report linked from prior email. It is just something to try, I do not know if it will pay or not. Has been in the older one an aspect and slope bug?? yes, but it is still there in the new version you use those options, but in the old version you had no choice you had to used them. I am not sure how much of a difference it really makes. So do you recomand me to use r.horizon in the newest version? it sounds like you are using a modern enough version. No, I do not recommend to use r.horizon until you fix the other problems first. It is mostly useful if you want to speed things up, but at the cost of accuracy. see the bug report notes. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sun problem
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 problemI 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
Re: [GRASS-user] r.sun problem
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, Hamishhamis...@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 problemI 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sun problem
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
