TWiki> IVOA Web>WebPreferences>HiPSRFC (revision 6)EditAttach

HiPS 1.0 Proposed Recommendation: Request for Comments

Public discussion page for the IVOA HiPS 1.0 Proposed Recommendation.

The latest version of the HiPS specification can be found at:

Reference Interoperable Implementations

Comments from the IVOA Community and TCG members during RFC period: 2016-12-15 - 2017-01-26

Comments from Markus Demleitner

p. 16, "Each line is ended by CR..." Are you sure you want what this is saying? The only platform I'm aware of that ever used single CRs as line separators was the classic Mac, and AFAIK with OS X they migrated to having just LF as a line separator as $DEITY had originally intended. So, essentially what you're specifying here will make everyone equally unhappy. Note that the IETF somewhere requires anything with a text/ major media type to use CRLF as line separator. So, much as I'd like to see single LFs here, I guess you should just require CRLF as line separator throughout and be done with it. (Incidentally, on p.22, there's mention of "property1\nkey1"; \n is the conventional escape for LF rather than CR, so whatever you do, this would need reconciliation).

p. 17, point 3. First, there's "image His" rather than "image HiPS". Then -- Obscore 1.1 now has "measurements" as dataproduct_type instead of "catalog". Everyone will be grateful if we keep terminology uniform between standards, and given that ObsCore was there first, I guess HiPS would have to bite the bullet and change.

p. 18, point 6. What should catalog HiPSes put into hips_file_format?

p. 18, point 8: hips_frame. For equatorial, you should mention in the specification that you're assuming the ICRS reference frame (you do, don't you?).

p. 18, table header: I suppose "Rec or Should" should be "Req or Should", no? Linguistically more consistent would be "Must or Should", but since you'd have to change all the letters in the table then I'd say it's not worth the effort.

p. 18, "obs_description". You're saying this contains "one paragraph", which people would probably take to mean "a couple of (perhaps physical) lines", which of course is outlawed by the basic metadata format. To reduce the risk of confusion, I'd suggest writing something like "longer free text description of the dataset"

p. 20, "Catalogue HiPS metadata": Are you sure we can't just require metadata.xml? If I were to write a client and all I had to work with are the column labels from the TSV, I'd be cross with you.

Also, two typos:

p. 12 "The mean method is appropriated": -> appropriate

p. 19, hips_order: Deeper -> Deepest (or perhaps Highest?)

-- MarkusDemleitner - 2016-12-15

Comments from TCG members during the TCG Review Period: 2016-12-15 - 2017-01-26

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

(1) Sentence "The more you ..." starts in italic and ends in plain text

(2) "Going beyong...": This sentence suggests that HIPs can be used even for non spatial data. Must be clarified

(3) P5 "... given level is covers an .."
The HEALPix tile defintion vs HEALPix cell is not clear (to me at least). After reading back and forward, I understand that one tile contains data of one HEALPix cell at an order ranging between 0 and a deepest order which must be lower that the HEALPix order of the resampled data. This key concept, very important to understand the following, could be a bit more developed

(4.2.1) It is first said that HIPs tiles must contain "orginial pixels" and after that "original pixels are resampled": not consistant. Better to say that " HIPs tiles must contain orginal pixels resamples inthe the HEALPix geometry".
"... tile hierarchy is S orders" must or should?
The sub section "To avoid tiles ...." actually introduces the concept of deepest order. Would be nice to mention it before to enter 4.2.1.1

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

Registry Working Group ( _Markus Demleitner, Theresa Dower )

(1) 4.4.2.1 Is there a terribly strong reason to require 7-bit ASCII in the TSVs? This would make Registry's life quite a bit harder when we produce a HiPS of the Registry (once we have enough coverages), as our authors and titles can potentially contain all kinds of odd characters. My take is: Just allow UTF-8. There's few platforms where that's a problem these days, and UTF-8 doesn't clobber Tabs, so there's probably little that can go severly wrong.

(2) While I like the term obs_regime in the table on p. 18, I have to mention that the same concept, with essentially the same terms (but different spelling -- ugh) is called waveband within VODataService's vs:Coverage element. Now, the different concept names probably are not really dramatic, but the differences in the terms contained are fairly painful, and that pain will only increase as we may extend the list with neutrinos, gravitational waves, or whatever. So, here's what the VODataService creators came up with about ten years ago:

"Radio" | "Millimeter" | "Infrared" | "Optical" | "UV" | "EUV" | "X-ray" | "Gamma-ray"

Couldn't you just adopt this list or even better, defer to VODataService's vs:Waveband type so future additions will just pull through? I realise it's a pain given the installed base, but perhaps clients can contain a mapping for a while to ease transition?

(3) Thanks for making the implemented global HiPS list something of an epiphenomenon of a proper registration -- much appreciated. Since, on the other had, I suspect that all actual clients go through that global list exclusively, I think either sect. 6 should say somewhere that that service exists and how to use it (probably in a non-normative section) or there should be an appendix discussing that. Except, of course, if you actually have plans to phase out that service. But if, as I suspect, it is what clients are expected to do for the forseeable future, it should IMHO be documented in this standard.

-- MarkusDemleitner - 2016-12-15

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Dave Morris )

Data Curation & Preservation Interest Group ( Françoise Genova )

Operations Interest Group ( _Tom McGlynn, Mark Taylor )

Knowledge Discovery Interest Group ( Kaï Polsterer )

Theory Interest Group ( _Carlos Rodrigo )

Standards and Processes Committee ( Françoise Genova)


Edit | Attach | Watch | Print version | History: r25 | r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r6 - 2016-12-16 - LaurentMichel
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback