ADQL geometry types

[Alex Szalay]

The REGION was the object which made the whole construct a mathematically closed algebra.
So this means that ADQL will remain an ad hoc mishmash of certain geometry type.
This will also mean that the internal geometry representations of major existing surveys like 
SDSS, GALEX, HST, HLA will be incompatible with ADQL. 

Draw your own conclusions what the outcome will be.

--Alex

-----Original Message-----
From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of Patrick Dowler
Sent: Thursday, April 14, 2016 6:09 PM
To: <dal at ivoa.net> <dal at ivoa.net>
Subject: ADQL geometry types

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