multipolygon considered unnecessary about dali

[pdowler]

adql:REGION is not a standard; multipolygon is the simplest subset that supports the use cases that were brought forward and discussed... the purpose is to standardise enough to stop needing and using adql:REGION. No one had a reason to try to support something more general so we stopped at simple.

multipolygon is intended to make adql:REGION obsolete so arguing that we don't need it because we have adql:REGION doesn't make sense.

We can debate the serialisation format; the arbitrary separator(s) in a 1-D array is the way to do it with current VOTable. If VOTable had a more flexible mechanism for 2-D arrays (see ivoa-std/VOTable#25) that we could use for numeric then we would be using it (see ivoa-std/VOTable#25) and if adding such a thing had any traction we would have to consider waiting to see how it was going to work. TBD

[msdemlei]

On Wed, Sep 30, 2020 at 10:36:54AM -0700, Patrick Dowler wrote: adql:REGION is not a standard; multipolygon is the simplest subset that supports the use cases that were brought forward and discussed... the purpose is to standardise enough to stop needing and using adql:REGION. No one had a reason to try to support something more general so we stopped at simple.

Ah -- I missed that step and had still assumed adql:REGION was going to be kept.

**multipolygon is intended to make adql:REGION obsolete** so arguing that we don't need it because we have adql:REGION doesn't make sense.

In that case I'm fine with multipolygon as a concept. I'd still like it better if we came up with a serialisation that would scale to generic variable-length arrays (a thought: follow postgres' jsonb path just a few steps?).

[pdowler]

have removed multipolygon from the polymorpic shape xtype and picked the simplest serialization to push discussion of that from here to the WD

closing this issue in favour of WD dicusssion