I would just freeze the units in degrees, and square degs for area. This
removes the uncertainty,
and make queries consistent. It would be the query writer's responsibility
to examine the units
used if the ra,dec are derived from a table. In cartesian we could specify
that the vectors be
normalized.
I agree with everything else.
--Alex
-----Original Message-----
From: owner-voql-teg-at-eso.org [mailto:owner-voql-teg-at-eso.org] On Behalf Of
Patrick Dowler
Sent: Friday, May 30, 2008 1:13 PM
To: Jeff Lusted
Cc: voqlteg
Subject: Re: Spec (BNF) changes parallel to the RFC: BOX, and ELLIPSE
On 2008-5-30 00:37, Jeff Lusted wrote:
> <box> ::=> <comma> <numeric_value_expression>
> BOX <left_paren> <coord_sys>
> <comma> <coordinates>
> <comma> <numeric_value_expression>
BOX looks fine.
I am still thinking about ellipse. So far I count 1 vote for (Francois), 1 vote against for technical reasons (Alex), 1 vote for against for cautious/procedural reasons (Pat)...
(applies to all the geometry_expressions) We should be careful when
specifying
limits: it is only in spherical coordinates that the values are limited. In
a cartesian coordinate system, there are no limits.
For spherical coordinate values, limits should nominally be [0,360] and [-90,90]. However, it seems that the coordinate system defines (or should) these limits already and by deferring to the coordinate system definition we could also accommodate systems that naturally have other limits (like 0,360 and 0,180). In cartesian coordinates, there are no inherent limits; this needs to be clear in the document.
We also should specify that in spherical coordinates the units are always degrees (or sq. deg for AREA) but in a cartesian coordinate system our only choice is to similarly limit this to spatial coordinates and thus chose a unit of length like m (meters). We already have 2d spherical that is strictly spatial already, so that is at least consistent.
Alternatively, we could follow what we do for scalar columns and not specify the units anywhere. The user would be required to examine the metadata for the spatial content in the DB and use the appropriate units (which they have to do for scalar columns) in their constant/literal values. This does not really add any burden on the user and it also covers the cartesian cases. The only funny one is to specify that AREA returns a value in units derived from the unit of the argument (without saying what that is).
This might be too much of a departure from the process at this stage, but that depends totally on what is in the current PR, Since we are answering Mark Taylor's comment about units for arguments, it could be a clarification of the fact we did not specify units and what that means. Thoughts?
-- 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-30Z19:21:19