s_region problem
François Bonnarel
francois.bonnarel at astro.unistra.fr
Mon Nov 27 13:12:27 CET 2017
Dear all,
My understanding of this context as a DAL chair involved in several of
the specifications as author and (supposed to be) aware of the others.
Most of this stuff is extracted from a discussion we had in a more
limited group.
1 ) Obscore
The discussion here is actually invloving at least 3 DAL standards
+ Obscore (which is DM oficially but actually "DM-DAL") : TAP, ADQL,
DALI and Obscore. The DAL dillemma is the following : as it encompasses
a vast variety of situations and use cases and various interface shapes,
DAL technology cannot be defined by a single "SPEC_OF_EVERYTHING". DAL
has defined a great deal of different protocols, which of them evolving
its own rythm. We have to be carefull all this keep consistent and to be
carefull also we do not break everything
Each of the 4 standards involved here have two versions : TAP 1.0,
1.1, ADQL 2.0, 2.1, DALI 1.0, 1.1. Obscore 1.1 and DALI 1.1 are IVOA
recommendations since 2017 May the 17th. TAP1.1 and ADQL 1.1 are still
in discussion.
1 ) For s_region what does Obscore spec says ? ObsCore is a model
(or a view of a larger model) each class/attribute is perfectly defined.
To map such a model in a TAP service one has to express it in a TAP
schema. The OBscore spec defines precisely this TAP schema. + xtypes for
each TAP schema column. In OBscore 1.0 the xtype for s_region is
"adql:REGION". Obscore 1.1 maintains the same definitions for s_region
(and other ObsCore attributes) than 1.0. But it adds that the definition
given in the spec is consistent with TAP 1.0 (the only valid one at the
moement it was defined) but that the situation may evolve after the
release of TAP 1.1.
2 ) So what does TAP says about xtypes ? 1.0 was defining a couple
of them, all bound to adql functions, including adql:Region. adql:REGION
WAS AT THE TIME OF WRITING OF 1.0 considered as STC-S. TAP 1.1 gets rid
of this and claims that as far as possible xtype should map to the
definitions given in DALI. It says "SHOULD" and not MUST of course. You
are still allowed to define or use other xtypes if really necessary.
3 ) DALI 1.0 didn't say anything about xtypes. DALI 1.1 defines a
couple of them. xtypes CIRCLE and POLYGON are defined as arrays of
doubles. This has also been discussed to be xtypes of some of SODA input
parameters (together witn interval). These xtypes are those refered by
TAP 1.1 as those that SHOULD be used if no other xtype is required by
the use case.
4 ) ADQL 2.0 Defined a couple of functions which TAP was mapping
to xtypes: Among them REGION. ADQL 2.1 is considering dropping
string-typed REGION and keep more double array oriented CIRCLE and
POLYGON. This has consequences for querying. This has no consequence on
adql:REGION xtype which can remain defined as in ADQL 2.0 if necessary.
Discussion :
With the main goal of keeping the defintions and
formats stable for a while in the vO in a given context ( the
ObsCore/OBstap one here) I think nothing prevent us to keep adql:REGION
(equivalent to STC-S string) as an xtype for the s_region attribute in
ObsCore.
I don't know how DACHS is implemented but I
assume it generates xtypes in the VOTABLE response of the services from
the TAP schemata. So if the the ObsCore TAP schema keeps adql:REGION as
the xtype of s_region instead of xtype=polygon, clients like Aladin
could still recognize and parse it immediatly.
Actually it makes more sense than it may appear.
The data/metadata (coord system and whatever) distinction is not an
issue for Obscore. Everything is ICRS in there. So the STC-S string is
unambiguously a polygon, a circle, or any of other stc flavors of space
area perfectly understandable. s_region is not only a space area. It's
the support of the observation (as defibed by ObsCore and
characterisation) expressed as a space area. So it's not that strange to
have a spoecific xtype for it, and to keep the historical
adql:REGION/STC-S then.
For POlygon or CIRCLES in general, which have
plenty of usages different from "dataset support" (exemply gratia
"region of interest", "survey or catalog coverages" , "cross match
search regions" ,etc... and which may require different coordinate
systems than ICRS going to the POLYGON/CIRCLE xtypes with arrays is the
most standard option for the future...
Lets' go to Pierre questions in detail
Le 24/11/2017 à 12:26, Pierre Fernique a écrit :
>
>
> Dear DAL and Apps members,
>
> It seems that we have a problem concerning the *s**_region* usage.
>
> Recently, we discover that some data providers have changed their
> syntax, moving from the regular STC-S string to a new one which seems
> to be an array of doubles, alternating long and lat. Both Aladin V10
> and Aladin Lite fail to manage a such new syntax, and we had
> complaints from final users which do no longer see the FoV of their
> observations.
>
> After investigating about this unexpected evolution, it appears that
> this new syntax is generated by some versions of DaCHS testing TAP1.1
> future possible recommendation.
>
> So, I have several questions for TAP 1.1 authors and DAL members :
>
> 1. Is is really true that STC-S s_region should be removed from
> VOTable results ? Personally, I did not see this consequence in
> the TAP 1.1 document. or ?
>
No. Nothing prevent us to have string field in VOTable
>
> 1.
>
>
> 2. And if yes : is it only in TAP ? or also in SIA2 or SSA ?
>
TAP itself doens't prevent to use string-typed FIELDS in the response.
IT only recommands usage of fIELDS with wtype.
In the case of s_region the basic thing is not TAP or SIAV2, the
discovery protocol, but ObsCOre. ObsCore has to be stabilized.
Common discovery metadata in the case of ADQL queries and the case of
Parameter query language has been a major progress recently...
We should not break it/
For SSA si next answer.
>
> 1. How the client can know the logic (lon/lat or lat/lon,
> counter-clock or anti-counterclock, ...), the frame and other
> coordinate parameters for such array of double ?
>
I think xtype=POLYGON assumes it's lon/lat. At the moment coordsystem
can aonly be given by the de-deprecated COOSYS. So reference to a
COOSSYS element seems to be the only solution.
>
> 1. How providers who already generated complex s_region will do now ?
> (for instance ESO)
>
I think they should not change that. ObsCore has been designed and
discussed durin a long time to be a stable basis.
>
> 1.
>
>
> 2. How we will manage the transition period ?
>
In my opinion no transition period is needed for the specific case of
s_region which is STCS ICRS.
DAL "build up" is always a balance between stability and backward
compatibility and controlled progress in the definitions.
Cheers
François
>
> Best regards
> Pierre Fernique
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20171127/7f8a163d/attachment.html>
More information about the dal
mailing list