Draft note on STC in the Registry

[Marco Molinaro]

Hi Markus, Pierre, all,

2018-01-29 15:10 GMT+01:00 Pierre Fernique <Pierre.Fernique at astro.unistra.fr
>:

>
> 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.
>

I think that especially point 3, but also partly point 2,
talk me into ASCII MOCs.

I only kindly ask, if that's the solution, to have MOC-1.1
and move ASCII MOC (also JSON?) into normative,
otherwise confusion may persist.
(But this last point is up to Apps)

Cheers,
    Marco


>
> 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180131/17ff1987/attachment.html>