<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p> I think Alberto and others arguments push to the following
decision:</p>
<p> 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.</p>
<p> 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.</p>
<p> For long terme evolution here are my thoughts:</p>
<p> 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.</p>
<p> 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.</p>
<p> Query by MOC is also something of great benefit to
applications.</p>
<p> So I'm afraid 3 different xtypes should have to leave
together.<br>
</p>
<p> 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.</p>
<p> 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.</p>
<p> In the special case of ObsCore, the coordinate system
is already required to be ICRS by the standard.</p>
<p><br>
</p>
<p>Cheers</p>
<p>François<br>
</p>
<br>
<div class="moz-cite-prefix">Le 07/12/2017 à 18:14, alberto micol a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:F03BCB83-B9F9-4D3C-BE7F-B3B0FCD7AAC0@googlemail.com">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
Dear All,
<div class=""><br class="">
</div>
<div class="">I think that this topic has the potential for a very
bad impact on the way the astronomical community perceives the
VO.</div>
<div class=""><br class="">
</div>
<div class="">1.- The clients/tools are the face of the VO, they
are what the astronomical community sees of the VO.</div>
<div class="">
<div class="">Exposing these new polygon format when the
clients/tools are not yet in the position of digesting it</div>
<div class="">seems not a good way forward.</div>
<div class="">We are losing our face with the astronomical
community by acting this way.</div>
<div class="">Coordination with the developers of tools/clients
is of paramount importance.</div>
<div class="">This to me is an important lesson learned.</div>
</div>
<div class=""><br class="">
</div>
<div class="">2.- The ObsTAP promise was and still is:</div>
<div class="">- one and the same query to all data centres,</div>
<div class="">- one and the same answer (names, formats, units)
from all of them</div>
<div class="">Easy.</div>
<div class="">This is now an unfulfilled promise.</div>
<div class=""><br class="">
</div>
<div class="">3.- A multiplication of formats makes it very hard
to interoperate.</div>
<div class="">Some clients will support all new formats, some will
only support one of them;</div>
<div class="">as a consequence, data providers will have to
generate output containing all formats</div>
<div class="">so to guarantee maximum flexibility to their users.
Complexity is nobody’s friend.</div>
<div class=""><br class="">
</div>
<div class="">4.- At ESO, complementing what Theresa said, there
was quite some effort in supporting STC-S</div>
<div class="">as output format from our SQLServer database. We did
that because this is required by ObsCore,</div>
<div class="">and because this is what the clients understand.
Blood went into our design and implementations:</div>
<div class="">STC-S is formally not an approved standard? It is a
de-facto standard, and that should be respected. </div>
<div class=""><br class="">
</div>
<div class="">Sorry all, I might sound a bit hard on all this…
apologies but I see a lot at stake here.</div>
<div class=""><br class="">
</div>
<div class="">Conclusions:</div>
<div class="">
<div class="">I plea the data centres that already implemented
the change in Obscore/SSA/SIA/etc</div>
<div class="">to retract it asap to avoid this confusion, until
the impasse</div>
<div class="">--from the user's point of view-- is resolved. </div>
</div>
<div class=""><br class="">
</div>
<div class="">Alberto</div>
<div class=""><br class="">
</div>
<div class="">PS: One extra point: if you really really really
want to move away from STC-S,</div>
<div class="">then why re-inventing the wheel and coming up with
yet a new format?</div>
<div class="">Please consider to use the well-established text
markup language called Well-Known Text (WKT),</div>
<div class="">already supported by many DBMSes including postgres,
SQLServer,</div>
<div class="">Oracle, mysql, and many others;</div>
<div class="">see: <a
href="https://en.wikipedia.org/wiki/Well-known_text" class=""
moz-do-not-send="true">https://en.wikipedia.org/wiki/Well-known_text</a> (and
its RDBMS section).</div>
<div class="">Such choice would greatly simplify the adoption of
the new standard by the data centres:</div>
<div class="">there would be no need to develop special functions
to handle VO-made formats.</div>
<div class="">Still, clients would have to implement it, but at
least the backend job would be already done.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 24 Nov 2017, at 12:26, Pierre Fernique <<a
href="mailto:Pierre.Fernique@astro.unistra.fr" class=""
moz-do-not-send="true">Pierre.Fernique@astro.unistra.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<p class=""><br class="">
</p>
<p class="">Dear DAL and Apps members,</p>
<p class="">It seems that we have a problem concerning
the <b class="">s</b><b class="">_region</b> usage.</p>
<p class="">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.</p>
<p class="">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.</p>
<p class="">So, I have several questions for TAP 1.1
authors and DAL members :<br class="">
</p>
<ol class="">
<li class="">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 ?<br class="">
</li>
<li class="">And if yes : is it only in TAP ? or also
in SIA2 or SSA ?</li>
<li class="">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 ?</li>
<li class="">How providers who already generated
complex s_region will do now ? (for instance ESO) </li>
<li class="">How we will manage the transition period
?</li>
</ol>
<p class="">Best regards<br class="">
Pierre Fernique</p>
<p class=""><br class="">
</p>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>