Re: [GRASS-user] r.sunmask cast shadow question
On Sat, Jan 4, 2014 at 12:17 PM, Tim Michelsen wrote: ... > Perhaps r.sun.hourly should get ... > * average sunlight duration per day during a month, etc. (h/d) This needs some modifications in the r.sun code. I was discussing this issue some time ago with Jaro Hofierka who gave the following hints: On Thu, Apr 16, 2009 at 18:34, Jaro Hofierka wrote: > Markus, > > sunrise, sunset times are calculated for each cell, however, not including > shadows by surrounding terrain features. This would need another test which > in fact is done during radiation calculations (there is a time step to sum > up radiation), but the time is not stored. > To minimize a number of output maps we have stored the information of > sunrise/sunset times using min-max values in a history file (or a single > value when a single value of latitude is used for the map). So it would need > a modification of the code to put there extra files storing sunrise-sunset > times. If you need a quicker solution, you would need to make tests just for > a small part of the day (e.g. 1-2 hours around reported sunrise/sunset > times). > > Jaro Perhaps useful as a pointer. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sunmask cast shadow question
Am 04.01.2014 15:12, schrieb Vaclav Petras: > > > > On Sat, Jan 4, 2014 at 6:17 AM, Tim Michelsen > mailto:timmichel...@gmx-topmail.de>> wrote: > > Am 02.01.2014 23:13, schrieb Markus Neteler: > > You may consider r.sun as well in order to compute cast shadow. I > > played around with it recently, see > > http://courses.neteler.org/will-the-sun-shine-on-us/ > Thanks for sharing this. > > >Perhaps r.sun.hourly should get an additional flag to generate the > binary “sun-yes” – >“sun-no” maps directly. > Additionally, it would be nice to have a agregrate flaf > * sum up the daily/monthly/annual radiation (kWh/m^2) > * average sunlight duration per day during a month, etc. (h/d) > > Would r.sun.hourly and r.sun.daily help to satisfy these requests? > > http://grass.osgeo.org/grass70/manuals/addons/r.sun.hourly.html > http://grass.osgeo.org/grass70/manuals/addons/r.sun.daily.html > > > Where can such ideas be collected for GRASS addons? > In the normal bugtracker? > > > Never thought about that. It is an feature request, so I would put it to > bugtracker. If the reporter thinks that it should go to addons (and not > to main code) I added these isses but currently have not time to work on this: add flag for binary “sun-yes” – >“sun-no” output http://trac.osgeo.org/grass/ticket/2154 r.sun.hourly: add flag for aggregating a series of output files http://trac.osgeo.org/grass/ticket/2155 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sunmask cast shadow question
On Sat, Jan 4, 2014 at 6:17 AM, Tim Michelsen wrote: > Am 02.01.2014 23:13, schrieb Markus Neteler: > > You may consider r.sun as well in order to compute cast shadow. I > > played around with it recently, see > > http://courses.neteler.org/will-the-sun-shine-on-us/ > Thanks for sharing this. > > >Perhaps r.sun.hourly should get an additional flag to generate the > binary “sun-yes” – >“sun-no” maps directly. > Additionally, it would be nice to have a agregrate flaf > * sum up the daily/monthly/annual radiation (kWh/m^2) > * average sunlight duration per day during a month, etc. (h/d) > > Would r.sun.hourly and r.sun.daily help to satisfy these requests? http://grass.osgeo.org/grass70/manuals/addons/r.sun.hourly.html http://grass.osgeo.org/grass70/manuals/addons/r.sun.daily.html > Where can such ideas be collected for GRASS addons? > In the normal bugtracker? > Never thought about that. It is an feature request, so I would put it to bugtracker. If the reporter thinks that it should go to addons (and not to main code), he or she can write this to ticket description (trac component 'Addons' is appropriate). However, the reporter is not obliged to know or decide if main code or addons are appropriate. Vaclav > > Kind regards, > Timmie > > ___ > 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.sunmask cast shadow question
Am 02.01.2014 23:13, schrieb Markus Neteler: > You may consider r.sun as well in order to compute cast shadow. I > played around with it recently, see > http://courses.neteler.org/will-the-sun-shine-on-us/ Thanks for sharing this. >Perhaps r.sun.hourly should get an additional flag to generate the binary “sun-yes” – >“sun-no” maps directly. Additionally, it would be nice to have a agregrate flaf * sum up the daily/monthly/annual radiation (kWh/m^2) * average sunlight duration per day during a month, etc. (h/d) Where can such ideas be collected for GRASS addons? In the normal bugtracker? Kind regards, Timmie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sunmask cast shadow question
On Mon, Dec 2, 2013 at 10:47 PM, wrote: > Please allow me to answer my own request: based on further analysis on basic > synthetic terrain models, I figured out that r.sunmask will only work on a > projected > framework. Hence, I re-projected the WGS-84 DEM obtained from SRTM and indeed > managed > to get meaningful cast shadow representations. > > I quickly summarized some of my experiments (using GRASS 6.4.3-2 as a plugin > to QGis 2.0.1) > at http://jmfriedt.free.fr/proj_grass/projection.html which might (or might > not) be useful > to others. Thanks for writing that up! You may consider r.sun as well in order to compute cast shadow. I played around with it recently, see http://courses.neteler.org/will-the-sun-shine-on-us/ (maybe you have seen that already posted around) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sunmask cast shadow question
Please allow me to answer my own request: based on further analysis on basic synthetic terrain models, I figured out that r.sunmask will only work on a projected framework. Hence, I re-projected the WGS-84 DEM obtained from SRTM and indeed managed to get meaningful cast shadow representations. I quickly summarized some of my experiments (using GRASS 6.4.3-2 as a plugin to QGis 2.0.1) at http://jmfriedt.free.fr/proj_grass/projection.html which might (or might not) be useful to others. JM - Mail original - De: "friedtj" À: grass-user@lists.osgeo.org Envoyé: Lundi 28 Octobre 2013 11:14:43 Objet: [GRASS-user] r.sunmask cast shadow question I am attempting to use r.sunmask to identify the time at which an oblique-view picture was taken from a webcam in a mountain area by trying to match the projected shadow pattern. I thus first compute the elevetion/azimuth of the sun for my location (as provided by the USNO web site) and the use the A-mode projection of r.sunmask to observe the shadow pattern. I was surprised to observe litte (or actually no) effect of the sun elevation on the cast shadow pattern, so I tried the following synthetic example: a DEM is defined by the following elevation file north: 0.5 south: -0.5 east:0.5 west:-0.5 rows:10 cols:10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2000 2000 0 0 0 0 0 0 0 2000 5000 5000 2000 0 0 0 0 0 0 2000 5000 5000 2000 0 0 0 0 0 0 0 2000 2000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 which is inserted on a GRASS region centered around (0,0) and hence wih a 12.3 km cell size (111 km/9 cells). The resulting DEM is also found at http://sequanux.org/jmfriedt/t/sun1.png My synthetic mountain is 5000 m high in the first cell which hence exhibits a slope of 22 degrees, and the second half of the mountain rises by 2000 m over another cell so exhibits a slope of 10 degrees. The average tilt of the whole mountain slope spanning two cells is 11 degrees. I then generate the sun mask using r.sunmask for sun elevations of 20 and 40 degrees and different azimuths to differenciate the simulations (as found at http://sequanux.org/jmfriedt/t/sun2.png -- both png files also come with an associated world file): the 20-degree case should cast a shadow by the steepest slope, and the 40 degree elevation should not cast any shadow at all. As observed on the picture, a shadow is always cast all the way to the limit of my DEM, which seems incorrect if we are indeed looking at the projected shadow due to the topography. Any sun elevation above 22 degrees should not generate any cast shadow pattern, and I went up to testing a sun elevation of 89 degrees which also generated a cast shadow all the way to the limit of my DEM. Am I misunderstanding how to use r.sunmask ? Somehow r.sun does not seem to be working on my installation so I am unable to compare both outputs. All this was done with GRASS 6.4 called from QGis 2.0.1. Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France ___ 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
