<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Markus,</p>
<p>I am no sure to understand the problem.</p>
<p>Using the following polygon in Aladin:</p>
<p>draw polygon(10.0, 0.0, 0.0, -2.0, 2.0, 10.0, 10.0, 0.0, 2.5,
0.0, 4.0, 5.0, 10.0, 0.0, 3.0, 0.0 ,3.5, 1.0, 4.5, 0.0) <br>
</p>
<p>I get a result which seems correct (see below).<br>
</p>
<p>I suspect that the problem you mention (on the need for rational
arithmetic) as no consequence in practice: the areas between two
very close edges (which are supposed to overlap) is going to be
very very close from 0 (I may be missing something, let's discuss
this off list if you want).</p>
<p><br>
</p>
<p>It seems that there is a large consensus to support only
non-self-intersecting polygons, so I am not going to push any
further.</p>
<p>I suppose that VO documents should be updated to state explicitly
that self-intersecting polygons are not supported.</p>
<p>Kind regards,</p>
<p><br>
</p>
<p>François-Xavier<br>
</p>
<p><br>
</p>
<p><img src="cid:part1.3546FB93.2673FB75@astro.unistra.fr" alt=""></p>
<br>
<div class="moz-cite-prefix">Le 15/06/2018 à 18:47, Markus Nullmeier
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:c24b9a03-2178-1c1d-d585-b83574335d71@ari.uni-heidelberg.de">
<pre wrap="">Hello list,
On 15/06/18 16:41, Francois-Xavier PINEAU wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">going from
any vertex of the polygon to the point to test, i. e., at the crossings
of the path to the test point with the edges of the polygon.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Yes, and this work just the same for self-intersecting polygons.
</pre>
</blockquote>
<pre wrap="">
Only if you disallow edges that (partly) overlap. But you cannot
detect them reliably unless you require everybody to use exact
rational arithmetic instead of customary floating-point arithmetic.
(This of course additionally includes exactly prescribing the
approximations, i. e., the implementations, that are used for
the trigonometric functions.
[Otherwise some polygons would be allowed for one service and illegal
for another.]
A minor investment compared to using rational arithmetic in the first
place, but probably still highly annoying for many.)
See the attached image (do attachments work on the IVOA lists?
otherwise, use <a class="moz-txt-link-freetext" href="http://www.g-vo.org/edp-forum-2018/collinear-edges.png">http://www.g-vo.org/edp-forum-2018/collinear-edges.png</a> )
for a counterexample with overlapping edges, where 'inside' and
'outside' is no longer well-defined for self-intersecting polygons.
And while overlapping edges are obviously something that one also wants
to disallow for non-intersecting polygons, they are less of a problem
there because they are
a) less likely to emerge because of non-existent intersecting edges
b) the algorithm above may be made quite robust by allowing a certain
"slack margin" for "in-"/"out-" crossing of (quasi-) collinear edges
that exhibit an inconsistent order.
The "slack margin" argument also works for the task of validating non-
intersecting polygons effectively, rendering them much more easily
interoperable than the self-intersecting variant by the simple virtue of
assigning the burden of defining 'inside' and 'outside' to client
applications.
Best regards,
Markus Nullmeier
</pre>
</blockquote>
<br>
</body>
</html>