RE: Sessions at Trieste

From: Alex Szalay <szalay-at-jhu.edu>
Date: Thu, 15 May 2008 11:19:18 -0400


I think that our region description MUST be able to allow for small circle boundaries, contrary to the GIS definitions. This is a good example where astronomy has more precise needs than GIS. This will of course not be a usual spherical polygon, which contains only great circles, but a generalized spherical polygon, that we should call REGION.

STC/S can represent all this, so no problem as long as we stay with the STC region descriptor strings.

--Alex

-----Original Message-----
From: owner-voql-teg-at-eso.org [mailto:owner-voql-teg-at-eso.org] On Behalf Of Iņaki Ortiz de Landaluce
Sent: Thursday, May 15, 2008 10:54 AM
To: Jeff Lusted
Cc: Pedro Osuna; VOQL-TEG
Subject: Re: Sessions at Trieste

Hi all,
I know there are some other discussions going further on, but please let me jump back to the examination of Bob Hanisch's comments. I agree with all the points made by Jeff regardless of the correctness of his sample (that has triggered further discussions as well).

>Section 2.3.2.2.5.11
>I think someone else needs to answer this one. In my prosaic way, I
>think of a rectangle as polygon.

Regarding Bob's comment on Section 2.3.2.2.5.11, I believe he is right. Even in the simplest case where the coordinates of the corners are a combination of the min/max longitude and latitude values, the sides of equal longitude are not necessarily great circles (except the ones passing through the equator) and therefore a coordinate transformation will not turn them into a great circles. Therefore, assuming that a polygon is "denoted by great circles passing through specified coordinates"(*) he is right commenting that "Transforming a rectangle to another coordinate system will generally result in a polygon"(*) is not a valid statement. To keep it simple I would just take the last sentence on Section 2.3.2.2.5.11 out as I believe the syntax and semantics for the POLYGON and RECTANGLE sections are still valid.

Please let me know if you agree.
Regards
Iņaki

Note(*): Sentences are taken from the spec, sections 2.3.2.2.5.10 and 2.3.2.2.5.11.

Jeff Lusted wrote:
> Hi Colleagues!
>
> On Tue, 2008-05-13 at 10:30 +0200, Pedro Osuna wrote:
>
>> I would ask some of you to send me possible answers to the RFC
>> comments, as you have a better knowledge of the details. I will then
>> introduce them in the system and sign like, e.g., "Pat Dowler for the
>> VOQL-TEG, agreed by Chair", or something like that. Then, we could
>> eventually discuss them in Trieste.
>>
>
> This is my first experience of replying to RFC, so I'll be guided by
> Pedro and you of more experience (Please!). These are my comments on Bob
> Hanisch's points. They still need editing because I'm obviously
> soliciting opinions (yours!). I'll try and generate other replies over
> the next day or so. I haven't edited them into the page as I wanted to
> gauge your opinions first. Pedro and Inaki, do you want to control the
> editing, as I'm sure others may want to add/amend/expand/delete.
>
> I think first of all we should make the point that ADQL is a developing
> language. I don't think anyone on the TEG thought this would be the
> definitive release of the language. So, this current specification is a
> movement towards completion. Other, later versions will fill out the
> geometric and region side of things. We have to start somewhere.
>
> Section 1.
> I think we could accept these comments.
>
> Section 2.3.2
> We need to say something about STC. As the ADQL spec is not focused upon
> XML, it would be difficult to use STC-full, unless it is about what is
> emitted by the parser. But the parser is an implementation detail; and
> some may feel that a parser is not necessary: hence the concentration
> upon functions rather than operators. So we are back to STC-s. I cannot
> see anything in STC-s that allows it to be quoted easily in a query
> where details are extracted within the query; eg:
>
> -- Find all observed objects within 0.001 degrees of those
> -- observed objects which have a quality greater than 3
> -- and a redshift greater than 1.6
> select s.obsra, s.obsdec, s.z, s.specid, s.targetname, s.quality from
> spectra as s
> where s.quality > 3 and s.z > 1.6 and
> CONTAINS( POINT( 'J2000', s.ra, s.dec ), CIRCLE( 'J2000', s.ra, s.dec,
> 0.001 ) ) = 1 ;
>
> Please check this carefully (I'm not an astronomer and feel exposed
> here). Would this be an example that could not be covered by STC-s? I'm
> happy to be proved wrong, as usual.
>
> Sections 2.3.2.2.3 and 2.3.2.2.4.
> It was felt AREA, DISTANCE, LONGITUDE, LATITUDE and CENTROID would be
> useful extensions to the language, and may be the first of a number.
>
> Section 2.3.2.2.5.6 INTERSECTS
> I think we could accept these comments.
>
> Section 2.3.2.2.5.11
> I think someone else needs to answer this one. In my prosaic way, I
> think of a rectangle as polygon.
>
> The spelling mistake can be corrected. The criticism over the level of
> sub-sectioning may be warranted.
>
> OK. That's all for now.
> Regards
> Jeff
>

-- 
Iņaki Ortiz de Landaluce

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Science Operations Department (SCI-O)
Science Archives Engineering Unit (SCI-OE)

E-mail: Inaki.Ortiz-at-sciops.esa.int
Tel: +34 91 813 13 67  Fax: +34 91 813 13 22

European Space Astronomy Centre (ESAC)
28691 Villanueva de la Caņada
P.O. Box 78, Madrid, SPAIN 


============================================================================
====================
This message and any attachments are intended for the use of the addressee
or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or
in part) of its content
is prohibited. If you received this message in error, please delete it from
your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed.
ESA shall not be liable
for any e-mail if modified.
============================================================================
=====================
Received on 2008-05-15Z17:20:17