Draft note on STC in the Registry
molinaro at oats.inaf.it
Wed Jan 31 09:34:31 CET 2018
Hi Markus, Pierre, all,
2018-01-29 15:10 GMT+01:00 Pierre Fernique <Pierre.Fernique at astro.unistra.fr
> 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)
> 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
>> (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:
>> 12364 12365 12359 49488
>> 49489 49490 49429 49430 49431 49496 49433 49435
>> 49508 49509 49510 49512 49513 49514 49453 49464 49465 49467
>> -- 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:
>> 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...
More information about the registry