multipolygon considered unnecessary

[msdemlei]

I still don't see a convincing advantage in having multipolygon when there is adql:REGION that also can represent multiple polygons. Having two ways to express the same thing is never good (though, admittedly, sometimes still preferable), and I'd need to see a convincing argument for why we need to accept this uglyness here (for instance: Here's a VOTable parser that can't do adql:REGION but can to multipolygon).

On the other hand, there is the standing issue of having arrays of variable-length things in VOTable. A fix for that is something that would help many applications (Registry, for instance, yearns for arrays of variable-length strings) that are really clumsy otherwise (cf. ADQL's ivo_string_agg user-defined functions).

So, if the multipolygons came in as a side effect of fixing the long-standing x-array problem, I'd be a lot more relaxed about introducing a second representation for multiple polygons; at least it wouldn't be yet another ad-hoc special case but would fit into general VOTable handling.

[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