<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="monospace">Dear all,</font><br>
<br>
<font face="monospace">Whatever the future of the STC-S working
draft is, having -- even partial --</font><br>
<font face="monospace">implementations may help the debate.</font><br>
<br>
<font face="monospace">A few MOCPy users have asked for a S-MOCs
from STC-String feature.</font><br>
<font face="monospace">And it seems that S-MOCs are considered to
replace (at least in some places)</font><font face="monospace">
STC.<br>
I am curious to know where exactly since MOCs and STC-S are
complementary:</font><br>
<font face="monospace">* STC-S is compact -- as far as it does not
contains unions/intersection of hundreds</font><br>
<font face="monospace"> of shapes -- and precise, but not
indexation oriented</font><br>
<font face="monospace">* MOCs are approximations, not compact --
except at low resolutions --</font><br>
<font face="monospace"> but fast and indexation oriented</font><br>
<font face="monospace">I believe that efficient STC-S queries must
rely (internally) on MOCs</font><br>
<font face="monospace">(or other similar mechanisms), but should not
be replaced by MOC queries</font><br>
<font face="monospace">(even if MOC queries are interesting too and
can help in STC-S queries).</font><br>
<br>
<br>
<font face="monospace">## STC-S Parser</font><br>
<br>
<font face="monospace">So, as previously announced, I implemented a
STC-S parser available on both</font><br>
<font face="monospace"> github and crates.io:</font><br>
<font face="monospace">* <a class="moz-txt-link-freetext" href="https://github.com/cds-astro/cds-stc-rust">https://github.com/cds-astro/cds-stc-rust</a></font><br>
<font face="monospace">* <a class="moz-txt-link-freetext" href="https://crates.io/crates/stc-s">https://crates.io/crates/stc-s</a></font><br>
<font face="monospace">There is still room for improvement and
feeback/comments from people</font><br>
<font face="monospace">with STC experience would be much
appreciated.</font><br>
<br>
<br>
<font face="monospace">## STC-S to S-MOC</font><br>
<br>
<font face="monospace">This email to announced that I now have also
implemented a <b>first version of</b></font><b><br>
</b><font face="monospace"><b>the STC-S to S-MOC feature</b> in
MOCLibRust and in:</font><br>
<font face="monospace">* <b>moc-cli</b>: already available in pypi
and github release</font><br>
<font face="monospace"> + <a class="moz-txt-link-freetext" href="https://pypi.org/project/moc-cli/">https://pypi.org/project/moc-cli/</a></font><br>
<font face="monospace"> +
<a class="moz-txt-link-freetext" href="https://github.com/cds-astro/cds-moc-rust/tree/main/crates/cli">https://github.com/cds-astro/cds-moc-rust/tree/main/crates/cli</a></font><br>
<font face="monospace"> + Example: echo "Circle ICRS 147.6 69.9
0.4" | moc from stcs 14 - fits stcs.moc.fits --force-u64</font><br>
<font face="monospace">* moc-wasm: already available in github
release</font><br>
<font face="monospace"> +
<a class="moz-txt-link-freetext" href="https://github.com/cds-astro/cds-moc-rust/tree/main/crates/wasm">https://github.com/cds-astro/cds-moc-rust/tree/main/crates/wasm</a></font><br>
<font face="monospace">* <b>MOCPy</b>: implemented in the github
source code, but not released yet</font><br>
<font face="monospace"> + <a class="moz-txt-link-freetext" href="https://github.com/cds-astro/mocpy">https://github.com/cds-astro/mocpy</a></font><br>
<font face="monospace">The feature has been put in place but now
have to be tested more thoroughly.</font><br>
<font face="monospace">So far the limitations are:</font><br>
<font face="monospace">* it <b>supports only frame=ICRS,
flavor=SPHER2 and units=deg</b></font><br>
<font face="monospace">* it wrongly considers the<b> DIFFERENCE to
be a SYMMETRIC DIFFERENCE</b> (XOR)</font><br>
<font face="monospace"> instead of a "MINUS".</font><br>
<font face="monospace"> Note that for a single polygon whith a hole
inside it, the result is the same,</font><br>
<font face="monospace"> except that:</font><br>
<font face="monospace">* it does not adopt the STC definition of a
polygon:</font><br>
<font face="monospace"> + it <b>supports self-intersecting
polygons</b></font><br>
<font face="monospace"> + the polygon interior is (kind of) the
part having the smallest area, i.e.</font><br>
<font face="monospace"> the order of the vertices does not matter</font><br>
<font face="monospace">We do support nested
UNION/NOT/INTERSECTION/XOR operations.</font><br>
<font face="monospace">To do so, we rely on BMOCs implemented in the
CDS HEALPix Rust library. </font><br>
<font face="monospace">BMOCs are S-MOCs storing in each cell a
boolean flag telling if the cell is for </font><br>
<font face="monospace">sure fully inside the geometrical shape or
not.</font><br>
<font face="monospace">For example, the NOT operation removes all
cells having the boolean set to 'true'</font><br>
<font face="monospace">but preserves the cells having the boolean
set to 'false' (and add missing cells</font><br>
<font face="monospace">setting their flag to 'true').</font><br>
<font face="monospace">BMOCs have so far two drawback:</font><br>
<font face="monospace">* operations on BMOCs has not yet been
thoroughly tested</font><br>
<font face="monospace">* operations on BMOCs are -- at least in the
current implementation -- much slower </font><br>
<font face="monospace"> than operations on MOCs</font><br>
<font face="monospace">In the future, we may first detect the
operations in a STC-String to switch</font><br>
<font face="monospace">between MOCs (neither NOT or DIFFERENCE
operations) and BMOCs.</font><br>
<font face="monospace">Except that BMOCs have also one big
advantage: they can be spitted into 2 sub-MOCs</font><br>
<font face="monospace">* one fully inside the STC region (no
additional test needed, e.g. when retrieving sources)</font><br>
<font face="monospace">* one "edges" MOC: additional tests needed to
determine if a source in this MOC</font><font face="monospace"><br>
is in or out of the STC region.</font><br>
<font face="monospace"><br>
<b>If you have example of STC-String, especially with operations
(Alberto?), <br>
please send them to us so we can add them to our tests.</b><br>
<br>
Even if STC-S is dropped in the future, it should not be that
complex to<br>
adapt to another standard like DALI "shape".<br>
(Although STC-S is complex, it is quite complete and
self-consistent since it contains<br>
information such as the frame: the two sides of a medal).<br>
<br>
<br>
## About polygons:<br>
<br>
We support self-intersecting polygons.<br>
<br>
Although it is useless when describing footprints, I do think it
makes sense<br>
when you let a user create a polygon by clicking in interfaces
such as<br>
Aladin/Aladin Lite or TOPCAT.<br>
In addition, the existing algorithm to deal with self-intersecting
polygons is<br>
simple (at least in the plane, with some complications on the
sphere)<br>
and fast (see
<a class="moz-txt-link-freetext" href="https://wrfranklin.org/Research/Short_Notes/pnpoly.html">https://wrfranklin.org/Research/Short_Notes/pnpoly.html</a>).<br>
<br>
The best option to define the interior/exterior of a
self-intersecting polygon<br>
may be to provide a control point, provided it is not a vertex
and is not part<br>
of an edge. (It's on of the several options that has been
implemented in the<br>
CDS Healpix Lib).<br>
The control point can be automatically computed from the current
standard for<br>
non-intersecting polygons:<br>
* for convex polygons: we can use the gravity center (or its
opposite) by testing it<br>
with the current convention (if the gravity center is (0, 0, 0),<br>
remove recursively one vertex, starting from the first one).<br>
* concave polygons: by testing the gravity center of 3 successive
non-aligned vertices,<br>
iterating till one lies inside the polygon by the current
standard (also ensuring<br>
the point is not a vertex or on an edge).<br>
* self-intersecting: the control point would have to be provided,
i.e. after the last<br>
vertex (unless we all agree on a same algorithm, using the NOT
operation to define<br>
the complement polygon).<br>
<br>
Alberto:<br>
If I understand correctly, a polygon with a hole is the
intersection<br>
of a CCW polygon with a (smaller) CW polygon, right?<br>
Why not having used the difference between two CCW polygons?<br>
Is it because the difference in STC-S is not a symmetric
difference and hence<br>
you cannot use the logical XOR operation in a database expression?<br>
(<b>That may advocate to replace the DIFFERENCE by/ or at least to
add a<br>
SYMMETRIC DIFFERENCE in STC :)</b> ).<br>
<br>
<br>
fx<br>
<br>
<br>
</font><br>
<font face="monospace"><br>
</font><br>
<font face="monospace"><br>
</font>
</body>
</html>