DALI-next

[Patrick Dowler]

Yes, the "region" part of DALI_next would give us more or less STC-S
stripped down to the minimal necessary/useful bits.

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


On Tue, 27 Aug 2019 at 13:48, Tim Jenness <TJenness at lsst.org> wrote:

> 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>
> 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> 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/40c56383/attachment.html>