<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Alberto,<br>
<br>
Markus is using DACHS, which is completely different from my
library. So, I fear the blame is on me for that issue.<br>
<br>
It is actually due to the way I ask the columns metadata: through
the TAP_SCHEMA. And since the TAP_SCHEMA, according to TAP 1.0,
has no way to declare arrays, my library does not know about your
arrays and can not add any arraysize. In theory, it could be
possible to declare the column metadata in a more complete way,
but unfortunately, the whole TAP library is using TAPType and so,
suffers from the same lack as TAP 1.0. That's why I was asking to
DAL about what is planned for TAP 1.1 so that I can already start
to solve this issue.<br>
<br>
According to what has already been discussed here, I think I will
very soon switch internally to VOTable datatypes. The impact on
the current library users should be minimal, almost invisible. For
those interested in having arrays, like you Alberto, there will be
a small additional step (probably adding some column(s) in
TAP_SCHEMA.columns....ideally the one of the future TAP 1.1 so
that avoiding an annoying transition when TAP 1.1 will be
released...hence my original questions). On a further version of
the library, I may propose a different way to declare the tables
and columns metadata.<br>
<br>
In the meantime, Alberto, I may have a quite quick solution for
you. Since it is starting to be too technical here, I propose to
discuss that privately so that avoiding to bother the rest of DAL
with that ^^<br>
<br>
Grégory<br>
<br>
<br>
On 06/07/2017 11:27 AM, alberto micol wrote:<br>
</div>
<blockquote
cite="mid:49C30E7A-E910-456C-B30B-06A515F66EC0@googlemail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="">Thanks Markus.</div>
<div class=""><br class="">
</div>
<div class="">I tried your TAP with the query you provided and
found that</div>
<div class="">- your FIELD declaration contains: datatype=“float”
arraysize=“*”</div>
<div class="">- votlint is happy with your returned votable</div>
<div class=""><br class="">
</div>
<div class="">In my case instead:</div>
<div class="">- the FIELD has no arraysize and datatype=“double"</div>
<div class="">- votlint complains about it:</div>
<div class="">
<div style="margin: 0px; font-size: 11px; line-height: normal;
font-family: Menlo;" class=""><span
style="font-variant-ligatures: no-common-ligatures" class="">ERROR
(l.159, c.43): Bad double string '123.269560 -34.578040'</span></div>
</div>
<div class=""><span style="font-variant-ligatures:
no-common-ligatures" class=""><br class="">
</span></div>
<div class=""><br class="">
</div>
<div class="">Given that I think we are both using Gregory’s
library,</div>
<div class="">I wonder how you manage to get the arraysize into
your votable…</div>
<div class="">In my votable only the “char” fields have gotten an
arraysize=“*”</div>
<div class="">all other fields have no arraysize.</div>
<div class=""><br class="">
</div>
<div class="">What is that I’m doing wrong? Maybe Gregory can tell
me...</div>
<div class=""><br class="">
</div>
<div class="">Many thanks,</div>
<div class="">Alberto </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 01 Jun 2017, at 13:37, Markus Demleitner <<a
moz-do-not-send="true"
href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi Pat,<br class="">
<br class="">
On Wed, May 31, 2017 at 10:54:10AM -0700, Patrick Dowler
wrote:<br class="">
<blockquote type="cite" class="">I agree with the goal of
supporting array-typed columns, I think 1-d<br class="">
arrays are OK now, and I think this is within the realm
of the TAP-1.1<br class="">
update. It would make TAPType in VODataService obsolete
since we could<br class="">
just use VOTableType.<br class="">
</blockquote>
<br class="">
I'm all for that.<br class="">
<br class="">
<blockquote type="cite" class="">And I think this is
actually a pretty small change and I'm almost<br
class="">
there in my prototype.<br class="">
<br class="">
Thoughts?<br class="">
</blockquote>
<br class="">
But then why not just take over the VOTable type system
(or at least<br class="">
arraysize) to TAP_SCHEMA, too? I'm noticing just now, but
if<br class="">
something in the vicinity of the VO is called arraysize,
as an<br class="">
implementor I'd be somewhat sore if it contained something
different<br class="">
than what is in VOTable's arraysize syntax (I'd be ok with
dropping the<br class="">
number-plus-star feature, like arraysize="7*").<br
class="">
<br class="">
It does all we can possibly need at this point, and since
dealing<br class="">
with it is part of VOTable, people already have code to
deal with<br class="">
strings like these.<br class="">
<br class="">
For 1.1, I don't think we can switch datatype to VOTable
types to<br class="">
complete the transition (or can we?). But arraysize is
new anyway,<br class="">
and I can't see many reasons to keep the semantics of 1.0
size for<br class="">
it.<br class="">
<br class="">
Oh, and:<br class="">
<br class="">
<blockquote type="cite" class="">On 31 May 2017 at 08:08,
alberto micol <<a moz-do-not-send="true"
href="mailto:amicol.ivoa@googlemail.com" class="">amicol.ivoa@googlemail.com</a>>
wrote:<br class="">
<blockquote type="cite" class="">My use case regarding
arraysize=???2" in TAP is here described.<br class="">
<br class="">
SSA 1.1 requires, in the VOTable output, a single
field for the spatial<br class="">
location,<br class="">
expressed as:<br class="">
<br class="">
<FIELD ID="SpatialLocation" name="SpatialLocation"
datatype=???double"<br class="">
ucd="pos.eq"
utype="ssa:Char.SpatialAxis.Coverage.Location.Value"<br
class="">
arraysize="2" unit=???deg???><br class="">
<br class="">
At ESO we are implementing SSA on top of TAP.<br
class="">
<br class="">
I therefore created the spatial location column in the
TAP_SCHEMA.columns<br class="">
table declaring size=2,<br class="">
but TAP does not translate this information into the
(naively) expected<br class="">
arraysize=???2???,<br class="">
for the reasons that Gregory explained.<br class="">
<br class="">
Hence, we are stack with the development of the ESO
SSAP...<br class="">
unless some smart DAL person comes up with a solution!<br
class="">
</blockquote>
</blockquote>
<br class="">
I'd say don't worry *too* much about that. At the GAVO
data cetner,<br class="">
we've been publishing tables with arrays for ages, and the
fact that<br class="">
we've been lying a bit about the TAP_SCHEMA metadata
hasn't bothered<br class="">
anyone (we have size NULL for them for var-size arrays,
and we've<br class="">
been abusing size for array length otherwise). If you
don't believe<br class="">
me, run<br class="">
<br class="">
select top 1 wcs_refpixel from lsw.plates<br class="">
<br class="">
on <a moz-do-not-send="true"
href="http://dc.zah.uni-heidelberg.de/tap" class="">http://dc.zah.uni-heidelberg.de/tap</a>.
I'd be surprised if you<br class="">
found a TAP client that wouldn't simply do the right thing
(provided<br class="">
they support arrays in VOTable cells at all).<br class="">
<br class="">
For SSA, incidentally, the situation is a bit different,
because<br class="">
conceptually what ssa_location is is a (spherical) point.
You can<br class="">
inspect the table flashheros.data (which is an SSA table)
on our TAP<br class="">
service to see what we do. Admittedly, that's not
terribly<br class="">
attractive because I doubt many clients do something
sensible with<br class="">
STC-S specs.<br class="">
<br class="">
With TAP 1.1, that's going to improve (the POINT xtype);
so, that's<br class="">
what I'd put into my VOTable if I wrote new code now:<br
class="">
<br class="">
<FIELD datatype="float" arraysize="2"
xtype="POINT".../><br class="">
<br class="">
-- clients will be happy with this for now, and a correct<br
class="">
TAP_SCHEMA/VODataService representation can follow when
TAP 1.1 is<br class="">
finalized.<br class="">
<br class="">
-- Markus<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<p><br>
</p>
</body>
</html>