This page focuses on VESPA. Other access modes to planetary data predate VESPA and are still in use.

VO standards used in VESPA

General IVOA standards used by VESPA

Figure 1 identifies the IVOA standards used in VESPA


EPN-TAP is used to access all possible data types; a specific client (VESPA portal / user interface) converts from EPN-TAP standard conventions to user parameters. In this sense, the set (VESPA portal and EPN-TAP) constitutes a middleware between the user and the data.

EPN-TAP provides access to granule level as defined by data providers, not to the underlying / subgranule structure (e.g., file structure). However, post-processing may be applied to a data product retrieved via VESPA (e.g. script extracting spectra from a cube, see CRISM use case or APERICubes).

Some useful extensions need to be defined or finalized, including:

EPN-TAP v2 doc ~ finalized Aug 2019, to be submitted to IVOA as a Working Draft (WD).

Access to on-line codes

However, on-line codes also need specific access.

Service registration

Required for VESPA development

Solar System data description and handling require specific capabilities that are not always implemented for astronomy. The most important are listed here.

Coordinate systems

• The STC standard does not seem practical to accommodate the variety of coordinate frames in use in the Solar system.


We stick to the principle to provide a description of physical quantities via UCDs rather than in Utypes - VO tools use UCDs to understand the data, and this proves more flexible & easy than Utypes.

Although Solar System specific UCDs have been proposed in the recent year, the work is still in progress. Proposals for new UCDs are regularly forwarded to the semantics group of IVOA. 

Unresolved sources may be measured as incident flux. 
Resolved sources are either measured in radiance or reflectance (= I/F). 
Lab measurements are provided in slightly different scales.

Flux can be described as phot.flux.density;em.wl

Radiance is best referred to as phys.luminosity;phys.angArea;em.wl in UCD 1.23, which is uncomfortably complicated. More appropriate would be phys.radiance (note: phot.radiance was proposed in v 1.3 but seems TBC for the thermal range)

Observed reflectance is usually provided as I/F (= radiance factor), which is the ratio of radiance to the reflected solar flux at the target distance (provided as sr-1). The only current match is phys.albedo, which is not very specific and implies a spectrally integrated quantity. More appropriate would be phys.reflectance

For lab measurements, standard quantities are reflectance/pi or reflectance/cosine of incidence angle, TBD

Normalized spectra may also need specific descriptors

Various kinds of albedos could be identified by specific UCDs

Initially, only phase angle is described in the UCD doc. Incidence (or "solar zenithal angle" in some contexts, but this may be misleading) and emergence angles at least are required (and possibly azimuth).

Obvious choices are pos.incidenceAng, pos.emergenceAng, pos.azimuthAng

pos.resolution (deprecated and replaced by pos.Angresolution) was useful to provide resolution on a linear distance axis, for instance on a planetary surface.

time.update could be used to provide the date of last update in a service (e.g. to speed up mirroring actions)

+ see UCDs used to describe EPN-TAP parameters.


VESPA contributions to the IVOA vocabulary are discussed elsewhere:

Time variations

Daily and seasonal variations cycles are commonly studied, and may require specific UCDs (is it in Characterization?)

Use of scenarios must be considered (e.g. simulated Martian years for atmospheric studies)

Time itself need to be related to the target whenever coordinated observations are involved - this is best way to handle multispacecraft observations

ADQL queries

Several problems have been spotted so far with ADQL requests in this context:

Tools / special requirements

Open issues are related to:

Other datatypes: