This section provides a more complete description of EPN-TAP parameters, with meaning and usage. 

Definition, types, UCDs, and a short definition are provided here: EPN-TAP V2.0 parameters

Although additional, service-specific parameters can be used, care must be taken to avoid duplications or variations on existing parameters. 

Mandatory parameters

1- Granule references

These 3 keywords must always be informed. If granule grouping is not relevant, use a single value for granule_gid (and obs_id can be identical to granule_uid).

granule_uid

Identifier for this row. This parameter is a primary key in epn_core tables, i. e., not two different rows may share the same granule_uid.

There can be only one file associated to a granule (plus possibly a thumbnail for quick-look purpose in a search interface).

Basic ascii characters are allowed, including internal spaces, except for the # character. 

obs_id

Associates granules derived from the same data (e. g. various representations / processing levels). May be the ID of the original observation.

granule_gid

Associates granules of same type (e. g. same map projection, or geometry data products) - think of it as a simple and convenient way to group or differentiate types of data.

When several files relate to the same data, this parameter helps distinguishing them: this will allow the user to select the type of data of interest. E. g., a service may provide links to calibrated images, plus raw data and ancillary information for every observation; these will share the same obs_id, but will have different granule_gid.

2- Data Description

dataproduct_type

The dataproduct_type parameter describes the high level scientific organization of the data product linked by the access_url parameter, or directly included in the table (in which case the value is 'ci' for catalogue_item). EPNCore currently defines several types listed below. The data provider must select the type most adapted to his data. In complex situations (e. g., when a file contains several data products), several types can be used to describe the same granule by using a hash-separated-list — although using several granules to describe the file content may be a better solution.  

In EPN-TAP these types are identified by a 2-characters ID, so that multivalued queries are unambiguous. Possible IDs are listed below with their meaning:

