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

This page lists requests sent / to be sent to IVOA discussion groups to accommodate VESPA needs.

Roadmap described here: Planetary Science requirements in the VO

Interop May 2017 (Shanghai)

All this to be discussed in advance on mailing lists.


Ask to include VESPA related tools in IVOA Application lists:

  • VESPA :
    web application, EPN-TAP (and PDAP) client / Query databases 
    connected to VO tools via SAMP
  • APERICubes:
    web-based tool
    Spectral cube slicer for PDS3 formatted cubes (VIRTIS on Venus-Express and Rosetta, currently) and GIRAFFE fits.
    Connected via SAMP, both in I/O

SEhelpdesk for this page ( & Pierre Fernique for this pageAdvertise VESPA


  • Evolution of SAMP messages (content) we want to add: 
    • geojson
    • pds3 + pds4 (+ datalink ?)
    example to present as usecase, sending geojson to MIZAR and Planetary Cesium Viewer
PLSMark Taylor and Thomas Bochs

UCDs and Utypes for Solar System

  • See list in EPN-TAP V2.0 parameters (related to parameters)
    UCDs in red and italics/blue are non standard but needed by VESPA.
SEMireille Louys

Discussed in May 2018 (Victoria interop) for inclusion.
  • Add "spectral matrix" UCD (use case = want to know that data can be sent to iPECMan): phys.spectralmatrix
  • UCD for gravitational field "Power Spectrum of Spherical Harmonic Coefficients of Lunar Gravity Model": phys.gravitation
  • Shape model (full 3D shape) or Terrain Model (or Elevation model) with respect to geoid or ellipsoid: phys.shape, phys.shape.elevation


  • How do we pass Utypes and UCDs to VO tools? Really included in VOTables only, not in fits ?
    The reason is apparently related to the length of value fields in fits. 
  • Add fits kw for UCD (and Utypes, if space permits)? 
    Otherwise, data handling in tools depends on how data are transmitted.
this is addressed in SDM2, TBC

ADQL additions

  • we need to look inside a field of list, ie to combine ivo_hashlist_has with LIKE
    e.g. to look for a UCD in a list (and get time vs time;stat.min)
Support of UCDs in
in particular, but also
instrument names, etc

  • Use case for "ivo_hashlist_has" : function to parse list in ADQL. We need an ADQL function to handle a multi valued field. Idea from markus is that we should not asked ADQL transformation but put that in endorsed note. He will help in writing it, but doesnt want to be the handler of it in IVOA. What we have to say, is that we have use case for it target_name, target_class. That also exist in obscore. Moreover this function is used in relational registry interogation and will be handle by Gregory library and DaCHS. We could handle this note if TCG thinks it's the right way to go.
PLSFrançois Bonnarel, Dave Morris, Markus Demleitner

RegTAP functions have been reviewed by TCG, included “ivo_” functions. We can refer to that in EPN-TAP service specification. It is a function to implement on server-side, by data provider. It exist already in DaCHS, it seems to be easy to implement with Gregory Mantelet’s library.

Tools / standards:

  • Spectral aggregates? Required to plot measurements from spectrometers with several channels 
    (very common in our field). 
    Appears to require a formatting standard to store several spectral elements in the same file
  • Computing functions / statistics - I want to get the average of several profiles/spectra sent from a service. Is this SODA-related? Is this a function on the data server? I'm thinking more about a function to call with a selection of data already retrieved on user side.



J-M Glorian?

OK with dedicated script in CASSIS, to be made more generic

    -Implement cross-matches based on s_region (in addition to cone search-like criteria)?
    -Better support of Healpix maps

M. Taylor (passed, TBC for him)
Mark not very excited…
  • Aladin (to be discussed directly with PFernique?): 
    See fits format items
    • stability issue of v9 on Mac / java 1.8 (blocks on my machine at startup very often) - seems OK in v10beta
    • issue with auto hips from files on v9: does not work as expected, and never finishes on my side (TBC with more recent versions)
    • implement E-handed frames in s_region (see STC item)

Pierre Fernique

All those fixed in v10. However open issues are shown on Aladin pages in Confluence

Fits format:

  • Chiara's request for additional keywords to support projections on planetary surfaces
  • Need to implement the planetary ref systems in Aladin, they are part of the fits std:
    MALN + MALT, etc + proj types (see her ex Mars & Venus)
  • Define equivalent for Earth (don't seem to exist)
  • Current fits keywords do not allow for image projections on ellipsoids, even less on a 67P
    (one kw missing, see Chiara's docs)
? - IAU fits commission?Support planetary mapping & surface feature catalogues

STC, etc:

  • s_region is very nice, but we need a E-handed system with longitudes [0, 360[ to respect IAU conventions.
    Additional predefined system required:
    We're currently using UnknownFrame, which appears to be W-handed (it is used like this in Aladin at least). We need something similar but explicitly E-handed. Call it BODY, or BODY-FIXED, or E-HANDED?
    Or combine UnknownFrame with another property?
SEMarkus Demleitner, Dave MorrisSupport body fixed
frames, consistency with
IAU conventions
new version of TAP (v1.1) removes reference frame in box, circle, polygon. Client must do the query correctly, interpreting the TAP service coordinate frame (default is ICRS)
  • AstroCoords for VOEvent: we need to be able to tell that the event occurs at a named planet or a spacecraft (e.g., "Jupiter", "Juno") in the WHERE section.

John Swinbank

 TCG discussion

  • function to parse list in ADQL : We need an ADQL function to handle a multi value field that is resume in a single field. Idea from markus is that we should not asked ADQL transformation but put that in endorse note. He will help in writing it, but doesn't want to be the handler of it in IVOA. What we have to say, is that we have use case for it target_name, target_class. That also exist in obscore. Moreover this function is used in relational registry interrogation and will be handle by Gregory library and DaCHS. We could handle this note if TCG thing it's the right way to go.
    There is also another function to handle Hips in ADQL with first implementation in DaCHS, use case are already there, it's not our goal, but we may use it and it's another argument to build this note and circulate it.
    This is a question to DAL, but Baptiste must ask in TCG a way to build it as input come from different group (Planetary Science, Registry, Hips ?)
  • Endorsement of VOResource schema that is necessary to register EPN-TAP service in RofR registry. That yet stop for non compliance (ivo-id containing # characters should be valid)


  • open
  • 2nd item fixed in Dec 2017?


  • Using ORCiD for identification of author ?
  • See STC comments also
BCJohn Swinbank



It would be very important to be able to specify if one wants to search for model outputs, experimental data or observations. Right now it is not possible to specify it, and if used blindly it can be very confusing!

Simulations may currently include the prefix ;meta.modelled after measurement_type (not always implemented, though). We're asking a more comprehensive system to IVOA, to also support experimental data - but this has to be agreed upon.

Review board



Check here for recent discussions (mostly the first one which addresses these questions):


• pos.bodyrc needs to be used as primary (relates to body coord system, as pos.lunar)


Not needed

• At least a new pos.projection is required (there is only a very specific pos.lambert)


• UCD needed for VOeventsSE

• Clarify usage of inf / -inf / Nan in ADQL (should apparently exist, as per DALI - but do not)SE

• Correct/clarify definition of reflectance in 2018 sheet: 
add Q | phys.reflectance | Radiance factor (received radiance divided by input radiance)

Radiance factor is the same as I/F; in this case, this is divided by input irradiance (not radiance), i.e. by solar flux.

We can keep phys.reflectance for the reflectance factor (standard quantity for lab measurements, currently listed as phys.reflectance.factor)  = ratio of radiance to that of a Lambertian disk at the same distance and illuminated under the same incidence (also called radiance coefficient)

In any case, this is not necessarily similar to albedo (which is typically integrated spectrally, and is then related to thermal equilibrium). I would keep albedo for more general purpose.


How do we handle asymmetric error bars? Some services need to have stat.error.min/max SE

How do we specify an additive constant / offset? The only close match is arith.zp, specificSE

  • No labels
Write a comment…