s_region problem

[François Bonnarel]

Hi all,

      I think Alberto and others arguments push to the following decision:

       Keep adql:region/stc-s as the xtype for s_region in ObsCore. (and 
ObsTAP/SIAV2 services). Query parameter following adql:region should 
also be accepted.

       The only major change required is in ADQL 2.1 where the "dropping 
of REGION" should be suppressed as already proposed by Dave. TAP 1.1 
doesn't require any change because it only recommands using new DALI 
xtypes ( CIRCLE and POLYGON where datatype is an array of doubles) when 
nothing  else is usefull/required. There is however a sentence in TAP 
1.1 which says ADQL REGION type (for Queries, not as an xtype) is 
dropped in ADQL spec. This sentence should be removed.

       For long terme evolution here are my thoughts:

            Outside ObsCore context, and when no complex shape is needed 
the new xtype makes field typing and query managment easier. So it 
should be used. s_region is not a "Region of Interest" in general. It is 
the coverage of a dataset. Something very specific.

            The disparition of "string fields" for space features 
doesn't seem to be possible in a short term. There is a need for a 
string xtype looking like STC-S to describe shapes.

             Query by MOC is also something of great benefit to 
applications.

            So I'm afraid 3 different xtypes should have to leave together.

            The inclusion of coordinate systems and frames in the STC-S 
string is another story. I agree with Markus it could be nice to remove 
that from the field value. By the way it is not breaking the STC-S 
scheme because these metadata are optional. The default is UNKNOWN. IN 
that case a "ref" from the field towards an appropriate coordinate 
system structure in the VOTABLE could be enough.

            An idea (personal in that case) could be to extend the 
VOTable COOSYS element by using attributes and subelements mapping the 
stc "coordinate system" package.

            In the special case of ObsCore, the coordinate system is 
already required to be ICRS by the standard.


Cheers

François


Le 07/12/2017 à 18:14, alberto micol a écrit :
> Dear All,
>
> I think that this topic has the potential for a very bad impact on the 
> way the astronomical community perceives the VO.
>
> 1.- The clients/tools are the face of the VO, they are what the 
> astronomical community sees of the VO.
> Exposing these new polygon format when the clients/tools are not yet 
> in the position of digesting it
> seems not a good way forward.
> We are losing our face with the astronomical community by acting this way.
> Coordination with the developers of tools/clients is of paramount 
> importance.
> This to me is an important lesson learned.
>
> 2.- The ObsTAP promise was and still is:
> - one and the same query to all data centres,
> - one and the same answer (names, formats, units) from all of them
> Easy.
> This is now an unfulfilled promise.
>
> 3.- A multiplication of formats makes it very hard to interoperate.
> Some clients will support all new formats, some will only support one 
> of them;
> as a consequence, data providers will have to generate output 
> containing all formats
> so to guarantee maximum flexibility to their users. Complexity is 
> nobody’s friend.
>
> 4.- At ESO, complementing what Theresa said, there was quite some 
> effort in supporting STC-S
> as output format from our SQLServer database. We did that because this 
> is required by ObsCore,
> and because this is what the clients understand. Blood went into our 
> design and implementations:
> STC-S is formally not an approved standard? It is a de-facto standard, 
> and that should be respected.
>
> Sorry all, I might sound a bit hard on all this… apologies but I see a 
> lot at stake here.
>
> Conclusions:
> I plea the data centres that already implemented the change in 
> Obscore/SSA/SIA/etc
> to retract it asap to avoid this confusion, until the impasse
> --from the user's point of view-- is resolved.
>
> Alberto
>
> PS: One extra point: if you really really really want to move away 
> from STC-S,
> then why re-inventing the wheel and coming up with yet a new format?
> Please consider to use the well-established text markup language 
> called Well-Known Text (WKT),
> already supported by many DBMSes including postgres, SQLServer,
> Oracle, mysql, and many others;
> see: https://en.wikipedia.org/wiki/Well-known_text (and its RDBMS 
> section).
> Such choice would greatly simplify the adoption of the new standard by 
> the data centres:
> there would be no need to develop special functions to handle VO-made 
> formats.
> Still, clients would have to implement it, but at least the backend 
> job would be already done.
>
>
>> On 24 Nov 2017, at 12:26, Pierre Fernique 
>> <Pierre.Fernique at astro.unistra.fr 
>> <mailto:Pierre.Fernique at astro.unistra.fr>> wrote:
>>
>>
>> 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 ?
>>  2. And if yes : is it only in TAP ? or also in SIA2 or SSA ?
>>  3. 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 ?
>>  4. How providers who already generated complex s_region will do now
>>     ? (for instance ESO)
>>  5. How we will manage the transition period ?
>>
>> Best regards
>> Pierre Fernique
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20171218/e71941ce/attachment.html>