• im (= image): scalar field with two spatial axes, or association of several such fields, e. g., images with multiple color planes, from multichannel or filter cameras. Preview images (e. g. map with axis and caption) also belong here. Conversely, vectorial 2D fields are described as spatial_vector (see below).
• ma (= map): scalar field / rasters with two spatial axes covering a large area and projected either on the sky or on a planetary body, associated to spatial_coordinate_description and map_projection parameters (with a short enumerated list of possible values); each pixel is associated to 2D coordinates (e. g., fits with WCS). This is mostly intended to identify radiometrically calibrated and orthorectified images with complete coverage that can be used as reference basemaps, but this also includes HiPS.
• sp (= spectrum): measurements organized primarily along a spectral axis, e. g., radiance spectra. This includes spectral aggregates (series of related spectral segments with non-connected spectral ranges, e. g., from several channels of the same instrument, various orders from an échelle spectrometer, composite spectra, SED, etc).
• ds (= dynamic_spectrum): consecutive spectral measurements through time, organized primarily as a time series. This typically implies successive spectra of the same target / field of view.
• sc (= spectral_cube): sets of consecutive spectral measurements with 1 or 2D spatial coverage, e. g., imaging spectroscopy. The choice between image and spectral_cube is dictated by the characteristics of the instrument (which dimension is most resolved and which dimensions are acquired simultaneously). The choice between dynamic_spectrum and spectral_cube is related to the uniformity of the field of view and by practices in the science field.
• pr (= profile): scalar or vectorial measurements along 1 spatial dimension, e. g., atmospheric profiles, atmospheric paths, sub-surface profiles, traverses…
• pf (= photometric_function): scalar or vectorial measurements along 1 angular dimension, e. g., phase or polarization curves, phase functions, emission-phase function sequences… Does not handle variations along several angular axes. This is typically associated to variations in illumination angle parameters.
• vo (= volume): measurements with 3 spatial dimensions, e. g., internal or atmospheric structures, including shells/shape models (3D surfaces).
• mo (= movie): sets of chronological 2D spatial measurements (consecutive images)
• cu (= cube): multidimensional data with 3 or more axes, e. g., all that is not described by other 3D data types such as spectral cube or volume. This is intended to accommodate unusual data with multiple dimensions. This can be used for 3D ancillary data associated to spectral cubes, e. g., providing the coordinates or illumination angles for each spectrum.
• ts (= time_series): measurements organized primarily as a function of time (with exception of dynamical spectra and movies, i. e. usually a scalar quantity). Typical examples of time series include space-borne dust detector measurements, daily or seasonal curves measured at a given location (e. g. a lander), and light curves.
• ca (= catalogue): applies to a granule providing a catalogue of object parameters, a list of features, a table of granules in another TAP service, a list of events, a list of spectral lines... The result metadata table of a service query can also be considered as a catalogue. Catalogues can be provided as VOTable (possibly containing multiple tables, although this is not supported by SAMP). It is good practice to describe the type of data included in the catalogue using a hash-separated-list (e. g., a table of spectra should be described by ca#sp, so that it will respond to a query for spectra).
• ci (= catalogue_item): applies when the service itself provides a catalogue with entries described as individual granules, in particular when there is no associated file (e. g., a list of asteroid properties or spectral lines). Catalogue_item can be limited to scalar quantities (including strings), and possibly to a single element. This organization allows the user to search inside the catalogue from the TAP query interface. In practice, Spice kernels are identified as catalogue_items because they are usually associated to a set of scalar parameters.
• sv (= spatial_vector): vector information associated to localization, such as a spatial footprints, a GIS-related element, etc —  e. g. a kml or geojson file (STC-S strings are provided though the s_region parameter, though). This includes maps of vectors, e. g., wind maps.
• ev (= event): introduces individual VOevents formatted according to IVOA standard (or possibly events with other formatting). Characteristics are provided via the event_* parameters.

Example TAP queries:

SELECT TOP 100 FROM iks.epn_core 
 WHERE dataproduct_type LIKE '%sp%'

or 

SELECT TOP 100 FROM iks.epn_core 
 WHERE ivo_hashlist_has(dataproduct_type, 'sp') = 1

will return only image data (both syntaxes handle lists of values).

measurement_type

The measurement_type parameter defines the physical quantities contained in the data, using UCDs. It relates to the reported quantity, not to the type of experiment. Therefore only UCD related to physical quantities can be used; e. g., phys.absorption;em.opt.I is eligible, while pos.lunar.occult (occultation by lunar limb) is not. This is used in particular to provide indications to visualization/processing tools.

Whenever several quantities are comprised in the data, the measurement_type parameter must describe all these quantities, using multiple UCDs in a hash-separated-list. 

Examples:

• For images in general (i. e., actual measurements with a camera), the relevant UCD is phot.radiance;obs.image (or phot.radiance;obs.image;stat.uncalib if not calibrated).
• For spectra: phot.radiance describes radiance, phys.reflectance stands for reflectance factor (= I/F), and phot.flux.density for a flux vector (irradiance). The associated spectral vector is described by UCDs em.wl, em.freq or em.energy, and the related error has the form stat.error;phys.reflectance (for I/F).
• Quantities derived from modeling/simulation are described by the regular UCD with ";meta.modelled" appended. 

processing_level

The processing_level parameter is intended to provide the user with a quick evaluation of data readiness level. EPNCore uses a simplified scheme as described below. 

Several classifications are in use in different contexts, as summarized in the table below. EPNCore uses the CODMAC / PDS3 levels but removes the intermediate calibration levels; this is equivalent to using the simplified PDS4 levels and maintaining a separate level for ancillary data. "Partially calibrated" datasets are in general considered as not calibrated, but this evaluation is up to the data provider, depending on context. "Ancillary" data include all extra information documenting the measurements, in particular coordinates or geometry files. Several processing levels can be included in the same service (in particular calibrated and ancillary data, but also raw data). When mixed in the same file, the choice is left to the data provider.

Note that the optional processing_level_desc parameter is available to provide, e.g., a specific encoding of processing levels related to a data collection, or more details about partial calibrations.

Most EPN_TAP data services are expected to include Calibrated or Derived data. 

Notes:

• This table is a compilation of information from PSA, PDS4, and ObsCore documents
• The PDS3 column corresponds to the PDS3/PSA PRODUCT_TYPE keyword
• Descriptions are extracted from PSA and PDS4 documentations, with comments.

3- Target description

target_name

The target_name parameter identifies a target by name or ID. The target may be any Solar System body, exoplanet, planetary sample, or meteorite, plus in some cases astronomical objects or spacecraft. Any other feature (craters, regions, atmospheric layers…) must be named using the optional feature_name parameter (see 4.3.3). This parameter can be multivalued only to describe several targets related to a granule (e. g. with events). Alternative names of the same target must not be listed here, but may be provided through the optional alt_target_name parameter. In some rare cases no target name can be defined, so this parameter can remain empty.

The best practice is to use the official designation of the target as defined by IAU. This parameter is case sensitive (mixing lower/upper cases) and all values must use the standard spelling and case; unusual characters (such as intermediate spaces) are allowed, except quotes and hashes (preferably changed to _ , which is the single-character wildcard in TAP queries). Data providers must be aware that services which do not use the IAU designations might not be accessible by the clients. Conversely, users must be aware that some services containing data of interest might not be visible, if they do not use the recommended IAU nomenclature for planetary bodies. The quaero name resolver (https://ssp.imcce.fr/webservices/ssodnet/api/quaero/) from IMCCE may help data providers (as well as users) to handle multiple denominations; it is available from the VESPA portal to support queries.

Concerning celestial objects (at fixed position, i. e., stars, galaxies…) the name should be identifiable through Simbad (http://simbad.u-strasbg.fr/simbad/).

Other best practices are listed below:

• The Exoplanet Encyclopedia provides a nearly complete list of currently known extrasolar planets: http://exoplanet.eu/ (also available as an EPN-TAP service)
• Meteorite catalogues can be found here: 
  http://www.nhm.ac.uk/research-curation/research/projects/metcat/search/indexsing.dsml 
  and http://www.lpi.usra.edu/meteor/index.php
• The catalog of lunar samples is available here: http://www.lpi.usra.edu/lunar/samples/
• Other planetary samples are listed in topical web sites, e. g. samples from the Stardust mission are described here: 
  http://curator.jsc.nasa.gov/stardust/catalog/
• Consortia such as the IGSN issue IDs for samples
• Asteroids: Usage is to use preferably name (if it exists) or principal designation (the number is not used here, it can be included in alt_target_name)
  
• Meteors: the IAU Meteor Data Center assigns IDs to meteors and meteor showers
• Calibration targets: values can relate to existing names in a given archive (e. g., the PSA contains values such as bias, checkout, dark, flatfield, internal source…)

Example TAP queries:

SELECT TOP 100 FROM spectro_asteroids.epn_core 
 WHERE (target_name LIKE '%Ceres%' OR target_name LIKE '%Vesta%') 
 AND (ivo_hashlist_has(target_class, 'dwarf_planet') = 1 OR ivo_hashlist_has(target_class, 'asteroid') = 1)

Will return data only from 1 Ceres or 4 Vesta.

The LIKE operator is used here to handle cases when 1) the name includes a number, either '1 Ceres' or '(1) Ceres', which (although not recommended) may occur in some services, 2) the special case of dwarf planets, which may be tagged as asteroids, or as 'dwarf_planet#asteroid' (recommended, see below). 

The usage of LIKE cannot be generalized to all target_class values, because of  'planet' which also responds to 'dwarf_planet' and 'exoplanet'. The ivo_hashlist_has function smoothly handles all values of target_class.

Example:

1P is the official IAU designation for comet Halley

target_class

The target_class parameter identifies the type of the target. Solar System bodies are defined without ambiguity by the couple target_class and target_name. In other cases, targets may have no proper name (i. e., samples), but the target_class parameter must be informed in all cases. The possible values for target_class are:

• asteroid
• dwarf_planet
• planet
• satellite
• comet
• exoplanet
• interplanetary_medium
• sample
• sky
• spacecraft
• spacejunk
• star
• calibration

Usage:

• Any target has a unique target class.
• It is however good practice to use a hash-separated-list to associate dwarf_planet#asteroid, so as to remove any ambiguity (e. g., to help support older catalogues).
• If several target_name values are provided for a granule, several target_class may be present as hash-separated values.
• "interplanetary_medium" refers in particular to interplanetary dust observed in context (not to samples), or to simulations (e.g., of primordial nebula). Details can be provided through target_region.
• "sample" refers to lunar or planetary samples, to meteorites, but also to terrestrial samples, e. g., in laboratory studies.
• "satellite" stands for natural satellites only - artificial satellites are handled though spacecraft or spacejunk.
• "star" is used typically for calibration targets, and for the Sun.
• "sky" should be used for all other celestial bodies, usually referred to by their sky coordinates. It also includes the Interstellar Medium.
• "calibration" is used for observations only related to instrument or signal calibration, including dark current, flat field, reference sample (in lab), etc (use of "calibration" with planetary bodies is left to data providers).
• planetary rings are not considered a target class, but appear in target_region with their planet indicated in target_name.

Comment:

All "Types" of objects used by the quaero resolver are included in the EPNCore list: "asteroid", "spacecraft", "comet", "exoplanet", "spacejunk", "satellite", "planet", "dwarf planet", "star".
Additional EPNCore classes are: "interplanetary_medium", "sample", "sky", "calibration".

4- Axes

EPNCore describes the data coverage along 8 main axes: time, spectral, spatial (3 coordinates), and viewing geometry (3 angles). 

Coverages along the time/space/spectral axes are described with a range and a resolution and/or sampling step. 

Each quantity is a set of 2 parameters providing min and max values. They must both be present with the same value when min = max. Additional single parameters provide extra information: spatial_frame_type, s_region, and the optional shape parameter.

time (min/max)

The time_min and time_max parameters provide the date and time of acquisition in the observer frame. 

The time parameters are always provided in UTC and formatted in Julian Days (expressed in double precision). EPNCore uses standard JD to avoid ambiguity with time origin (as opposed to ObsCore which uses Modified JD). The use of double precision floats insures an accuracy on the order of 1 ms, which is considered sufficient for search purposes (the initial accuracy is preserved in the data itself). A client front-end may expose times formatted in a more convenient way for human users.

Example TAP queries:

• Search data contained in a time range:

SELECT TOP 100 FROM spectro_asteroids.epn_core WHERE time_min > 2455197.5 AND time_max < 2455927.5

• Search data described by a start time parameter

SELECT TOP 100 FROM spectro_asteroids.epn_core WHERE time_min BETWEEN 2455197.5 AND 2455927.5

Time range is by default provided in the observer frame (i. e., at the observer location at that moment), which is almost always the native time in the data. For instance, space-borne observations are usually documented with spacecraft on-board time, which is expected here (provided as JD, not as on-board clock timing). For other cases, the location where time is measured must be provided through the time_refposition parameter.

To support space-borne vs ground-based campaigns, multiple spacecraft observations, or survey of periodic events, measurement times need to be corrected for light path. Whenever comparisons are potentially involved, the use of the target_time_min and target_time_max parameters is recommended in addition to time_min and time_max to make this kind of comparison simpler.

Non-compulsory parameters may be used to accommodate additional, specially formatted time scales such as native on-board time for space borne observations. The information of the time_min and time_max parameters is however highly recommended for all observations, as it is used by default to search datasets.

time_sampling_step (min/max)

These parameters provide the sampling step in seconds for measurements of dynamical phenomena, and for computations. This is the time between 2 successive measurements or data, which is mostly relevant when the measurements are regularly spaced. This may also reflect an input parameter, e. g., for simulations or ephemeris computations. This parameter is intended to allow the user to search for time-resolved observations of dynamic phenomena, but can also accommodate the "repetition time" for several types of instruments.

time_exp (min/max)

These parameters correspond to the integration time (or exposure time) of measurements in seconds. They provide an estimate of the time resolution for dynamical phenomena, as well as an indication of relative S/N ratio inside a given dataset. This time is usually shorter than the time_sampling_step if both are present. It provides the overall integration time, i. e. individual exposure time x number of summed frames when relevant. 

spectral_range (min/max)

The spectral_range parameters define the upper and lower bounds of the spectral domain of the data. This quantity is conventionally expressed on a frequency scale in Hertz, although the client front-end may propose conversions to other units/scales. The spectral range and associated parameters only apply to electromagnetic waves. See the optional parameters from the particle spectroscopy extension for particle energy or mass detection.

Since this is the standard parameter to identify a spectral range, it is recommended to fill it even for images obtained through a filter (central wvl ± FWHM/2, or even central wvl in both parameters, may be enough for search purposes). The svo Filter Profile Service (http://svo2.cab.inta-csic.es/theory/fps3/) provides responses for many instrument filters; bandwidths can be retrieved easily with a python library: https://github.com/hover2pi/svo_filters

with c = 2.99792458E8 (m/s)
spectral_range_min  = c*E6 /spectral_range_max_micron
spectral_range_max  = c*E6 /spectral_range_min_micron
(notice the inversion)

spectral_sampling_step (min/max)

The spectral_sampling_step parameters provide the spectral separation between the centers of two adjacent filters or channels. Similar to the spectral_range quantities, they are expressed on a frequency scale in Hz. 

These parameters are most relevant for radio observations (long wavelengths / low frequencies) with regular sampling. They can also help distinguish between Nyqvist and sub-Nyqvist sampling rates (together with resolution).

with c = 2.99792458E8 (m/s)
df = c*1E6 dlam / lam^2 (from wavelength, with lam and dlam in micron)
df = c*1E3 dlam / lam^2 (same if dlam provided in nm)
df = c/1E-2 du (from wavenumber u in cm-1)

spectral_resolution (min/max)

The spectral_resolution parameters actually provide the (dimensionless) resolving power: | lambda / Delta(lambda) | = | fq / Delta(fq) |  

These parameters are mostly intended to provide an order of magnitude, e. g., to distinguish between Fourier spectrometers, grating spectrometers or filter cameras, or between observations related to surfaces or atmospheres. This is often most relevant for optical/infrared observations (short wavelengths / high frequencies).

spectral_resolution_min  = abs( spectral_range_min_micron / max(DeltaLambda) )
spectral_resolution_max  = abs( spectral_range_max_micron / min(DeltaLambda) )

c1 (min/max)

c2 (min/max)

c3 (min/max)

These parameters provide up to three spatial coordinates of the measured target (note that these parameter names contain no underscore before min/max, in contrast with the other ones). The coordinates depend on the spatial_frame_type parameter defined below. All services must handle three spatial coordinates, even if the third one is always set to NULL. Some coordinates are measured along a circle and must handle 0-meridian crossing, therefore min/max values are actually start/stop values defining the footprint. In body-fixed coordinates, c1 is longitude and is always counted eastward; c1min is therefore the westernmost longitude and c1max the easternmost one; the opposite applies to Right Ascension on the sky. Note that the c3 parameter is related to the observed area, relative to a reference surface in most cases; the target distance (e. g., geocentric distance for ground based observations, or spacecraft distance) is introduced by the optional parameters "earth_distance" or "target_distance".

Example TAP queries:

Requests on C1/C2 coordinates often involve comparisons between two bounding boxes. Below are typical examples in body-fixed coordinates, when poles are not included in the bounding box (note that this type of query is more compact and more accurate if parameters s_region or shape are provided).

Increasing longitudes: data range intersects [100, 200]
SELECT TOP 100 FROM vvex.epn_core 
 WHERE ((c1min <= c1max AND c1min <= 200.0 AND c1max >= 100.0) OR (c1min > c1max AND (c1min <= 200.0 OR c1max >= 100.0)))
 AND c2max >= -20.0 AND c2min <= 20.0 AND spatial_frame_type = 'body'

0-crossing longitude range: data range intersects [300, 20]
SELECT TOP 100 FROM vvex.epn_core 
 WHERE (c1min <= 20.0 OR c1max >= 300.0 OR c1min > c1max) AND c2max >= -20.0 AND c2min <= 20.0 AND spatial_frame_type = 'body'

Increasing longitudes: data range is included in [100, 200]
SELECT TOP 100 FROM vvex.epn_core 
 WHERE c1min >= 100.0 AND c1max <= 200.0 AND c1min <= c1max 
 AND c2max <= 20.0 AND c2min >= -20.0 AND spatial_frame_type = 'body' 

0-crossing longitude range: data range is included in [300, 20]
SELECT TOP 100 FROM vvex.epn_core
 WHERE ((c1min >= 300.0 AND c1max <= 20.0) OR (c1min >= 300.0 AND c1max >= 300.0) OR (c1min <= 20.0 AND c1max <= 20.0)) 
 AND c2max <= 20.0 AND c2min >= -20.0 AND spatial_frame_type = 'body'

In order to make uniform requests possible, spatial coordinates provided in the EPNCore table must be standardized. However, they can be provided in several systems types, as defined by the spatial_frame_type parameter. The native coordinate system used with the dataset can be described by parameters spatial_coordinate_description and spatial_origin. This is intended to provide this information prior to loading the data, especially when several coordinate systems are available in the same service. Descriptions for EPN-TAP are provided in a separate document (draft here: Planetary Coordinate Systems). Secondary coordinates can be introduced using additional parameters, e. g., c1 and c2 ranges identify the visible region of a planetary disk, while extra RA / Dec parameters provide location on the sky at this moment, and subobserver_longitude_min/max and subobserver_latitude_min/max provide the coordinates of the disk center.

c1_resol (min/max)

c2_resol (min/max)

c3_resol (min/max)

These parameters provide a simple estimate of resolution in the same frame/units as c1/c2/c3. For instance, if spatial_frame_type = 'celestial' it can accommodate the FWHM of the PFS on the sky (in degrees). The client front-end may propose more appropriate units to the user, depending on context (e. g., angular resolution in mas, distance in m…).

spatial_frame_type

Provides the "flavor" of the coordinate system, which defines the nature of the spatial coordinates (c1,c2,c3) in the EPNCore table and queries, and the way they are defined. A value is always required (use "none" if not applicable). This may be different from the coordinate system associated to / included in the data themselves. The reference frame itself is defined by the spatial_coordinate_description parameter, and the frame center can be specified using the spatial_origin parameter in case of ambiguity. The possible types are described below:

• celestial: 2D angles on the sky, i. e., right ascension c1 and declination c2 + possibly heliocentric distance in c3 (in au); although this is a special case of spherical frame, the order and conventions are different. Right ascension is provided in degrees. ICRS coordinates are assumed by default, but other frames may exist, e. g. HPC (Helio-Projective Cartesian) is centered on the Sun; such frames are identified from the spatial_coordinate_description parameter. For ground-based observations, Earth distance may be provided in the earth_distance parameter (not in c3).
• body: 2D angles in body-fixed frame: longitude c1 and latitude c2 + possibly altitude as c3. A planetocentric system with eastward longitudes in the range (0,360)° is required for service interoperability. IAU 2009 planetocentric convention applies, in particular eastward longitudes and a north pole located on the north side of the invariant plane of the Solar System for planets and satellites. Unless otherwise specified in spatial_coordinate_description, this will be interpreted as the current IAU frame at the moment of access, in particular for the definition of the prime meridian.   
  Parameter c3 is measured above the reference ellipsoid, and can be <0 for interiors. Two other parameters are available to provide other vertical scales if needed (radial_distance and altitude_fromshape).
  Planetocentric rotating frames are defined as spherical (rather than body).
• cartesian: (x,y,z) as (c1,c2,c3). This provides spatial coordinates in km. 

• spherical: (r, theta, phi) as (c1,c2,c3), as defined in ISO standard 80000-2:2009; r = radius; theta = zenith angle/colatitude/inclination; phi = azimuth (E longitude). Angles are provided in degrees. When related to the sky or tied to a solid body, "celestial" (with RA/Dec) or "body" (with E longitude/latitude) frames must be used instead.
• cylindrical: (r, theta, z) as (c1,c2,c3); r = radius in km; theta = azimuth; z = height in km. The angle is provided in degrees.
• none: to be used when no spatial frame is defined for the dataset. This is intended to prevent useless searches when space coordinates are not defined (a non-zero value is required by the mixin in DaCHS).

This parameter, although related to the specific coordinate system in use, is mostly intended to identify the nature of the coordinates provided in the service table (e. g., angles versus distances). This parameter is provided as a column of the EPNCore table, to ensure it can be queried through the basic TAP mechanism. Although it will in general remain constant along the table for simple services, this parameter can vary from granule to granule and a value must therefore be provided in any query that includes spatial coordinates. Whenever additional coordinates are provided, they must be stored in extra columns of the table. If several different frames are mixed to provide the main coordinates, the use of different granule_gid may help clarify the situation. At any rate, easy access to the data must be considered during the design of the service. 

incidence (min/max)

The incidence parameters define the upper and lower bounds of the incidence angle range in the data (also known as Solar Zenith Angle). This is always indicated in decimal degrees, and usually ranges from 0 to 90° (with 0° indicating the normal to the surface). Incidence and emergence angles may be counted relative to the normal of the ellipsoid model, or to the local normal (e. g., using a 3D shape model). In case the two systems are included in the data, these keywords introduce the values relative to the ellipsoid (local values may be provided through non-compulsory parameters).

emergence (min/max)

The emergence parameters define the upper and lower bounds of the emergence, emission, or viewing angle range in the data. This is always indicated in decimal degrees, and usually ranges from 0 to 90° (with 0° indicating the normal to the surface). Incidence and emergence angles may be counted relative to the normal of the ellipsoid model, or to the local normal (e. g., using a 3D shape model). In case the two systems are included in the data, these keywords introduce the values relative to the ellipsoid (local values may be provided through non-compulsory parameters).

phase (min/max)

The phase parameters define the upper and lower bounds of the phase angle range in the data (i. e., scattering angle - 180°, or light source-target-observer angle). It is always indicated in decimal degrees, and may range from -180 to 180° (with 0° corresponding to opposition, i. e., light source in the back of the observer). Negative values may refer, e. g., to geometry before opposition, depending on context. Phase (phi), incidence i and emergence e are partly related:

abs(i - e) < phi < i + e

If the azimuth angle a is available instead of the phase angle, the latter can be derived from knowledge of the three angles:

cos phi = cos i cos e + cos a sin i sin e

s_region

This parameter introduces a footprint as a contour. The s_region parameter should be given for geolocalized data products in 2D, most notably on the sky (using RA, Dec) or on planetary surfaces (using E longitude, latitude) to communicate the geometry of a feature or an observation's footprint. This is a single parameter with no min/max declinations. Coordinates are provided in the same reference system as c1/c2 parameters, clients must therefore inspect spatial_frame_type before interpreting such contours. Any type of contour that works with ADQL's geometry operators (CONTAINS, INTERSECTS...) is legal here.

The shape parameter introduces another type of footprint, with potential extension to time coverage. When both are present, care must be taken that they are consistent.

In the VOTable serialization the s_region parameter is represented as either an STC-S string value with xtype='adql:REGION' or a DALI 1.1-compliant numeric array value with xtype='point', 'circle' or 'polygon'.

Implementation notes:

Two syntaxes are possible:

1) The original ObsCore s_region one (currently limited to polygons) — a string with syntax: '{(lon1,lat1), (lon2,lat2), … }' (with no quotes) where (lon1,lat1) = (10.d, 5d), character d included (it stands for degrees). Pairs (lon1,lat1) must sample the contour in a sequence provided in direct (counter-clockwise) sense as viewed from the observer. Notice that the result of a TAP query is an STC-S string, which has different format (as in ObsCore). 

2) Modern DALI 1.1 geometries — a numeric array providing either a point ('lon lat', with no quotes), a circle ('lon lat radius', with no quotes), or a polygon (sequence of at least 3 'lon lat' pairs, with no quotes). For polygons, pairs (lon lat) must sample the contour in a sequence provided in direct (counter-clockwise) sense as viewed from the origin (when on the sky) or from the observer (when on planets).

