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
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
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.
----- Mail original -----
De: "friedtj" <friedtj@free.fr>
À: 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
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
On Mon, Dec 2, 2013 at 10:47 PM, <friedtj@free.fr> 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.
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?
On Sat, Jan 4, 2014 at 6:17 AM, Tim Michelsen
<timmichelsen@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?
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.
On Sat, Jan 4, 2014 at 6:17 AM, Tim Michelsen
<timmichelsen@gmx-topmail.de <mailto:timmichelsen@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?
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)
On Sat, Jan 4, 2014 at 12:17 PM, Tim Michelsen
<timmichelsen@gmx-topmail.de> 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 <hofierka@geomodel.sk> 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).
