<div dir="ltr">Hi Markus,<br><div class="gmail_extra">thank you for reacting this quick.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The example gives, IMHO, a good idea of what </div><div class="gmail_extra">we're talking about.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As for what's the best or simply the chosen one</div><div class="gmail_extra">I have no clear idea, only my opinion that it could</div><div class="gmail_extra">be better to have these coverage elements machine</div><div class="gmail_extra">readable than human readable.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"> Marco</div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-29 13:20 GMT+01:00 Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marco,<br>
<span class=""><br>
On Mon, Jan 29, 2018 at 10:43:26AM +0100, Marco Molinaro wrote:<br>
> 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>
<br>
</span>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">33045-33047</a>,33049,33051,33069,33080-<wbr>33081,<br>
33083,33104-33106,33112,33124-<wbr>33126,33128-33130<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>
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br></div></div>