5- Data origin

instrument_host_name

This parameter provides the name of the observatory, spacecraft, or facility that performed the measurements. A hash-separated-list of host names must be provided for integrated data sets. In the EPNCore table, the acronym is preferred to the full name to avoid long strings and related errors (however, both values can be provided in the list). An observatory list is being developed in Europlanet-2024/VESPA by merging various sources (draft here: Observatory Facility Database). For lab measurements, this is typically the name of the facility.

Reference lists include:

• for ground-based observations, the list of IAU observatory codes:
  http://www.minorplanetcenter.net/iau/lists/ObsCodesF.html 
  However, this list is not intended to include all ground-based observatories, and a complement still needs to be identified (including e. g. radio-telescopes). 
• a reasonably complete list of radio-telescopes is available here:
  http://en.wikipedia.org/wiki/List_of_radio_telescopes
• the WiseRep list also provides a  database of telescopes and instruments: 
  https://wiserep.weizmann.ac.il/aux/telescopes 
  https://wiserep.weizmann.ac.il/aux/instruments
• Concerning space-borne data, the most complete list of international planetary missions and orbital observatories is found here (included in a complete list of space missions with ID): http://nssdc.gsfc.nasa.gov/nmc/
  Planetary missions are also listed here: http://nssdc.gsfc.nasa.gov/planetary/chronology.html. 
• Alternatively, the PDS dictionary defines values for many mission names: 
  http://pds.nasa.gov/tools/dictionary.shtml
  Other mission names are supported by the SPICE system, but only as ID codes: 
  https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/FORTRAN/req/naif_ids.html

instrument_name

Identifies the instrument(s) that acquired the data. A hash-separated-list of instruments must be provided for integrated datasets. Service providers are invited to include multiple values for instrument name, e. g., complete name and usual acronym. This will allow queries on either "Visible Infrared Thermal Imaging Spectrometer" or "VIRTIS" to produce the same reply. For ground-based observations and lab measurements, this is typically the name of the instrument in use (not the telescope or facility). Non-compulsory parameters are available to provide more information about sensors, instrument modes, etc.

Example:

Visible Infrared Thermal Imaging Spectrometer#VIRTIS

A draft list of recommended values is available here: Observatory Facility Database

The most complete ready-to-use list of international planetary missions and orbital observatories is found here: http://nssdc.gsfc.nasa.gov/nmc/

Instruments on board planetary missions in particular are listed here: 
http://nssdc.gsfc.nasa.gov/nmc/experiment

6- Granule call-back info

These parameters provide ancillary information for routine processing after a query. These 4 keywords must always be informed. Dates are provided in ISO 8601 format. 

