# Radiance's conventions on locational information

May I confirm with you that in Radiance there're several conventions
regarding some of the locational information should be specified:

*1. Longitude east of Greenwich* is specified as *NEGATIVE *value: e.g
Singapore's longtitude of 104E should be specified as -104.
*2. A positive azimuth angle *denotes an angle starting from *due SOUTH *and
rotating clockwise.
*3. Standard meridian* of a city equals to the Greenwich Mean Time of the
city multiplied by 15, and a *NEGATIVE *value indicates a timezone *EAST *of
Greenwich (e.g. Singapore belongs to the EAST8 timezone, so it's meridian is
-120=(8*15)*(-1) )

Take London as an example, to know the solar altitude and azimuth at 9:00am
1st Jan at London (altitude 51.15N and longitude 0.18W), the gensky command
is: "gensky 1 1 9:00GMT -a 51.15 -o 0.18 -m 0" or "gensky 1 1 9:00 -a 51.15
-o 0.18 -m 0"

and you'll get:

# gensky 1 1 9:00GMT -a 51.1500015259 -o 0.180000007153 -m 0
# Local solar time: 8.93
# Solar altitude and azimuth: 5.5 -41.8
# Ground ambient level: 6.0
......

and in this case the solar azimuth thus obtained indicates an angle starting
from *due South* and rotating *clockwise *for 41.8 degree.

Thanks!

Ji

I think if you specify the time with a time zone designation like GMT, the -m parameter is ignored.

the gensky command is: "gensky 1 1 9:00GMT -a 51.15 -o 0.18 -m 0" or "gensky 1 1 9:00 -a 51.15 -o 0.18 -m 0"

I have always assumed (but would like to confirm and open for discussion), if you give a date that is outside of the daylight savings time period (say January) but give a time of 9:00BST, would it incorrectly apply the 1 hour offset? In other words, the user or script must manually determine for the date in question, if the time should be given on the command line as 9:00GMT or 9:00 BST.

ยทยทยท

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses