Indeed. Thanks for clarifying much better.
--Alex
-----Original Message-----
From: owner-voql-teg-at-eso.org [mailto:owner-voql-teg-at-eso.org] On Behalf Of
Patrick Dowler
Sent: Thursday, May 15, 2008 12:55 PM
To: 'VOQL-TEG'
Cc: 'Robert Hanisch'
Subject: Re: Sessions at Trieste
Agreed. The REGION construct, which takes a string representation as
argument,
is the general purpose method. POLYGON is limited to great circle edges.
My thinking in writing that statement was to express that RECTANGLE is just
a
short-cut way to make a POLYGON; the edges are still great circles (and not
lines of equal longitude or latitude). If you transform it, then it is still
the same shape (POLYGON) but it probably cannot be written in "short-cut"
form of RECTANGLE because there will no longer be just 2 longitude and 2
latitude values. Since it brings very little real value when defined that
way, it may be best to just remove it (Bob: that is something we discussed
at
one point).
Note that ADQL itself doesn't specify what the string format actually is
(this
is also how OpenGIS does it). It would be up to a service that accepts ADQL
to declare what format(s) it understands. This serves several purposes: it
makes ADQL itself independent of both format in general and in which version
of the format, if it changes in some way. Also, it is consistent with how string representations for other non-scalar types are handled (dates, for example).
So, yes, REGION is the general construct and STC/s is the only standardised string representation a service can declare.
Pat
On 2008-5-15 08:19, Alex Szalay wrote:
> 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
-- 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-15Z19:06:35