DALI v1.2: shape vs ESO and ALMA

[Patrick Dowler]

The "definition" of polygon in DALI does refer to STC-1.33 for the complete
specification/details, so maybe by stating "counter-clockwise" to answer
the most superficial question locally (in the way that many people
understand it) it is implying that this is the whole definition? The intent
is for the complete spec in STC-1.33 to be normative.

You see, when we make a really opaque reference to another standard and say
nothing at all, readers *must* go read that other standard just to have an
idea what we are talking about. We get many complaints that doing this
makes our standards too opaque and too much work to understand. The other
extreme is that we lift the whole definition from STC-S and put it into
DALI and stop referencing STC entirely. What we did is in the middle... so
no one is happy? Can you suggest a way to clarify?

If you look back at all the notes in DALI_next, I think you will see that
we did consider holes and multipolygon does support holes as CW polygon
components, but we may have to write some more text and examples to
illustrate that clearly. Also, in DALI_next, we did not consider any use
cases involving multiple circles or multiple shapes. At some point, the
answer there is probably going to be MOC. Yes, CAG does have concepts that
nominally map to specifying such things with different types of paths, but
I gave up on that direction years ago.

"multicircle" would be simple and easy enough... in fact, you can do it now
with datatype="double" arraysize=3x*" xtype="circle". That's why there is
no "multi-internal" either (because you can already deliver those).

--
On what is included in shape, the current amount of polymorphism is limited
to known implementations. We did include multipolygon up to the Bologna
interop but the discussion there was that it is quite complex to implement.
To be clear on one point: by "implementation" we considered tables with a
column using that xtype and those tables being output (query result) or
input (eg. tap_upload) and what the recipient of the table would have to
do. The complexity in extending shape to include more subtypes is largely
in handling the input and specifically in enabling a spatial query using a
column in the uploaded table.

I have some ideas on how I could make that work in our postgresql+pgsphere
server, but it's "complicated". I would not want to make that part of the
spec

Finally, as far as I am aware, the conventional wisdom is that a point is
not a shape and everyone who designs a geometry system that supports that
regrets it. Do you have a use case for including point in the list of
shapes?
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 4 Dec 2023 at 01:38, Gregory MANTELET <
gregory.mantelet at astro.unistra.fr> wrote:

> Hi Alberto,
>
>
> On 01/12/2023 13:42, alberto micol wrote:
>
> Hi DALers,
>
> Two strong comments (A and B) and one question (C), regarding DALI v1.2...
>
>
> A) §3.12 Shape states: "The allowed shapes are: circle, range, polygon.”
>
> ESO needs to have also:
> - point
> - multi-polygon
> and, because of ALMA, also:
> - union of circles and polygons, also with holes, where holes are
> expressed as CW polygons.
>
> Otherwise we will not be able to adopt DALI 1.2
>
> But it would be best for the standard, if “shape” could be fully
> polymorphic, that is, if it could support all the DALI geometrical types,
> which are:
> - 3.6 Points
> - 3.7 Circle
> - 3.8 Range
> - 3.9 Polygon
> - 3.10 MOC
> - 3.11 Multi-Polygon
>
>
>
> I agree with you on this point. I also wondered the same thing: why
> `shape` is limited to only a small part of all available geometries being
> described in DALI?
>
>
> B) §3.9 Polygons states that:
> “In spherical coordinates […] Vertices must be ordered such that the
> polygon winding direction is counter-clockwise (when viewed from the origin
> toward the sky) as described in (Rots, 2007). “
>
> That is not the correct definition, as it excludes the possibility to
> express a hole using a CW polygon.
>
> As I expressed at the IVOA in Bologna earlier this year, the only standard
> that completely defines spherical polygons is the STC v1.33, 2007. All
> other standards (ADQL 2.0, TAP 1.0, DALI v1.1, etc) do not do the right
> job. If interested in details, please see:
> https://wiki.ivoa.net/internal/IVOA/InterOpMay2023Ops/ESO_VO_Polygon_Tool.pdf
>
> My suggestion is not to define the polygon in DALI, but simply refer to
> the definition provided by STC v1.33, 2007, along with its two very
> relevant Errata.
>
>
>
> You're right and I, personally, did not forget your talk in Bologna.
> Should we add to the next DAL running meeting a discussion on polygon in
> DAL ecosystem? It would be an occasion to start fixing some of the
> standards referring or badly defining polygons.
>
> My guess is that DALI should replace STC in the future....but it is not
> yet the case, which leads to an unstable and uncomfortable situation on
> some aspects like polygons.
>
>
>  C) Does DALI 1.2 allow a user to express spherical coordinates or
> geometrical types in non-equatorial frames?
>
>
>
> As far as I know, no. But I let any DALI author properly answer this
> question.
>
>
> Cheers,
> Grégory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20231208/8c618c5b/attachment.htm>