DALI-next

[Patrick Dowler]

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> 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/3112793a/attachment.html>