# Radiance's conventions on locational information

I believe this is correct, yes.

···

--
Randolph

On 2011-08-11 09:14:49 -0700, Ji Zhang said:

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
_______________________________________________
[email protected]

Hi:

Gensky will not check whether the date is outside the DST period or not.
Even if you specify a data that is outside a DST time period, gensky will
still apply the hour shift.

Regards,

Jia

···

On Thu, Aug 11, 2011 at 3:11 PM, Christopher Rush <[email protected] > wrote:

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

_______________________________________________