Held 2/6/2016, Paris Observatory
Objectives:
- Improve interactions between Aladin and VESPA tools/services
- Get inputs from Aladin for more elaborate uses in Planetary Science
- Identify additional quantities to define in the VO
Participants
- OBSPARIS: Stéphane Erard, Baptiste Cecconi, Pierre Le Sidaner, Andrieu François, Cyril Chauvin
- GEOPS : Chiara Marmo
- CDS: Pierre Fernique, Sébastien Derrière, Francois-Xavier Pineau
Minutes by P. Fernique (translated by SE, to be checked) + notes by SE
Action items from CDS/ObsParis VESPA meeting, 2 June 2017
About HiPS
- CDS will carry on with assessment of Planeto-HiPS generation, now using USGS data (https://planetarymapping.wr.usgs.gov), previously converted to fits by Chiara.
- Agreement to host these HiPS (<50GO) at Obs de Paris (PLS), as a mirror of CDS site
(done; in 2019, mirrors exist at PADC [planetary] and IAS [selection] - see here: https://aladin.u-strasbg.fr/hips/list) - Set up of a vocabulary of body to label, to be used in properties associated to each HiPS -> see below
- See with Thomas Boch that Aladin Lite can also plot such Planeto-HiPS (correct sense of longitude, depending on a keyword in properties)
- Flattening doesn't seem to be an issue with HiPS - just a matter of graphical representation (as long as lon/lat system is not degenerated, e.g. as on 67P)
About VO registry (relative to discovery tree in Aladin v10)
- Agreement on the principle to store more info (e.g., product_type) in records of the VO registry associated to EPN-TAP servers. In particular, a keyword indicating celestial body involved:
target_name, target_class, dataproduct_type, measurement_type - at least
Recognition of EPN-TAP parameters relative to overlays in Aladin
- In EPN-TAP services, Aladin will identify (hard coded) columns c1min & c2min as longitude & latitude, and s_region as containing an STC-S "footprint" to be plotted (action CDS)
- Parameter s_region will include mention of celestial body of interest, using a keyword from (or added) current STC vocabulary (will avoid plotting a footprint on another body, e.g. Mars craters on a Lunar map) => (action ObsParis)
- The idea is to use, e.g., the MARS_C codes from the STC (planetocentric only for solid surfaces + choice for giant planets)
- Prepare a demo to show use case (Titan?)
Open questions:
- If planeto HiPS develop beyond the cases described above, who will be in charge of generating them? CDS, or another planetary science team? (mirroring is always possible).
- In practice this has been done by CDS for the first set of 60 HiPS - How will clients handle different column contents in ObsTAP, EPN-TAP, and generic TAP? - should be through Utypes - in practice UCDs are used for this purpose.
- How to characterize an EPN-TAP (or ObsTAP) service content as all columns are always there, although they may be empty (i. e., their presence is not related to service content)?
- Who will maintain, and how, the list of keywords associated to each planetary body (for STC-S et for HiPS properties, as well as planeto-FITS)?
see this page: GeoFITS: Planetary Data FITS format and metadata convention
Aladin V10 demo with Mars data + EPN-TAP services + discovery tree
- Use last Aladin prototype : http://aladin.u-strasbg.fr/java/AladinProto.jar (>=9.628)
- Load HiPS from Mars THEMIS (resolution = 13" / pixel) :
- load http://alasky.u-strasbg.fr/Planets/Mars (directly from field "Location" on top of Aladin window)
- invert plotting direction: "Edit/properties" -> ascending longitude (will plot the map correctly)
- Select preferred map projection: "Projection" menu at right/top ("Sphere" stands for orthographic)
- Walk along HiPS; poles are now available
- Click Grid (bottom left), select Frame = Planet
- Superimpose Mars data from a VOTable
- load http://aladin.u-strasbg.fr/java/demo/MarsInfo.xml
this is a USGS catalogue of Martian features, all type mixed (selection of craters, plus volcanoes, regions, vallis, etc)
double click on MarsInfo in Aladin stack to see table - load and activate filter to present these data: http://aladin.u-strasbg.fr/java/demo/mars_feature.aj
this will draw ellipses as feature contours, with names
filter can be seen by right-clicking the "Crater" item in Aladin stack, then Properties / Advanced mode / Crater - check match between feature contours and map (actually inaccurate)
Indeed: many features are not elliptical, but there are actual shifts - related to different coordinate systems in map and catalogue (TBC)?
- load http://aladin.u-strasbg.fr/java/demo/MarsInfo.xml
- Search and query EPN-TAP services available
- Filter discovery tree (left panel) by specifying a keyword in field "select": "obspm" for PADC services, or (better here) "mars"
- Select service jacobsuni→Mars_craters, click on this line in the tree + check box "by critera" and press "Load" in dialog
- this opens a TAP query window; select table "mars_craters.epn_core"
- Click "Set ra, dec" and choose C1min and C2min
- Add constraint "diameter > 200" in the TAP query
- Add a filter as in the previous Io example (Aladin & planetary surfaces):
#AJS
filter Filter1 {
{
# scale is 64.5 arcsec/km
draw ellipse(64.5*${diameter}/2, 64.5*${diameter}/2, 0) rainbow(${degradation_state},0,3)
draw ${feature_name} rainbow(${degradation_state},0,3)
}
} Check match with map features
- Note: comment on TAP table
- s_region is visible in the table with a button called FOV.
- Clicking sends the view to the correct location (I guess from C1/C2), but the s_region contour itself is not plotted - and "Show associated FOVs" in Properties panel does not either. Is this normal? We would love to display the s_region contours this way.
- Note: Comment on the feature catalogue from USGS
- This is obviously a selection for test purpose
- UCDs are picked up so that Aladdin loads the table easily, but are fake (coordinates in particular)
- Includes a link to an USGS web service that does not work for some reason.
It seems that USG have changed their information system recently, see here: https://planetarynames.wr.usgs.gov/SearchResults?target=MARS
they now include kml footprint on each feature page.
- New branch "Planet" to discovery tree
- Load URL (in Location field) http://alasky.u-strasbg.fr/Planets/HipsList
- Open branch "/local/Planet"
- Note that all HiPS presented here (except for Mars) have very low resolution and don't allow the user to invert longitude direction - for an unknown reason, may be related to the way the HiPS is generated. They should all be replaced by versions similar to Mars THEMIS HiPS (classic Hipsgen generation method)
Extra items
- Concerning HEALPix density maps in TOPcat, see: https://arxiv.org/abs/1611.09190 (+ apply to ex. about VIRTIS coverage on 67P in VESPA PSS paper)
- Identify / complement Calabreta & Greissen values to indicate coordinates on Solar System bodies: 4 characters, ending in LT or LN (eg MALT/MALN) - only main objects (including Sun) + a generic value for body fixed frames. Have it validated by IAU fits commission.
- Projections : see Chiara's LPSC abstract for a selection among ISIS projections
- See possible usage of MOCs on planetary surfaces. In particular to: accelerate computation of intersections between datasets (faster than s_region, available in tools rather than server, and more general); get backward references to source data; data fusion, including spectral dimension.
- Usage of HipsCube, e.g. for atmospheric data
- Open WMS images in Aladin for plot (like in Mizar)?
Actions
- Assessment of COOSYS in result VOtable from a query, so that Aladin knwos what to do with it - OK if only a single frame present.
- Stéphane Erard: check personal Mars HiPS and s_region from mars_craters service
- June: Previous mismatch between Mars HiPS and s_region vector (longitude inverted) - could be related to inversion in my (SE) Mars HiPS - indeed the longitudes have to be inverted in Aladin to get a proper map, and longitudes are locked to the data, so I end up with W longitude in the HiPS. TBC
- August: regenerated correctly, there is only one way to get correct longitudes. s_region still inverted, clearly because UnknownFrame is assumed W-handed
- Conclusion: need to ask for an extra E-handed frame for use with s_region
- To anticipate other limitations, ask for one frame / planet - will prevent plotting Mars features on Venus map.
- Do we also need variations, e.g. Mars_C & Mars_G for planetographic & -centric? Would that be an STC-S string?
- Prepare demo, possibly on Titan (although there is no Titan frame?) + make a list of frames required for Aladin
- Stéphane Erard - new assessment of HiPS generation from a bunch of files