<div dir="ltr"><div class="gmail_default" style="font-size:small">Yes, the "region" part of DALI_next would give us more or less STC-S stripped down to the minimal necessary/useful bits. <br></div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Aug 2019 at 13:48, Tim Jenness <<a href="mailto:TJenness@lsst.org">TJenness@lsst.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;">
Talking of STC-S, can we *try* to approve it as a standard?<br>
<div><br>
<blockquote type="cite">
<div>On Aug 27, 2019, at 1:38 PM, Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com" target="_blank">pdowler.cadc@gmail.com</a>> wrote:</div>
<br class="gmail-m_4352483179818701098Apple-interchange-newline">
<div>
<div dir="ltr">
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">The use cases we examined call for the ability to support some of those off-diagonal types. The polymorphic simple corner is already in use in several places so that is simply standardising current practice.
The only "disjoint" use cases are the "multi polygon" ones, but those come from several people and are common. No one has mentioned let alone seriously argued for "multi circle" or (worse) a generic "multi shape".</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">It is possible to only standardise the diagonal (eg, "region") which supports both polymorphism and disjoint. However, there are legit reasons for implementers to support one but not both of those the way to
declare that you output or accept polymorphic but not disjoint is to say "shape" instead of "region". Clearly, the design is such that anyone who supports "region" can support all the others so there is no combinatorial complexity. If we did this I would say
"don't bother" because we'd be in the same boat as we are with defacto STC-S: single serialisation with partial implementations and no way to convey what partial means... and I'd just use custom xtypes instead. Interoperability would suffer for both reasons.<br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">I'll admit that "multi interval" doesn't add much compared to an array of simple interval(s) so while the use cases for that are solid that solution is not super compelling. Certainly in CAOM where I have that
kind of thing I can live with datatype="double" arraysize="2x*" xtype="interval".
<br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">In my experience, (and I think it is generally true) polymorphic is an easier thing to deal with than disjoint, so I can see reasons to want to support "shape" but not "region". On the other side, if someone
supports "multi polygon" they can trivially support "region" so as long as as "region" was not union of different shapes. That and the previous point would reduce the value in standardising the disjoint type-safe corner.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">This does not support holes (in polygons) without adding intersection (and then probably parentheses); we don't need that now but determined that it could be added later when use cases warrant. But, before
niggling about details, the main question is: Is that the only thing we might add in future or is there something else we need to at least consider?</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div>
<div dir="ltr" class="gmail-m_4352483179818701098gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>--<br>
</div>
<div>Patrick Dowler<br>
</div>
Canadian Astronomy Data Centre<br>
</div>
Victoria, BC, Canada<br>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 26 Aug 2019 at 04:37, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Pat,<br>
<br>
On Tue, Aug 20, 2019 at 11:16:25AM -0700, Patrick Dowler wrote:<br>
> <a href="https://wiki.ivoa.net/internal/IVOA/InterOpMay2019DAL/DALI-1.1-next.pdf" rel="noreferrer" target="_blank">
https://wiki.ivoa.net/internal/IVOA/InterOpMay2019DAL/DALI-1.1-next.pdf</a><br>
> <br>
> The last slide (debatable solution) was not presented but included to<br>
> initiate discussion.<br>
> <br>
> [...]<br>
> <br>
> We do not need to standardise all the xtypes that come out of this in<br>
> DALI-1.2; the ones with ? in the last slide do not correspond to any use<br>
> cases I know of and are there for symmetry/completeness only.<br>
<br>
For the record: I think there is little benefit in having the<br>
off-diagonal xtypes; it seems to me that there are few use cases that<br>
would be simplified by stripping either one of the "polymorphic" or<br>
"disjoint" requirements. Dropping both at the same time obviously<br>
helps a lot in letting clients reason about columns (and perhaps in<br>
implementation complexity, though I doubt any real VO component can<br>
get around region in the end when we standardise it). <br>
<br>
I simply can't see similar benefits for the cases where we drop just<br>
one of the two.<br>
<br>
Now, since it seems we cannot get rid of the requirement to have the<br>
disjoint mixed geometries, at least let's not complicate matters<br>
further by introducing intermediate steps that are nice conceptually<br>
but don't give practical benefits.<br>
<br>
Oh, and we're about it: I'd still like to maintain that the<br>
requirement that xtypes can round-trip with TAP uploads is a pain in<br>
the neck when it comes to these geometries. What I think we should<br>
do here is form an equivalence class of xtypes that TAP engines might<br>
transform things into, and that would include all geometries. <br>
<br>
This would mean that when you upload a circle, the server might<br>
return a region-typed column (I'm sure Alberto will like this). And<br>
when you upload a region, the server might return a moc-type column.<br>
Anything else will require fairly horrible hacks prone to breaking,<br>
and we'd need to understand *very* well why we absolutely have to<br>
have the transparent round-tripping for geometries.<br>
<br>
-- Markus<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote></div>