<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Alberto, all,<br>
<br>
Also, at the ESDC, we share the statements from Alberto. If we want
to have polymorphic ways to describe<br>
the same kind of entities (like geometry) we have to ensure that the
applications are prepared for them and<br>
we have to justify why we are moving away from the previous defacto
standard.<br>
<br>
In case we want to officially standardize STC-S or a similar string
format, we also consider that reusing a<br>
format like "Well-known_text" could be an option to prevent
inconsistencies and simplify implementations.<br>
<br>
Cheers,<br>
Jesus<br>
<br>
<div class="moz-cite-prefix">On 18/12/17 17:20, Baptiste Cecconi
wrote:<br>
</div>
<blockquote cite="mid:D44BD211-9F3B-4114-B823-7AF02E388FC3@obspm.fr"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>Hi Alberto,</div>
<div><br>
</div>
<div>in spite of my delayed answer, I fully agree with your
statements (all of them, include your extra point). </div>
<div><br>
</div>
<div>Baptiste </div>
<div><br>
Le 7 déc. 2017 à 12:14, alberto micol <<a
moz-do-not-send="true"
href="mailto:amicol.ivoa@googlemail.com"><a class="moz-txt-link-abbreviated" href="mailto:amicol.ivoa@googlemail.com">amicol.ivoa@googlemail.com</a></a>>
a écrit :<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="Content-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 moz-do-not-send="true"
href="https://en.wikipedia.org/wiki/Well-known_text"
class="">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 moz-do-not-send="true"
href="mailto:Pierre.Fernique@astro.unistra.fr"
class="">Pierre.Fernique@astro.unistra.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" 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>
</div>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Jesus Salgado
ESA Astronomy Archives Technical Lead
QUASAR Science Resources for European Space Agency (ESA)
ESAC Science Data Centre (ESDC), SCI-OPD
Data and Engineering Division, SCI-OP
Operations Department, Directorate of Science
European Space Astronomy Centre (ESAC)
European Space Agency (ESA)
ESAC - ESA Science Astronomy Centre
Camino Bajo del Castillo s/n
Urb. Villafranca del Castillo
28692 Villanueva de la Canada - Madrid Tel: +34 91 813 12 71
SPAIN Fax: +34 91 813 13 08
------------------------------------------------------------------- </pre>
<PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</PRE></body>
</html>