service_title

The schema name of the service: it provides a unique acronym for the service/table, constant throughout the service. This parameter is intended to identify the source of the data in later stages, e.g. when handling multiservice results. When designing the service, care must therefore be taken to use a title not already ascribed to another EPN-TAP service. Special/unusual characters must be avoided (including #, ?, etc). Other identifiers (ivoid…) may be used in a future version.

Existing EPNCore services can be listed from the registry:
select schema_name, table_utype from rr.res_schema natural join rr.res_table where table_utype LIKE '%epn%'

creation_date

Provides the date when the granule was introduced in the service.

modification_date

Provides the date when the granule was last updated (intended to speed up mirroring between sites, and to flag new calibrations). When unknown or not relevant, the creation date is replicated here.

release_date

Provides the date when the granule becomes public (intended to support a proprietary period). When unknown or not relevant, the creation date is replicated here.

Optional parameters

EPN-TAP can query any parameters included in the metadata table. Some of these parameters are defined precisely but are relevant only to very specific data services. Those are not mandatory, but must be implemented as defined in this section when present. Besides, the names of optional parameters are reserved for this particular usage and must not be used to introduce other quantities. 

7- Data Access Reference

Data access parameters

If the data are not included in the table (i. e., provided in separate files), these 3 parameters must be present and informed. If alternative formats are also provided, they must be described in other granules with the same obs_id and possibly different group ID, or via datalink. Whenever the data consists in a few scalar fields, these parameters are best replaced by parameters providing the data itself in the table, which makes them searchable from values (e. g. mass, in a table providing the masses of Solar System bodies).

access_url

The data of interest are often stored in a file, not in the table itself. In this very usual case, the access_url parameter provides a complete path to the data products on the network, so that they are accessible for download by plotting or processing tools. This parameter links to a file, a web service (e.g., PlanetServer_CRISM service) or a script (e.g., Titan_profiles service); in such cases, the link must include the adequate arguments so that data is downloaded. This parameter must link to the actual data, not to a file of metadata nor a document (the datalink_url parameter can be used for this purpose.

access_format

Access_format provides the format of the data file linked through the access_url parameter.
The data may be stored under native format, and no format conversion is required to set up an EPN-TAP service; this field can therefore include reference to unusual formats. However, VO ready formats are required to take advantage of visualization and processing in VO tools. Consistently with ObsCore, possible values are MIME-types written in lower cases; the most common ones are listed on this page: Data Formats and MIME Types.

access_estsize

The access_estsize field provides an order of magnitude of the size (in kilobytes) of the file available via the corresponding URL. It is intended to provide an indication that can help to tune download functionalities in an application, depending on data volume and transfer bit rate.

Miscellaneous file metadata

thumbnail_url

The thumbnail_url parameter contains the URL of a reduced version of the data product used for quick-look purpose (e. g., a small jpeg image, typically 200x200 pixels). This may be handy in the case of big data files or unusual data formats, to facilitate data selection by the user. EPN-TAP clients such as the VESPA portal use this thumbnail for on-line quick-look, which therefore provides important added value to a service. Preferred formats include jpeg and png, which are handled easily in a web browser. Larger or more elaborate previews must be provided as independent granules and identified via a granule_gid different from the data. 

file_name

The file_name parameter introduces the name of the data file, with extension but no path information. In many data services, the file name encodes the most relevant metadata and may be a very handy access mechanism for specialists. In services providing sets of files in a complicated directory tree (e. g., related to a spacecraft operation plan), the file_name parameter is a handy key to perform automatic operations such as mirroring, pipeline processing, etc - a web service is available to retrieve a file from the file_name parameter in any EPN-TAP service (File grabbing interface (fgi)). Its use is therefore always recommended when data are provided in separate files, i. e., not included in the table.
All file_name values in the EPNCore table are case sensitive and must reflect the filename of the product provided through access_url; for instance, if access_url is a link to a script converting an ascii file to VOTable, file_name must refer to the outcome of this script, in this case the VOTable.

access_md5

This parameter introduces a MD5 Hash for the file when available, to be used as a checksum.

accref

Although not an EPNCore parameter, this name is reserved for internal use. It must not be used explicitly, as DaCHS uses it internally in some situations (although it is not included in the answer to a TAP query): it is used to introduce a URL with datalink (present in epncore2 mixin) and is also generated automatically in the q.rd when using the localfile mixin (when accessing data files located on the DaCHS server itself); it may also be used to handle proprietary periods in DaCHS.

datalink_url

This parameter is used to provide extra accesses through a datalink/SODA interface. This interface can provide access, for instance, to previews, documentation, related data products (such as progenitors, calibration files, etc.) and to cut-out or processing services on the data.

Implementation note:

Datalinks can be parameterized with input values retrieved from the current granule at the time of ingestion. When multiple EPN-TAP parameters are required to build a datalink, they can be first concatenated in an extra parameter in the table (often called ds_id).

8- Supplementary description

bib_reference

The bib_reference parameter introduces an individual bibliographic reference at granule level. This provides the origin of the data, e. g., if the resource is a compilation of data from various origins. References are best provided as bibcode (as used e. g. by ADS), as DOI, or as arXiv reference, although other formats are acceptable.

A generic regular expression for bibcode (from IPDA discussions) is: [0-9]{4}[A-Za-z0-9\&\.]{5}[A-Za-z0-9\.]{9}[A-Z\.] 

See http://adsabs.github.io/help/actions/bibcode

publisher

This parameter refers to the publisher of the data service, not necessarily at the origin of the data. Currently a free format string.

processing_level_desc

This parameter provides further details about processing_level if needed, e.g., a specific encoding related to a data collection, or more details about partial calibrations. Provided as a free format string.

internal_reference

The internal_reference parameter can be used to identify granules (or sets of granules) intimately related to the current one. e. g., in a service containing both observations and results of analysis of observation sets, internal_reference can be used to provide the set of observations used to compute a result. This contains a hash-separated-list of granule_uid in the same service (which implies that those never contain the # character).
This is specifically intended to provide internal references in services which would otherwise need to be split in several tables, and it must only be used as a last resort (clever use of obs_id and granule_gid is usually more efficient).

external_link

The external_link parameter can be used to provide extra information that does not fit easily in the table, and is intended for human reading only. This parameter must contain a single URL. This is typically an extended discussion of a granule on a web site, which may include images, tables, or other documents. For instance, the individual planet pages of the Encyclopedia of exoplanets are linked with this parameter, as they contain many links and sometimes web applets. Alternatively, the parameter can provide a link to a web service related to this granule; for instance, in the HRSC/MEx service (hrsc3nd) it displays a detailed view of the image with zooming functions for quick examination at full resolution.

species

The species parameter introduces the chemical species of interest in simple data services. The formatting is very basic and simply uses the standard formula in ascii, e. g., H2O for water, CO2 for carbon dioxide or Fe for iron. This is one of the few query parameters provided in case sensitive form, using the standard chemical notation. This format can only accommodate atoms and simple molecular species, and does not support isotopic variations.  

An example application is related to atmospheric composition: a table providing vertical profiles of gaseous species with altitude. All columns are abundances and are described by the same measurement_type parameter. The use of the "species" parameter allows identifying the various species and accessing the requested information. This of course is restrained to simple cases.

If more elaborated compositional information must be included, the use of parameter species_inchikey is recommended. InChiKeys identify molecule, including isotopes, but not the physical state or phase.

messenger

This parameter is a generalization of waveband from VODataService (used e. g. in ConeSearch and SSA). It provides a rough indication of the spectral domain, e. g. when variable in a large archive. In addition, values for messengers can describe particles other than photons. Possible values are from the IVOA vocabulary (and case matters) http://www.ivoa.net/rdf/messenger.

filter

This parameter introduces the standard name of a filter used during measurements. This is reserved for filters in imaging mode (no grating/grism #, etc). There is no predefined list, because of the large variety of possible denominations, but the best practice is to use a short and accurate ID. This VO service provides an extended list of references: http://svo2.cab.inta-csic.es/svo/theory/fps3/

This is intended to document the results of a search, rather than a search parameter. Therefore, it is recommended to also fill the spectral_range_min/max parameters to describe filter imaging - this is the only way to make filter imaging easily searchable.

alt_target_name

This parameter introduces alternative names of the target, especially when they are more usual than the official IAU one (e. g., Halley vs 1P).

A frequent usage is to store a hash-separated-list of all alternative names for small bodies to avoid ambiguities (e. g., for asteroids: name, number, principal and provisional designations). Although this situation never occurs for small bodies, care must be taken to replace possible # characters by _ in target names (e. g., for samples).

feature_name

Introduces a supplementary name to provide more details about the observed target. It is intended in particular to accommodate a local name (crater, surface feature, region…) whereas target_name is reserved to identify the whole body (Mars, Moon, Ceres…). Use of official features names defined by IAU (http://planetarynames.wr.usgs.gov/) is preferred when relevant.

target_region

Specifies a type of region on the target. This parameter only introduces generic regions (e. g., atmospheric layer, internal structure…), not specific local names which must be handled using the feature_name parameter.

Values are best selected from the IVOA rendition of the Unified Astronomy Thesaurus: http://www.ivoa.net/rdf/uat

Older sources (some of them may be integrated in the UAT) include:

• IVOA thesaurus: http://www.ivoa.net/rdf/Vocabularies/vocabularies-20091007/IVOAT/
• IAU thesaurus: http://www.vocabularyserver.com/trex/en/
• Spase dictionary http://www.spase-group.org/

Example: 

"atmosphere", "surface", "ionosphere", "ring"
The same values can be given in the subject keywords of the service's registry record.

shape

This parameter introduces a footprint as a MOC (healpix-based). It is intended to support space/time coverages, most notably on the sky (assuming RA, Dec coordinates) or on planetary surfaces (assuming E longitude, latitude). This is a single parameter with no min/max declinations. It must contain a MOC 2.0 ascii string (MOC or STMOC). The result of the query must have xtype = "moc" (or possibly "stmoc" or equivalent in future standards) for proper handling in TAP.

The shape parameter may appear together with s_region, which introduces a simpler type of footprint (2D contour). Shape has precedence over s_region. When both are present, care must be taken that they are consistent.

Description of coordinate frame

spatial_coordinate_description

spatial_origin

These two parameters provide a description of the spatial frame in use, depending on the spatial_frame_type parameter. Both parameters relate to the coordinates provided in the EPNCore table, not necessarily to those included in the data products. 

Spatial_coordinate_description provides an acronym of the Coordinate Reference System as discussed in Planetary Coordinate Systems. For body-fixed frames, IAU/SPICE/WMS strings such as IAU20xx:49900 are eligible - in this case, the final 00 which stands for planetocentric E-handed is the only valid option (refers to EPN-TAP standard on c1/c2 coordinates). If absent the current IAU coordinate system is assumed, depending on context. 

Spatial_origin may be used to identify frame center in specific situations, using either target_name (referring to target center) or the IVOA vocabulary (http://www.ivoa.net/rdf/refposition). Other values may be used, e. g., to introduce specific geometries for simulations.

Examples

spatial_coordinate_description: ICRS, IAU_MARS, IAU2000:49900
spatial_origin: Geocenter, Mars, (spacecraft)

Spatial_coordinate_description and an epoch derived from time_min/max can be used to feed the COOSYS element of VOTable 1.4 when its value is constant throughout the table (notice that most EPN-TAP coordinate frames are not standard values in this vocabulary at the time of writing):

<COOSYS ID="system" epoch="<epoch>" system="<spatial_coordinate_description>"/>

time_refposition

Indicates where the time is measured, which can be a planet or a spacecraft — this does not handle time zones on Earth. This knowledge is required to cross-correlate event-based observations, in particular to indicate light-path differences. It applies to the time_min and time_max parameters (while target_time_min/max always refer to the target in the FoV). If this parameter is not informed, time is expected to be provided in the observer frame (related to instrument_host_name), which is not necessarily fixed in the Solar System.

Values for time_refposition may specify a target name (referring to target center) or spacecraft name, or use the IVOA vocabulary (http://www.ivoa.net/rdf/refposition) including future versions of the hierarchy proposed at https://wiki.ivoa.net/internal/IVOA/InterOpMay2019TDIG/topocenter.pdf.

Examples

Geocenter, (solar system bodies), (spacecraft)

time_scale

Provides the time scale applying to time_min and time_max parameters. UTC is assumed when no value is provided, since this is the expected value in most observational data services. Some services (in particular computational ones) may need to specify different time scales by using other using standard acronyms — values are preferably taken from the IVOA vocabulary: http://www.ivoa.net/rdf/timescale

Both time_scale and time_refposition can be used to feed the TIMESYS element of VOTable 1.4 when their values are constant throughout the table (this is best avoided otherwise, e. g., when grouping coordinated observations from various locations in the Solar System):

<TIMESYS ID="time_frame" refposition="<time_refposition>" timeorigin="JD-origin" timescale="<time_scale>"/>

Target configuration and observing geometry

The next pairs of parameters provide additional location in time and space, and require min/max values. They are independent and can appear separately:

solar_longitude (min/max)

Solar longitude (a.k.a. heliocentric longitude, or ecliptic longitude of the Sun, traditionally noted Ls) is the Sun-Planet vector angle counted from the planet position at N hemisphere spring equinox. It provides a measurement of season.

Ls = 90° corresponds to the northern summer solstice, Ls = 180° to the northern autumn equinox, and Ls = -90° to the northern winter solstice. Although it is most usually applied to Mars and Titan (using Saturn's Ls), this notion can be enlarged to any planetary body without ambiguity.

This should not be confused with the true anomaly of the body (which is the same angle counted from the perihelion position), nor with the longitude of the subsolar point (see below).

local_time (min/max)

Provide the local time at the observed area. These parameters are provided in unit of target rotation divided by 24 and are measured from local midnight, i. e., in decimal (local) hours (range from 0 to 24, must increase with time at a given location). 

target_distance (min/max)

The target_distance parameters introduce the distance of the observer to the observed area (in km) along the line of sight. This is mostly intended for space borne data, where it provides the spacecraft-target distance in km. For ground-based observations the earth_distance_min/max parameters should be used instead (in au).

target_time (min/max)

The target_time parameters introduce the time measured in UTC scale at the target. This is intended to directly correlate simultaneous observations such as ground-based support and space-borne observations, or multi-spacecraft campaigns. Values are given as TIMESTAMP. 

earth_distance (min/max)

sun_distance (min/max)

These two parameters provide the corresponding distance of Earth or Sun to the target at the time of observation (in au). When the target is the Sun or Earth, use the target_distance_min/max parameters to provide the distance to the observer.

subobserver_longitude (min/max)

subobserver_latitude (min/max)

Provide coordinates of sub-observer point, in particular sub-Earth point (disk center) or central meridian for ground-based observations (this is different from the FoV location which is provided in c1/c2 parameters). The min/max pair is required to support long exposures related to time series, especially on giant planets to test target attitude.

subsolar_longitude (min/max)

subsolar_latitude (min/max)

Provide coordinates of sub-solar point, especially for disk images. The min/max pair is required to support long exposures related to time series.

ra, dec

Sky coordinates of the target can be provided in addition to standard coordinates, in which case they must be stored in these parameters. This may for instance document the location of a planet in a celestial image, while the main coordinates c1/c2 are used to provide the observed area as longitude and latitude. ICRS coordinate system is assumed; right ascension is provided in degrees (similar to ObsCore). RA and DEC parameters are interpreted correctly by most VO tools, therefore no min/max variations are allowed to maintain compatibility with existing software. 

Vertical scales on planets

In body-fixed frame, parameters c3min/max, if present, introduce a vertical range counted from a reference surface, typically the reference ellipsoid for the current target.

Two other parameter pairs can be used provide different vertical scales, and must be considered for atmosphere-related services when available/relevant:

radial_distance (min/max)

Distance of observed area (at c1/c2) from body center, measured in km. Not to be confused with target_distance (which provides the distance from observer to observed area). 

altitude_fromshape (min/max)

Altitude of observed area (at c1/c2) above local surface, measured in km. The local surface is provided by a DTM or a shape model. This parameter typically provides the height in the atmosphere.

Parameter c3 can be used to select services/data in a given altitude range above the ellipsoid, while radial_distance and altitude_fromshape provide other convenient vertical scales to compare observations from various origins. This use of c3min/max also applies to planetary interiors (c3 is then <0) and measurements at high altitude/distance. 

Extensions

EPN-TAP extensions are subsets of optional parameters related to a specific field of data, based on several implemented services.
When the corresponding quantities are present, they must be introduced by these parameters to favor interoperability of services.
The concept of extension refers to the way associated parameters are discussed and defined together when a new field needs EPNCore vocabulary.
Although they are intended to be used together, all such parameters are available independently provided that the meaning and usage are preserved. 

9- Particle spectroscopy extension

These parameters are related to the spectral distribution of particles only - for electro-magnetic waves, the spectral_* parameters apply.

When used, these parameters define an extra axis and must all be present. This set defines an additional axis for particles energy, all with min/max values.

particle_spectral_type

The particle_spectral_type parameter specifies the type of axis in use: either 'energy' (provided in eV), 'mass' (in amu), or 'mass/charge' (in amu/qe).

particle_spectral_range (min/max)

The particle_spectral_range parameters define the upper and lower bounds of the spectral domain for particles. Depending on the particle_spectral_type parameter, this quantity is expressed on an energy, mass, or mass/charge scale, with respective units eV, amu, or amu/qe.

particle_spectral_sampling_step (min/max)

The particle_spectral_sampling_step parameters provide the spectral separation between measurements, in the same scale and unit as particle_spectral_range.
This parameter is mostly intended to provide an order of magnitude.

particle_spectral_resolution (min/max)

The particle_spectral_resolution parameters correspond to the actual resolution of the measurements, and are provided in the same scale and unit as particle_spectral_range.
This parameter is mostly intended to provide an order of magnitude.

10- Solar System Objects extension

Most services providing descriptions of solar system objects contain no observations (only inferred properties).
Dedicated parameters are defined for the most common quantities.

mean_radius, equatorial_radius, polar_radius

These parameters are used to provide solar system object sizes (in km)

diameter

Target diameter, or equivalent diameter for binary objects (in km)

mass

Solar system object mass (in kg)

sidereal_rotation_period

Solar system sidereal rotation period (in hour)

semi_major_axis, inclination, eccentricity, long_asc, arg_perihel, mean_anomaly

Provide the standard orbital parameters (distance in AU, angles in degrees)

epoch

Provides a date of interest in JD

See discussion page: orbital parameters

magnitude, flux, albedo

Provide values of respective quantities (flux in mJy).

When target_class = asteroid, dwarf_planet or comet, the following parameters can be used:

dynamical_class

introduces the class of small body, from an enumerated list. The draft list includes: TNO, MBA, NEO - add OCC (Oort Cloud comet), JFC (Jupiter family comet) here, and Centaur, Trojan (but which planet?)

dynamical_type

introduces a subdivision of the above, from an enumerated list. It currently includes:

• NEO (complete): Atira, Aten, Apollo, Amor
• TNO (complete, but check values): res 2:5 (develop?), res 1:2 (develop?), Plutino, Hot classical, Cold classical, Scattered disk object, Detached object, Inner Oort object

See discussion page: Small bodies sub-types

taxonomy_code

provides taxonomy codes for small bodies, typically related to spectral properties.

11- Maps

map_projection

Provides map projection description (preferably as FITS name or code) or parameters as a free string — for instance, several services use this to store proj4 parameters. This refers to the data, not necessarily to the spatial coordinates in the table (which have to be east-handed).

map_height, map_width

These parameters give the number of pixels along the two axes of a raster map. This specification does not constrain the orientation of such maps, and hence 'width' and 'height' do not correspond to physical directions.

pixelscale (min/max)

Pixel size at the target (usually at surface), in km/pixel.

map_scale

A string providing scale as a ratio (e.g., "1:50000").

12- Contributive works

These parameters are intended to specify the data origin in services compiling amateur data, detection networks, experimental facilities, or any service distributing data provided by multiple sources. 

observer_name, observer_id, observer_code

Provide the name, ID and possibly internal code of the observer. Name is provided as free text.

observer_institute, observer_country

Provide the affiliation of the observer, as free text.

observer_location, observer_lon, observer_lat

Give broad location and geographic position of the observer or telescope. observer_location can be used when the exact location cannot be released (small telescopes).

This set will be extended with parameters dedicated to observing networks.

Parameters from other extensions

Parameters from other extensions may be helpful in this context:

original_publisher - Services compiling data from many sources can use this parameter to refer to the source of the data

The data_calibration_desc parameter from the spectroscopy extension can be used to provide information on post-processing (this is preferred over a parameter named "comment")

producer_name, producer_institute provide reference to who produced the data, especially for experimental data services

13- Experimental spectroscopy

Specific *_desc parameters describe the sample and the experimental setup. Although optional, they are important to provide the context. They introduce free descriptive strings which are not intended as search parameters.

Note: VOTable are often better supported than fits files by VO spectral tools, and are therefore the preferred option to distribute spectral files if format conversion has to be considered. For dimensionless data (e. g., reflectance), units="" (VOunit standard)

producer_name, producer_institute

Provide reference to who measured the sample, as free text.

sample_id

Additional ID of the sample, e. g., a specific fraction of a meteorite (in addition to target_name). Intended to refer to a pre-existing catalogue of a collection, will therefore contain a name/ID mainly for local use. 

sample_classification

Provides composition as group, class, sub-class, etc… of sample concatenated in a hash-separated-list with no particular order (this allows for flexible searches with LIKE and % or ivo_hashlist_has; this is in practice the only way to ensure that the user gets all results). It should include the specification "meteorite" plus the meteorite type when applicable, as well as description of (main) mixtures ingredients. Meteorite types can be provided as in Krot et al 2005. Dana (Dana et al 1997) or Struntz (Nickel 2001) classification tags can be used for minerals. To reduce the likelihood of false positives, minor and trace components must not be included in sample_classification.

Example below are taken from the PDS_speclib service:
Terrestrial mineral:
 "natural#solid#earth#mineral#unclassified#nesosilicate#unclassified#olivine"
Lunar sample:
 "natural#solid#moon#rock#unclassified#igneous#unclassified#pyroxene"
Martian meteorite:
 "natural#solid#mars#rock#unclassified#unclassified#unclassified#unclassified#meteorite#snc"

species_inchikey 

Provides an accurate machine-oriented description of species involved, as per IUPAC standard (Heller et al 2015). InChiKeys are fixed-length strings which do not include #, and are therefore consistent with the hash-separated-list syntax.

grain_size (min/max)

Provide the particle size range in µm. A very large value (eg, >1000 µm) can be used locally in a service to identify bulk material - see if we define a code for this (-1 could do, but we also have to reserve a code for N/A). This is really grain_size, since particle is reserved for elementary particle spectroscopy.

azimuth (min/max)

Provides azimuth angle in degrees - see if negative values of angles can have a special meaning (also for phase angle)

pressure, temperature

Provide experimental conditions, in bar and K - although not recommended by IAU, unit bar is accepted for pressure in this context, as it refers to terrestrial/lab conditions.

sample_desc

Free string or hash-separated-list describing the sample, its origin, and possible preparation

setup_desc

Free string or hash-separated-list describing the experimental setup if needed - may include aperture (size of sample measured), etc

data_calibration_desc

Free string or hash-separated-list describing data post-processing / calibration

geometry_type

Describes the geometry for spectral measurements, from an enumerated list (can be a hash-list, e.g. in case several spectral segments are concatenated). Possible values are:

• direct (therefore in emission)
• specular
• bidirectional
• directional-conical
• conical-directional
• biconical
• directional-hemispherical
• conical-hemispherical
• hemispherical-directional
• hemispherical-conical
• bihemispherical
• directional
• conical
• hemispherical
• other geometry
• unknown

spectrum_type

Explicitly provides the type of spectral measurement, from an enumerated list - this is where 'radiance factor', 'reflectance', 'reflectance factor' etc… are defined. The purpose is to give a precise description of complex measurements independently from UCDs, which are not expected to reach this level of description.

A list of possible values is provided on this page, together with corresponding UCDs (which appear both under measurement_type and in the data files): Lab spectroscopy extension

measurement_atmosphere

Provides description of experimental conditions as a free string. Measurements under vacuum are indicated here with the word 'vacuum'.

Use of general parameters

More general parameters have restricted usage in this case:

thumbnail_url Provides a link to a small spectral plot - caution should be taken to maintained minimal readability in small format in the VESPA portal. Larger plots can be included as separate granules (previews).

datalink_url External documents are often available to provide extra information in this context, e. g. chemical analysis or descriptive image of the sample. Such documents can be considered an extension of the table for the current granule, as opposed to other data products which must be defined as different granules/rows. The best solution identified consists in providing such links under the datalink_url parameter (as dlmeta)  - the alternative idea to use specific parameters such as document_url, image_url… is deprecated.

target_class = 'sample', constant

target_name provides the name or ID of the sample — a value is mandatory in this case. It introduces the name of a meteorite or lunar sample when applicable. Various parts of the same sample can be indicated and described in sample_desc (such as "Location A", etc) or in sample_id.

measurement_type provides the type of measurement/scale as a UCD (REFF, I_over_F, etc…), and is completed by spectrum_type which is expected to be more accurate in general.

species is also available, see if usage is desirable (absence of a species here may suggest that no measurement is available in a services, while usage is limited to some species in practice).

original_publisher may be used to identify a source database in a collective service such as SSHADE

Special cases to handle:

• Photometric measurement sets: some wlv and many angles, distributed together
• Band lists: tables with characteristics and attributions (EPNCore may not be the best possible solution)
• Optical constants: use two associated spectra? Or only one if complex data are available.

14- APIS extension

A specific extension has been designed for compatibility with the APIS service, so that all services in the field of planetary aurorae can be queried together and consistently: EPNcore extension for APIS

This extension contains a set of ~ 25 specific parameters providing ephemeris and configuration quantities. 

Some parameters defined for APIS are of more general interest and can be used by other services distributing observational data from a large facility:

obs_mode, detector_name, opt_elem - relate to instrument characteristics

north_pole_position, target_primary_hemisphere, target_secondary_hemisphere - describe target geometric configuration

orientation, platesc - describe image orientation

15- Events

VOEvents can be archived in EPN-TAP tables. The following extra parameters are available to complete their metadata:

event_type

Provides a type of event from a pre-defined list. Possible values include:

• meteor_shower
• fireball
• lunar_flash
• comet_tail_crossing

A more complete list of values will be maintained separately.

event_status

Following the VOevent standard, this can be:

• prediction
• observation
• utility (e. g., local event related to an instrument, like a change of detector)

event_cite

Following the VOevent standard, this can be:

• followup
• supersedes
• retraction (an alternative is to update the event lists)

Use of general parameters 

When used with the Events extension, some general parameters are constrained:

access_url is expected to link to a VOevent file with dataproduct_type = ev 

access_format = text/xml (for broad identification) or = application/x-voevent+xml 

instrument_host_name, instrument_name For VOEvents that are actually predictions, use instrument_host_name = "simulation" and instrument_name = reference of code used, including version number. 

target_name groups all targets in a hash-separated-list (e. g., Sun#Earth)

obs_id is identical for related events

16- Other extensions

Other extensions will be defined by topical working groups. They will be maintained separately to complement the present document.

Extensions can be derived from independent Data Models, e. g. for exoplanets.