Polygon CCW winding check request

[Marco Molinaro]

Dear François-Xavier,

2018-06-13 10:05 GMT+02:00 Francois-Xavier PINEAU <francois-xavier.pineau@
astro.unistra.fr>:

> Dear Marco, DAL,
>
> I may be wrong, but I think that the STC definition of the inside of a
> polygon is not compatible with "complex" shapes.
>
I think you're right, but that is what STC currently states and DALI
references to.
So, apart from changing that, we're stuck.

> Example: if we take the case of a simple 4 vertices's polygon having a
> butterfly shape (i.e. having two crossing great-circle arcs), then the
> inside of one "wing" is in the counter-clockwise sense while the inside of
> the other "wing" is in the clockwise sense.
>
So you have: or a butterfly with one wing enclosed by its complementary
sphere minus the other wing, or you have to use 6 points, doubling the
cross-point to define the wings. But both things fall into the discussing
of what's a polygon while the intent of the mail was a request depending on
current standards statements.

I'm sure this discussion has to take place, there were already hints of
this in Victoria.
But the discussion I would say does not solve the interoperability issue
raise by Alberto.

How to deal easily with such a case while remaining compatible with the STC
> definition?
>
>
> A polygon is just a sequence of vertices with great-circle arcs connecting
> the consecutive vertices (plus the last vertex connection the first one).
>
> The great-circle arc connecting two vertices's is the smallest of the two
> complementary great-arcs (and hence is always <= pi (we have a degeneracy
> with vertices having an angular separation of pi)).
>
> There is no ambiguity on the inside and we have fast implementations for
> polygons having possibly very complex shapes (ray-tracing method).
>
> It is true that then the definition does not allow to describe the
> "exterior" (the complement on the sphere) of a polygon as being itself a
> polygon. Is it a problem in practice?
>
> From my (biased) point-of-view, it is more important to support complex
> polygons (with a simple and fast algorithm), and to possibly ask for an
> extra boolean parameter in use cases requiring the complement of a polygon.
>
> Do you agree / disagree?
>
I agree support for complex morphology has to be taken into account.
For example I'm not sure how a donut-like shape can be represented, or how
half a donut with a detached bite would be describable.

What I wonder is: where do this will lead to. I must say that I usually
considered my ~complex uses case of this kind to be solved by a
tessellation approach. But if we need an analytical approach, then we have
to figure it out.

I even wonder if this is only DAL matters.

Cheers,
    Marco


>
> Kind regards,
>
>
> François-Xavier
>
>
>
> Le 12/06/2018 à 17:45, Marco Molinaro a écrit :
>
> Dear DAL members,
> at the recent IVOA Interop in Victoria it was pointed out
> by Alberto
>
> http://wiki.ivoa.net/internal/IVOA/InterOpMayy2018DAL/ivoa_2
> 01805_micol_polygons.pdf
>
> that not all the data providers follow the STC specification
> about the winding direction of polygons stored in their
> archives.
>
> STC states that "The inside of the region is defined as
> that part of coordinate space that is encircled by the
> polygon in a counter-clockwise sense".
> And this is to be considered when looking at the
> celestial sphere from the inside.
>
> The different behaviour of the polygons stored at
> different sites creates an interoperability issue.
>
> This email is a request on data providers to check
> on their data and implementations (when dealing
> with polygons) to solve the presented issue.
>
> James also put together a python code snippet
> implementing a simple test, it is available here:
>
> https://gist.github.com/jd-au/45d1cdc0c6e2a7bc848a4be8f46c8958
>
> Thank you in advance!
> Cheers,
>        Marco & James
>       (your DAL chair & vice)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180613/795c361c/attachment.html>