ADQL geometry types

[Patrick Dowler]

I have just posted an update to WD-DALI-1.1 with what I think is now a
complete set of xtype values and serialisation rules (essentially
using VOTable arrays of numbers).

The next WD-TAP-1.1 makes use of DALI-1.1 xtypes and serialisation in
it's description of geometric values for use in TAP; this completely
replaces the non-normative STC-S usage that was in TAP-1.0 and thus
relegates coordinate system metadata back to the metadata section
where it belongs.

The implication of this is that I think ADQL should support the value
types as defined in DALI and I'd like to see these changes:

1. Deprecate COORDSYS function; no replacement.

2. Deprecate REGION; no replacement. This means that ADQL and TAP will
no longer support that highly problematic polymorphism within columns
(e.g. columns that can contain a mix of circles and polygons -- only
concrete types) and no more string manipulations or conversions.

3. Overload POINT, CIRCLE, and POLYGON with versions that lack the
coordinate system argument. Deprecate the old versions of these
functions.

A related issue w.r.t. WD-DALI-1.1:

4a. Deprecate BOX; no replacement.

4b. Overload BOX with a version that lacks coordinate system metadata
*and* define it in DALI.

4c. Define a range-valued function (COORDRANGE?) in ADQL.

BOX and range (concept used in SIA-2.0) differ and DALI does not
currently define either... no one really spoke up for range in DALI
discussions and some spoke out against it in SIA-2.0 discussions, but
it remained in SIA-2.0... I am in favour of leaving range out of DALI.
I would prefer 4a since the value of BOX exceeds the complexity.

-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada