s_region problem

[alberto micol]

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 <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/20171207/974b3d0a/attachment.html>