<div dir="ltr">Hi Markus, Pierre, all,<br><div class="gmail_extra"><br><div class="gmail_quote">2018-01-29 15:10 GMT+01:00 Pierre Fernique <span dir="ltr"><<a href="mailto:Pierre.Fernique@astro.unistra.fr" target="_blank">Pierre.Fernique@astro.unistra.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
May I advocate to avoid UNIQ coding in ASCII MOC representation. Mainly for these reasons:<br>
1) The ASCII MOC has been defined for human usage/readability. UNIQ coding is more complex to understand. It has been introduced to mixed order and npix in a "unique" long to avoid multiple tables in FITS MOC packaging.<br>
2) The "regular" ASCII MOC coding is already described in the MOC 1.0 document (in the non normative part) and concretely, it is already supported by MOC libs, notably in the Java MOC library (read and write) and associated tools. Concretely if you cut and paste the example below in Aladin Desktop (prefixed by "draw MOC ...") you are already able to see the spatial coverage result.<br>
3) We have already 1 standard representation (FITS) + 2 suggested alternative ("regular" ASCII and JSON). If we open the door to UNIQ in ASCII, why not use it in JSON... and we we will have 5 alternatives.<br></blockquote><div><br></div><div>I think that especially point 3, but also partly point 2, </div><div>talk me into ASCII MOCs.</div><div><br></div><div>I only kindly ask, if that's the solution, to have MOC-1.1</div><div>and move ASCII MOC (also JSON?) into normative, </div><div>otherwise confusion may persist.</div><div>(But this last point is up to Apps)</div><div><br></div><div>Cheers,</div><div> Marco</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
Pierre</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
Le 29/01/2018 à 13:20, Markus Demleitner a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Marco,<br>
<br>
On Mon, Jan 29, 2018 at 10:43:26AM +0100, Marco Molinaro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If possible, can we have a more complex <spatial><br>
example in §2.3? Even at this early stage the single<br>
cell there looks a bit too simple to exemplify what's<br>
at stake.<br>
</blockquote>
You're right -- I hadn't thought of this.<br>
<br>
I've put in the somewhat more interesting example<br>
<br>
<spatial><br>
4/2068<br>
5/8263,8268-8269<br>
6/<a href="tel:33045-33047" value="+13304533047" target="_blank">33045-33047</a>,33049,33051,<wbr>33069,<a href="tel:33080-33081" value="+13308033081" target="_blank">33080-33081</a>,<br>
33083,33104-33106,33112,<a href="tel:33124-33126" value="+13312433126" target="_blank">33124<wbr>-33126</a>,<a href="tel:33128-33130" value="+13312833130" target="_blank">33128-33130</a><br>
</spatial><br>
<br>
(which, incidentally, is abbreviated from what<br>
ivo://org.gavo.dc/mcextinct/q/<wbr>cone has) in Volute rev. 4721.<br>
<br>
For reference, in NUNIQs, this would look like this:<br>
<br>
<spatial><br>
3092<br>
12364 12365 12359 49488<br>
49489 49490 49429 49430 49431 49496 49433 49435<br>
49508 49509 49510 49512 49513 49514 49453 49464 49465 49467<br>
</spatial><br>
<br>
-- which illustrates that in the typical case, there's not a great<br>
deal of difference between the representation sizes in VOTable<br>
TABLEDATA (in BINARY2, as Mark has already pointed out, the second<br>
form is of course a good deal more compact. But then gzipping the<br>
entire container will probably nix much of that advantage).<br>
<br>
I'd argue the first form is more human-friendly, the second is more<br>
machine-friendly, and I'm not sure what that's telling me.<br>
<br>
As an illustration of the human-friendlyness, consider all-sky:<br>
<br>
0/0-11<br>
<br>
which in NUNIQs is:<br>
<br>
4 5 6 7 8 9 10 11 12 13 14 15<br>
<br>
If that's part of a large document and happens to be, accidentally or<br>
by design,<br>
<br>
4 5 6 7 9 10 11 12 13 14 15<br>
<br>
-- would you have noticed?<br>
<br>
But then: How many people will ever look an serialised MOCs? And of<br>
course, the "the higher the number, the smaller the area" works as an<br>
eyeball criterion for NUNIQs about as well as a "1/" vs. "18/" might<br>
in ASCII.<br>
<br>
-- Markus<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div></div>