REGION

Here is our current thinking on region, in BNF (disclaimer: not a bnf expert :-). Basically, we agreed to the functional representation since the difference between it and an operator is largely cosmetic (if you will re-write ADQL -> SQL) but it is also directly implementable. We also went with REGION as a type (so you have functions with regions as args and you can have a column of type region). POINT is not a type at this time.

In SQL terms REGION is a BLOB or BINARY and the region literals can be implemented as functions that return such a value, so this fits in standard SQL quite well.

We have defined <coordsys> as a small list of constants only. ICRS and GAL satisfy 98% of the uses since clients can convert from other equatorial systems trivially and converting from ecliptic requires also knowing the time. How we do this is a minor issue... could just be a string and a TAP capability to understand coordsys transformations.

Alex and Pat

--

!! region is a type: column or literal
<region> ::= <column_reference> | <region_literal>

<region_literal> ::= <circle> | <rectangle> | <polygon> | <region_stc>

<coordsys> ::= <column_reference> | <coordsys_literal>

<coordsys_literal> ::= ICRS | GAL

!! CIRCLE(coordsys, longitude, latitude, radius)
<circle> ::= CIRCLE <left_paren> 


	<coordsys> 

	<comma> <numeric_value_expression> 

	<comma> <numeric_value_expression> 

	<comma> <numeric_value_expression> 

	<right_paren>


!! RECTANGLE(coordsys, long1, lat1, long2, lat2)
<rectangle> ::= RECTANGLE <left_paren> 


	<coordsys> 

	<comma> <numeric_value_expression> <comma> <numeric_value_expression> 

	<comma> 	<numeric_value_expression> <comma> <numeric_value_expression> 

	<right_paren>


!! POLYGON(coordsys, long1, lat1, long2, lat2, long3, lat3, ...)
!! eg. 3 or more vertices, implicit closing of the last segment
!! does not explicitly state the winding direction (a la postgres)
<polygon> ::= POLYGON <left_paren> 


	<coordsys> 

	<comma> <numeric_value_expression> <comma> <numeric_value_expression> 

	<comma> 	<numeric_value_expression> <comma> <numeric_value_expression> 

	<comma> 	<numeric_value_expression> <comma> <numeric_value_expression> 

	[ <comma> <numeric_value_expression> <comma> <numeric_value_expression> ...]


	<right_paren>


!! REGION(stc_string_representation)
!! actually putting an STC string into ADQL has all kinds of escaping issues
!! since it undoubtedly contains SQL reserved characters like ' and "
<region_stc> ::= REGION_STC <left_paren> 


	<character_value_expression> 

	<right_paren>


!! region_predicate needs to be included in <predicate>
<region_predicate> ::= <contains_predicate> | <intersects_predicate>

!! boolean CONTAINS(r, coordsys, longitude, latitude)
<contains_predicate> ::= CONTAINS <left_paren> 


	<region>

	<comma> <coordsys> 

	<comma> <numeric_value_expression>

	<comma> <numeric_value_expression> 

	<right_paren>

	
!! boolean INTERSECTS(r1, r2)
<intersects_predicate> ::= INTERSECTS <left_paren> 


	<region> <comma> <region> 

	<right_paren>


!! double AREA(r) 
!! include in <numeric_value_function>
<area> ::= AREA <left_paren> <region> <right_paren>

!! allowed formats for converting region to strings in select
!! default should be ADQL
!! ADQL would be any suitable <region_literal>
!! STC would be the STC representation without the REGION_STC() around it
<format> ::= STC | ADQL

!! string TO_CHAR(region, format)
<to_char> ::= TO_CHAR <left_paren> <region> <comma> <format> <right_paren>



-- 

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.)