s_region problem

[Pierre Fernique]

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/apps/attachments/20171124/5a5021ea/attachment.html>