<div dir="ltr"><div class="gmail_default" style="font-size:small">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.<br><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">"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).<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">--</div><div class="gmail_default" style="font-size:small">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.<br><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Dec 2023 at 01:38, Gregory MANTELET <<a href="mailto:gregory.mantelet@astro.unistra.fr">gregory.mantelet@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
Hi Alberto,<br>
<br>
<br>
<div>On 01/12/2023 13:42, alberto micol
wrote:<br>
</div>
<blockquote type="cite">
Hi DALers,
<div><br>
</div>
<div>Two strong comments (A and B) and one question (C), regarding
DALI v1.2...</div>
<div><br>
</div>
<div><br>
</div>
<div>A) §3.12 Shape states: "<a id="m_-2827551302969693473tth_sEc3.12" style="color:rgb(0,0,0)">The
allowed shapes are: <tt>circle</tt>, <tt>range</tt>, <tt>polygon</tt>.”</a></div>
<div><a style="color:rgb(0,0,0)"><br>
</a></div>
<div><a style="color:rgb(0,0,0)">ESO
needs to have also: </a></div>
<div><a style="color:rgb(0,0,0)">-
point</a></div>
<div><a style="color:rgb(0,0,0)">-
multi-polygon</a></div>
<div>and, because of ALMA, also:</div>
<div>- union of circles and polygons, also with holes, <a style="color:rgb(0,0,0)">where
holes are expressed as CW polygons.</a></div>
<div><a style="color:rgb(0,0,0)"><br>
</a></div>
<div><a style="color:rgb(0,0,0)">Otherwise
we will not be able to adopt DALI 1.2</a></div>
<div><a style="color:rgb(0,0,0)"><br>
</a></div>
<div>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:</div>
<div>- 3.6 Points</div>
<div>- 3.7 Circle</div>
<div>- 3.8 Range</div>
<div>- 3.9 Polygon</div>
<div>- 3.10 MOC</div>
<div>- 3.11 Multi-Polygon <br>
</div>
</blockquote>
<br>
<br>
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?<br>
<br>
<br>
<blockquote type="cite">
<div><a style="color:rgb(0,0,0)">B)
§3.9 Polygons states that:</a></div>
<div><a style="color:rgb(0,0,0)">“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). “</a></div>
<div><a style="color:rgb(0,0,0)"><br>
</a></div>
<div><a style="color:rgb(0,0,0)">That
is not the correct definition, as it excludes the possibility
to express a hole using a CW polygon.</a></div>
<div><a style="color:rgb(0,0,0)"><br>
</a></div>
<div><a style="color:rgb(0,0,0)">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: </a><a style="color:rgb(0,0,0)">https://wiki.ivoa.net/internal/IVOA/InterOpMay2023Ops/ESO_VO_Polygon_Tool.pdf </a></div>
<div><a style="color:rgb(0,0,0)"><br>
</a></div>
<div><a style="color:rgb(0,0,0)">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.</a></div>
</blockquote>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote type="cite">
<div><a style="color:rgb(0,0,0)"> C)
Does DALI 1.2 allow a user to express spherical coordinates or
geometrical types in non-equatorial frames?</a></div>
</blockquote>
<br>
<br>
As far as I know, no. But I let any DALI author properly answer this
question.<br>
<br>
<br>
Cheers,<br>
Grégory<br>
</div>
</blockquote></div>