Draft note on STC in the Registry

[Pierre Fernique]

Hi,

May I advocate to avoid UNIQ coding in ASCII MOC representation. Mainly 
for these reasons:
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.
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.
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.

Cheers
Pierre

Le 29/01/2018 à 13:20, Markus Demleitner a écrit :
> Hi Marco,
>
> On Mon, Jan 29, 2018 at 10:43:26AM +0100, Marco Molinaro wrote:
>> If possible, can we have a more complex <spatial>
>> example in §2.3? Even at this early stage the single
>> cell there looks a bit too simple to exemplify what's
>> at stake.
> You're right -- I hadn't thought of this.
>
> I've put in the somewhat more interesting example
>
>   <spatial>
>      4/2068
>      5/8263,8268-8269
>      6/33045-33047,33049,33051,33069,33080-33081,
>      33083,33104-33106,33112,33124-33126,33128-33130
>    </spatial>
>
> (which, incidentally, is abbreviated from what
> ivo://org.gavo.dc/mcextinct/q/cone has) in Volute rev. 4721.
>
> For reference, in NUNIQs, this would look like this:
>
>    <spatial>
>      3092
>      12364 12365 12359 49488
>      49489 49490 49429 49430 49431 49496 49433 49435
>      49508 49509 49510 49512 49513 49514 49453 49464 49465 49467
>    </spatial>
>
> -- which illustrates that in the typical case, there's not a great
> deal of difference between the representation sizes in VOTable
> TABLEDATA (in BINARY2, as Mark has already pointed out, the second
> form is of course a good deal more compact. But then gzipping the
> entire container will probably nix much of that advantage).
>
> I'd argue the first form is more human-friendly, the second is more
> machine-friendly, and I'm not sure what that's telling me.
>
> As an illustration of the human-friendlyness, consider all-sky:
>
>    0/0-11
>
> which in NUNIQs is:
>
>    4 5 6 7 8 9 10 11 12 13 14 15
>
> If that's part of a large document and happens to be, accidentally or
> by design,
>
>    4 5 6 7 9 10 11 12 13 14 15
>
> -- would you have noticed?
>
> But then: How many people will ever look an serialised MOCs?  And of
> course, the "the higher the number, the smaller the area" works as an
> eyeball criterion for NUNIQs about as well as a "1/" vs. "18/" might
> in ASCII.
>
>          -- Markus