DALI-next

[Tim Jenness]

Talking of STC-S, can we *try* to approve it as a standard?

On Aug 27, 2019, at 1:38 PM, Patrick Dowler <pdowler.cadc at gmail.com<mailto:pdowler.cadc at gmail.com>> wrote:


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".

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.

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".

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.

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?

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 26 Aug 2019 at 04:37, Markus Demleitner <msdemlei at ari.uni-heidelberg.de<mailto:msdemlei at ari.uni-heidelberg.de>> wrote:
Hi Pat,

On Tue, Aug 20, 2019 at 11:16:25AM -0700, Patrick Dowler wrote:
> https://wiki.ivoa.net/internal/IVOA/InterOpMay2019DAL/DALI-1.1-next.pdf
>
> The last slide (debatable solution) was not presented but included to
> initiate discussion.
>
> [...]
>
> We do not need to standardise all the xtypes that come out of this in
> DALI-1.2; the ones with ? in the last slide do not correspond to any use
> cases I know of and are there for symmetry/completeness only.

For the record: I think there is little benefit in having the
off-diagonal xtypes; it seems to me that there are few use cases that
would be simplified by stripping either one of the "polymorphic" or
"disjoint" requirements.  Dropping both at the same time obviously
helps a lot in letting clients reason about columns (and perhaps in
implementation complexity, though I doubt any real VO component can
get around region in the end when we standardise it).

I simply can't see similar benefits for the cases where we drop just
one of the two.

Now,  since it seems we cannot get rid of the requirement to have the
disjoint mixed geometries, at least let's not complicate matters
further by introducing intermediate steps that are nice conceptually
but don't give practical benefits.

Oh, and we're about it: I'd still like to maintain that the
requirement that xtypes can round-trip with TAP uploads is a pain in
the neck when it comes to these geometries.  What I think we should
do here is form an equivalence class of xtypes that TAP engines might
transform things into, and that would include all geometries.

This would mean that when you upload a circle, the server might
return a region-typed column (I'm sure Alberto will like this).  And
when you upload a region, the server might return a moc-type column.
Anything else will require fairly horrible hacks prone to breaking,
and we'd need to understand *very* well why we absolutely have to
have the transparent round-tripping for geometries.

          -- Markus


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20190827/ee4cceb0/attachment-0001.html>