I looked through the trig functions in SQL (all radians as far as I can tell) and since there are DEGREES and RADIANS functions for converting, I think it is a given that SIN, COS, etc use radians.
But then we have to decide if the geometry "constructors" take radians or degrees. Radians are really not user-friendly and I am pretty uncertain about which would be better. It has to be explicit, for sure, and it is a matter for the ADQL definition rather than a TAP (or other) service metadata to specify it. The point of ADQL/s is that expert users could use it the same way they use SQL: type in a query and execute it!
Also, astronomical name resolvers return sexigessimal or degrees and never radians, so we seem to be on the boundary here...
--
As for Mark Taylor's comment about legal ranges, it seems that DB trig functions do range-reduction in some cases and fail in others (in my tests). However, with long/lat it is only safe to do it for longitude (because it wraps around independent of latitude).
So, we should specify the legal ranges, where I think [0,360] and [-90,90] are the sensible choices. For simplicity, we should say that using values outside these ranges is an error.
If a specific service is non-compliant with that by performing range-reduction I don't think it will break anything. That puts us in the same state as with the built in trig functions (which may behave inconsistently and I don't expect service providers to catch and map those inconsistencies).
--
Patrick Dowler
Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2008-05-14Z22:22:31