s_region problem

[Baptiste Cecconi]

Hi Alberto,

in spite of my delayed answer, I fully agree with your statements (all of them, include your extra point). 

Baptiste 

> Le 7 déc. 2017 à 12:14, alberto micol <amicol.ivoa at googlemail.com> 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> 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 :
>> 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 ?
>> And if yes : is it only in TAP ? or also in SIA2 or SSA ?
>> 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 ?
>> How providers who already generated complex s_region will do now ? (for instance ESO)
>> 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/20171218/814c296f/attachment-0001.html>