Page tree
Skip to end of metadata
Go to start of metadata


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


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 (2019: being rediscussed in IVOA)

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?)
    • † 2018: indication of reference frame in STC-S strings (s_region) is deprecated by the standard. Must rely on another info.

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). 
    -  2019: 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

(Updated May 2019, v10.128; syntax for filters has evolved)

    1. load http://alasky.u-strasbg.fr/Planets/Mars (directly from field "Location" on top of Aladin window)
    2. invert plotting direction: "Edit/properties" -> ascending longitude (will plot the map correctly)
    3. Select preferred map projection: "Projection" menu at right/top ("Sphere" stands for orthographic)
    4. Walk along HiPS; poles are now available
    5. Click Grid (bottom left), select Frame = Planet
  • Superimpose Mars data from a VOTable
    1. 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 (the name, not the icon) in Aladin stack to see table
    2. 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 Menu Item: Catalog / Create a Filter; copy filter text only between { } in this field

    3. check match between feature contours and map (actually inaccurate)
      Indeed: many features are not elliptical, plus there are actual shifts - related to different coordinate systems in map and catalogue (TBC)? - looks like a planetocentric vs planetographic issue



  • Search and query EPN-TAP services available
    1. Filter discovery tree (left panel) by specifying a keyword in field "select":  "obspm" for PADC services, or (better here) "mars"
    2. Select service  jacobsuni→Mars_craters, click on this line in the tree + check box "by critera" and press "Load" in dialog
    3. this opens a TAP query window; select table "mars_craters.epn_core"
    4. Click "Set ra, dec" and choose C1min and C2min
    5. Add constraint "diameter >  200" in the TAP query
    6. Add a filter as in the previous Io example (Aladin & planetary surfaces):

      {
      # 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)
      }

    7. 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 (from C1/C2); 
    • features in display are highlighted in the table (FoV of different color)
    • the s_region contour is also plotted and highlighted; "Show associated FOVs" in Properties panel plots all s_region
  • 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 "Solar System" to discovery tree
    1. Load URL (in Location field) http://alasky.u-strasbg.fr/Planets/HipsList
    2. Open branch "Solar System" (was "/local/Planet")
    3. 2019: All planetary HiPS have been regenerated correctly and plot directly in the correct orientation (longitude = ascending) 

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


  • No labels
Write a comment…