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


A TAP query consists in looking for certain values of the parameters in the data table. Its arguments are therefore the parameters/columns of this table. Such queries act as a filter on the database contents, and return only the lines of the table matching the arguments.
An EPN-TAP client will typically send the query to all known services, and present a list of services providing a positive answer. It can also restrict to a set of selected services, e. g., those which provided an answer to a first query. Queries are therefore often run in two steps, starting with a discovery/exploration phase to identify services of possible interest (e.g., those containing spectroscopy of Mars), and then addressing a specific question (e.g., a particular spectral range and location at the surface). The overall list of EPN-TAP services used in the exploration phase is accessed from a registry.
The client must use the HTTP GET or POST protocols to send queries to services. The query is composed of the URL of the service, and ADQL language [RD10] is used to express the request. The TAP query is very generic and there is no mandatory parameter associated with it.
Example query:
http://<server address>/tap/sync?REQUEST=doQuery&lang=adql&query=select * from epn_core where time_min > '2455197.5' and time_max < '2455927.5'
Will return all kind of data from 2455197.5 (01/01/2010) to 2455927.5 (01/01/2012) in Julian days (target is not specified)

4.1 Service Behavior


EPNCore defines a set of parameters that must be handled by any EPN-TAP service even if they are not relevant for this service (see section 4.2 below). In this case, the corresponding fields in the epn_core view must be set to "NULL" or left empty. If the client sends a query using such a non-relevant parameter, the service must answer with no data (i.e., elements containing NULL for the query parameter will not be included in the answer, since they do not fit the query). Conversely, parameters omitted (or set to NULL) in the query will not be used to filter the data.
An EPN-TAP client may set a default value for some parameters, in particular for resource_type. A query using a single parameter resource_type = granule would reply with the complete list of granules / data files in the service, which is not optimal for resource exploration; the "dataset" value is more adapted in this case and may be the client's default.
Some parameters can be multivalued in the sense that the epn_core view can accommodate several values, in particular when related to datasets. The separator between values is always a space. To query such parameters, the "like" operator must always be used instead of the "=" operator. These fields include: target_name, target_class, instrument_name, instrument_host_name, measurement_type.
Example:
http://<server address>/tap/sync/request=doquery & lang=adql & query=select * from epn_core where time_min between '2455197.5' and '2455927.5' and target_class like 'comet' and target_name like '1P'
The service will return all data of any type for comet Halley (1P) from 2455197.5 (01/01/2010) to 2455927.5 (01/01/2012) in Julian days
Similarly, a single query can introduce multiple values for a given parameter. ADQL provides standard operations on parameters to combine possible conditions (and, or, like…) as well as parentheses. Standard ADQL wildcards are also implemented [RD10].
Example:
target_name like 'Mars' or target_name like 'Venus'
Return data on both Mars and Venus
Because of a limitation in ADQL language, most query parameters listed below are case insensitive, i.e. should be provided and queried in lower-case. In practice, applications and clients must present parameters using only lower-case characters, and strings in the epn_core view must be transferred in lower cases as described above. Case sensitive parameters are: target names, URLs, filenames, "species" and all non-standard parameters (i.e., defined for a particular service and not listed below).
EPN-TAP services may also contain parameters not included in EPNCore. All such parameters can be accessed using the corresponding names. Notice that names of ADQL functions are reserved and cannot be used as parameter names (see Appendix D). The information of the service table is accessible using VOSI [RD3]. All the metadata tables related to a data service can be obtained via:
HTTP GET http://<server address>/tap/tables
VOSI also provides information about general service capabilities (e.g., IVOA protocols supported by the service). The "capabilities" can be obtained via:
HTTP GET http://<server address>/tap/capabilities
Finally, "Availability" gives information on the current status of the service (up/down...):
HTTP GET http://<server address>/tap/availability
See VOSI document for details on the availability resource.

4.2 Compulsory parameters


Similarly to IVOA's ObsCore [RD7], EPNCore defines a set of parameters describing the EPN-TAP services. These parameters must all be present in the epn_core view of the database, and must be understood as they are defined below.
The parameters attributes must be included in the service response: numerical type, unit, UCD, and a short description string. With the DaCHS framework, this is provided in the "q.rd" file mapping the parameters (Appendix D).
All EPNCore parameters are listed and described in this section. Parameters are characterized using their UCDs and Utypes [RD8]. If compulsory parameters are not relevant or unknown, they must be present in the epn_core view with a value = NULL (or left empty).
Other parameters present in the data service may be queried by EPN-TAP through the same mechanism, but are not systematically supported.
Most numerical parameters are introduced with min and max values, to make interval comparisons possible. Whenever only one value is available (e. g., a unique acquisition time), it must be entered in both min/max fields.
Some of the compulsory parameters may correspond to different UCDs and Utypes depending on context (e. g., the first coordinate may be a distance or an angle). The UCDs and Utypes are part of the service description setup by the data provider. It is therefore the provider's responsibility to adjust the UCDs and Utypes of the service; caution in this matter will insure optimal match with external services. Multiple possibilities and solutions are described below. Whenever new values are required (e. g., to describe data file contents), it is a good practice to look for equivalent descriptions in [RD8] and [RD7].

4.2.1 Index

Name in epn_core view : index
Type : long
unit: unitless
Utype : ??
UCD : meta.id

This parameter provides a unique line number in the epn_core view, typically the entry number of the resource in the database.
This column is present to allow easy referencing of rows across multiple clients keeping the resource set (e.g., in SAMP). While this number should be stable as long as identical queries give identical results, there are no expectations of stability of this number when the total number of rows in the table changes (e.g., on a re-import of updated data).

4.2.2 Resource Type

Name in epn_core view : resource_type
Type : string
unit: unitless
Utype : Epn.ResourceType
UCD : meta.code.class

Defines the scope of the query. There are two possible values:
dataset and granule
The epn_core view lines correspond to individual data objects, and point to a single file (or group of files); this corresponds to the "granule" level of information, the smallest level described in the catalogue. A granule is therefore the smallest element reachable in a data service: a file, a group of associated files, a table entry, or some kind of data computed on the fly. This typically corresponds to a line in the epn_core view.
Subsets of granules may also be grouped together and summarized on a single line of the epn_core view, which defines a "dataset". The same EPN service may contain several datasets. Responses to queries related to granules or datasets are formally similar. The dataset field definitions are derived from the component granules in the most straightforward way (e.g., dataset time_min is the minimum time_min of included granules…).
In the epn_core view, at least one entry resource_type = dataset is required to provide a summary of the data available in the service. The access_url parameter may provide a URL access to a full dataset archive in one file. Data providers could omit this link, for instance in case of very large datasets they don't intend to distribute globally.
Other datasets may be present to describe granules grouped according to arbitrary criteria. Cross-reference between datasets and individual granules are provided through the dataset_id parameter.
An EPN-TAP client may default to resource_type = dataset. This will allow test queries to return information on datasets only, therefore limiting the number of answers. Although this parameter is not mandatory in queries, it makes little sense for the client to query both datasets and granules together.

4.2.3 Dataset ID

Name in epn_core view: dataset_id
Type : string
unit: dimensionless
Utype : ??
UCD : meta.id

The dataset_id parameter provides cross-references when the table includes several datasets (i.e., several lines with resource_type = dataset). It introduces a unique reference ID for these datasets; when applied to granules, it gives the reference to datasets that include the granule. IDs are composed of standard alphanumeric characters, with no space.
When only the mandatory dataset is present, this parameter can be set to 1 for all entries.

4.2.4 Data Product Type

Name in epn_core view: dataproduct_type
Type : string
unit: unitless
Utype : Epn.dataProductType
UCD : meta.code.class

The dataproduct_type parameter describes the high level scientific organization of the data product linked by the access_url parameter (see below), or directly included in the table (in which case the value is most likely 'catalog'). EPNCore currently defines several types listed below. The data provider should 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 — although using several granules to describe the file content may be a better solution.
In the epn_core view, these types are identified by a 2-characters ID, so that multivalued queries are unambiguous. Possible IDs 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. Maps of planetary surfaces are considered as images.
  • sp = spectrum: measurements organized primarily along a spectral axis, e.g., a series of radiance spectra.
  • ds = dynamic_spectrum: consecutive spectral measurements through time, organized as a time series.
  • sc = spectral_cube: sets of 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).
  • pr = profile: scalar or vectorial measurements along 1 spatial dimension, e.g., atmospheric profiles, atmospheric paths, sub-surface profiles…
  • vo = volume: other measurements with 3 spatial dimensions, e.g., internal or atmospheric structures.
  • mo = movie: sets of chronological 2D spatial measurements
  • 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 mostly intended to accommodate unusual data with multiple dimensions.
  • ts = time_series: measurements organized primarily as a function of time (with exception of dynamical spectra and movies, i.e. usually a scalar quantity). Space-borne dust detector measurements are a typical example of a time series.
  • ca = catalog: can be a list of events, a catalog of object parameters, a list of features.... e. g., a list of asteroid properties. It can be limited to scalar quantities, and possibly limited to a single element (i.e., one catalog entry). Time_series, Profile, and Catalog are essentially tables of scalar values. In Time_series the primary key is time; in Profile it is altitude or distance; in Catalog, it may be a qualitative parameter (name, ID…).
  • sv = spatial_vector: list of summit coordinates defining a vector, e.g., vector information from a GIS, spatial footprints…
    Usage:
    select * from epn_core where resource_type = 'granule' and dataproduct_type like 'im'
    will return only image data

    4.2.5 Target Name

    Name in epn_core view: target_name
    Type : string
    unit: unitless
    Utype : Epn.TargetName
    UCD : meta.id;src

    The target_name element 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. Any other feature (craters, regions, atmospheric layers…) must be named using the optional element_name parameter (see 4.3.3).
    The best practice is to use the official name of the target as defined by IAU [RD19]. This parameter is case sensitive (mixing lower/upper cases) and all values must use the standard spelling and case. Data providers must understand that services that do not use the IAU names might not be accessible by the clients. Conversely, users should 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 SSODnet name resolver provided by VOParis-IMCCE may help data providers (and users as well) to handle multiple denominations [RD11].
    Other best practices are listed below:
    The Exoplanet Encyclopedia provides a complete list of currently known extrasolar planets:
    http://exoplanet.eu/
    Meteorite catalogs can be found here:
    http://www.nhm.ac.uk/research-curation/research/projects/metcat/search/indexsing.dsml
    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/
    Usage:
    select * from epn_core where target_name like 'Ceres' or target_name like 'Vesta' and target _type like 'dwarf_planet' or target_class like 'asteroid'
    Will return data only from 1 Ceres or 4 Vesta (see ADQL syntax). Complex queries may also include parentheses
    Example
    1P is the official IAU name for comet Halley.

    4.2.6 Target Class

    Name in epn_core view: target_class
    Type : enum string
    unit: unitless
    Utype : Epn.TargetClass
    UCD : meta.code.class;src

    The target_class element identifies the type of a named target. A target is defined without ambiguity by a couple of parameters: target_class and target_name (although some targets may have no proper name).
    EPNCore defines the possible values for target_class:
    asteroid, dwarf_planet, planet, satellite
    (types from IAU list [RD22])
    comet, exoplanet, interplanetary_medium, ring, sample, sky, spacecraft, spacejunk, star
    (extra types defined for EPN)
    Usage:
    Any target has a unique target type.
    "interplanetary_medium" refers in particular to interplanetary dust.
    "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 - other cases are handled though spacecraft or spacejunk.
    "star" is used typically for calibration targets, and for the Sun.
    "sky" may be used for other celestial bodies, usually referred to by their sky coordinates. It also includes the Interstellar Medium.

    4.2.7 Time Range

    Name in epn_core view: time_min, time_max
    Type : double
    unit: 'd' — Julian day
    time_min:
    Utype : Char.TimeAxis.Coverage.Bounds.Limits.Interval.StartTime
    possibly: Utype : Epn.Time.time_min
    UCD : time.start
    time_max:
    Utype : Char.TimeAxis.Coverage.Bounds.Limits.Interval.StopTime
    possibly: Utype : Epn.Time.time_max
    UCD : time.end

    NB2: pour les Utypes, on pointe vers le DM EPNcore non ?
    C'est dans EPNcore, qui faudrait repointer vers Chararacterization ou autre, Pierre ?

    The time parameters provide the date and time of acquisition.
    In EPN-TAP, the time parameters are always provided in UTC and formatted in Julian days (expressed as a double precision float). Although ObsCore uses Modified JD, EPNCore uses JD to avoid ambiguity with time origin. With double precision floats, the accuracy is on the order of 1 ms, which is considered sufficient to identify data of interest (the initial accuracy is preserved in the data itself).
    The two values min/max permit to handle long periods. Whenever acquisition time is a scalar (rather than an interval), both time_min and time_max must contain the same value in the table. There is no limiting value to this parameter.
    Examples:
    http://<server address>/tap/sync/request=doquery & lang=adql & query=select * from epn_core where time_min > '2455197.5' and time_max < '2455927.5'
    Will search data described by a time range
    http://<server address>/tap/sync/request=doquery & lang=adql & query=select * from epn_core where time_min between '2455197.5' and '2455927.5'
    Will search data described by a start time parameter
    Although time is provided in UTC, it is not necessarily measured on ground; e.g. spacecraft on-board times are acceptable if they are provided on a UTC scale. Therefore times may need to be corrected for light path in order to be compared with other events / datasets. The location where time is measured is provided though the Time_Origin parameter, which is defined at service level (see section 5).
    Service providers may want to use non-compulsory parameters to accommodate additive, specially formatted time scales such as native on-board time (see section 5). The information of the time_min/time_max parameters is however greatly recommended, as it is the only simple way to relate independent datasets.

    4.2.8 Time Sampling Step

    Name in epn_core view : time_sampling_step_min, time_sampling_step_max
    Type : double
    unit: 's'
    time_sampling_step_min
    Utype : Epn.Time.Time_sampling_step_min
    UCD : time.interval;stat.min
    time_sampling_step_max
    Utype : Epn.Time.Time_sampling_step_max
    UCD : time.interval;stat.max

    This parameter provides the sampling step 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 be used as a query parameter, e.g., for ephemeris computations.
    This parameter is intended to allow the user to search for time-resolved observations of dynamic phenomena.

    4.2.9 Exposure Time

    Name in epn_core view: time_exp_min, time_exp_max
    Type : double
    unit: 's'
    time_exp_min
    Utype : Epn.Time.Time_exp_min
    UCD : time.duration;stat.min
    time_exp_max
    Utype : Epn.Time.Time_exp_min
    UCD : time.duration;stat.max

    This parameter corresponds to the integration time of measurements. This time is usually shorter than the time_sampling_step if both are present.

    4.2.10 Spectral Range

    Name in epn_core view: spectral_range_min, spectral_range_max
    Type : double
    unit: 'Hz'
    spectral_range_min
    Utype : Epn.Spectral.Spectral_range_min
    UCD: em.freq;stat.min
    spectral_range_max
    Utype : Epn.Spectral.Spectral_range_max
    UCD: em.freq;stat.max
    The spectral_range parameters define the upper and lower bounds of the spectral domain of the data. As mentioned previously, this quantity is expressed on a frequency scale in Hertz. Conversions to the native unit are provided in Appendix A.
    The spectral range and associated parameters only apply to electromagnetic waves. See the optional parameters particle_spectral_* for particle energy or mass detection.

    4.2.11 Spectral Sampling Step

    Name in epn_core view: spectral_sampling_step_min, spectral_sampling_step_max
    Type : double
    unit: 'Hz'
    spectral_sampling_step_min
    Utype: Epn.Spectral.Spectral_sampling_step_min
    UCD: em.freq.step;stat.min
    spectral_sampling_step_max
    Utype: Epn.Spectral.Spectral_sampling_step_max
    UCD: em.freq.step;stat.max
    em.freq.step ça n'existe pas… et ce n'est pas vraiment comme ça qu'il faudrait le mettre à mon avis. Je vais y réflechir

    The spectral_sampling_step is the spectral separation between the centers of two adjacent filters or channels. Like all spectral_* quantities, it is expressed on a frequency scale in Hz. Conversions to the native unit are provided in Appendix A. The min and max values are expected to correspond to both ends of the spectral range if there is any ambiguity.
    This parameter is mostly intended to provide an order of magnitude, e.g., to distinguish between grating spectrometers and Fourier spectrometers, or between observations related to surfaces or atmospheres. In can also help distinguishing between Nyqvist and sub-Nyqvist sampling rates.

    4.2.12 Spectral Resolution

    Name in epn_core view : spectral_resolution_min, spectral_resolution_max
    Type : double
    unit: 'Hz'
    spectral_resolution_min
    Utype : Epn.Spectral.Spectral_resolution_min
    UCD : spect.resolution;stat.min
    spectral_resolution_max
    Utype : Epn.Spectral.Spectral_resolution_max
    UCD : spect.resolution;stat.max
    (check that spect.resolution is actually OK)

    The spectral_resolution parameters correspond to the spectral bandwidth used for the measurement (Full Width at Half Maximum). In case of a filter camera this is the filter bandwidth; in case of a spectrometer this is the spectral resolution per se. The min and max values are expected to correspond to both ends of the spectral range if there is any ambiguity.
    This parameter is mostly intended to provide an order of magnitude, e.g. to distinguish between grating spectrometers and filter cameras.

    4.2.13 Spatial Coordinates (c1, c2, c3)

    Name in epn_core view : c1min, c2min, c3min, c1max, c2max, c3max
    Type : vector of double
    unit: depending on context (deg, m…)
    Utype : char.SpatialAxis.Coverage
    c1min, c2min, c3min
    Utype:
    Epn.Spatial.Spatial_range.c1min
    Epn.Spatial.Spatial_range.c2min
    Epn.Spatial.Spatial_range.c3min
    UCD: pos;stat.min ou obs.field;stat.min (question) (Ca peut être les deux…)
    c1max, c2max, c3max
    Utype:
    Epn.Spatial.Spatial_range.c1max
    Epn.Spatial.Spatial_range.c2max
    Epn.Spatial.Spatial_range.c3max
    UCD: pos;stat.max ou obs.field;stat.max (question)

    This parameter provides up to three spatial coordinates of the measured target. The coordinates depend on the spatial frame type defined below. All services should handle three spatial coordinates, even if the third one is always set to NULL. Note that the c3 parameter is related to the observed area; the target distance (e. g., geocentric distance for ground based observations, or spacecraft distance) is best introduced by the optional parameter "target_distance".
    The query will be made on the coordinate system proposed by the provider, and no conversion is expected (see spatial_frame_type below). More precise description of the coordinate system is given in the response metadata. Descriptions for EPN-TAP are provided in [RD17].
    Secondary coordinates can be introduced using additional axes, e.g., c1 and c2 providing central longitude and latitude of a planetary disk, and extra RA / DEC columns providing location on the sky at this moment.

    4.2.14 Spatial Resolution

    Name in epn_core view:
    c1_resol_min, c2_resol_min, c3_resol_min, c1_resol_max, c2_resol_max, c3_resol_max
    Type: double
    unit: depending on context (deg, m, ...) — same as spatial_range
    c1_resol_min, c2_resol_min, c3_resol_min
    Utype:
    Epn.Spatial.Spatial_resolution.c1_resol_min
    Epn.Spatial.Spatial_resolution.c2_resol_min
    Epn.Spatial.Spatial_resolution.c3_resol_min
    UCD: pos.resolution;stat.min
    c1_resol_max, c2_resol_max, c3_resol_max
    Utype:
    Epn.Spatial.Spatial_resolution.c1_resol_max
    Epn.Spatial.Spatial_resolution.c2_resol_max
    Epn.Spatial.Spatial_resolution.c3_resol_max
    UCD: pos.resolution;stat.max

    This parameter provides a simple estimate of resolution, either the FWHM of the PFS on the sky (in degrees), or the pixel size on a surface (in m), depending on spatial_frame_type.
    The client frontend may propose more appropriate units to the user, depending on context (e.g., angular resolution in mas, distance in m…).

    4.2.15 Spatial Frame Type

    Name in epn_core view: spatial_frame_type
    Type : string
    unit: unitless
    Utype : Epn.Spatial.Spatial_frame_type
    UCD : meta.code.class;pos.frame

    Provides the "flavor" of the coordinate system, which defines the nature of the spatial coordinates (c1,c2,c3). The possible types are described below:
    celestial: 2D angles on the sky, e. g., right ascension c1 and declination c2 + possibly distance from origin c3 – although this is a special case of spherical frame, the order is different.
    body: 2D angles on a rotating body: longitude c1 and latitude c2 + possibly a z c3 coordinate.
    The best practice is to follow the IAU 2009 planetocentric convention [RD12], 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 (see [RD12] for small bodies, and Annex A for details). The Z coordinate is by default the distance counted from the center of mass.
    The spatial_coordinate_description and spatial_origin attributes allow the data provider to indicate different conventions, e. g., to indicate a planetographic frame, or to use altitude above a reference surface as the third coordinate. It is stressed however that using other frames will make comparisons between datasets more difficult.
    cartesian: (x,y,z) as (c1,c2,c3). This includes spatial coordinates given in pixels.
    cylindrical: (r, theta, z) as (c1,c2,c3); angles are defined in degrees.
    spherical: (r, theta, phi) as (c1,c2,c3); angles are defined as in usual spherical systems (E longitude, zenith angle/colatitude), in degrees. If the data are related to the sky, "celestial" coordinates with RA/Dec must be used.
    healpix: (H, K) as (c1,c2).
    This parameter, although related to the specific coordinate system in use, is mostly intended to identify the nature of the coordinates handled by the service (e. g., angles versus distances).
    This parameter is provided as a column of the epn_core view, to ensure it can be queried through the basic TAP mechanism. However, it is essentially an attribute of the coordinates and is in general expected to remain constant along the table. This parameter should 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 datasets may help clarify the situation; datasets entries must sum up all spatial frame types included in the dataset. At any rate, easy access to the data must be considered during the design of the service.
    Ranges and specific definitions vary with the actual frame in use, and are discussed in Appendix A.

    4.2.16 Incidence Angle

    Name in epn_core view: incidence_min, incidence_max
    Type : double
    unit: 'deg'
    incidence_min
    Utype : Epn.View_angle.Incidence_angle_min
    UCD pos.posAng;stat.min  
    incidence_max
    Utype : Epn.View_angle.Incidence_angle_max
    UCD pos.posAng;stat.max 

    The incidence angle parameters define the upper and lower bounds of the incidence angle variation in the data (also known as Solar Zenith Angle). This is always indicated in decimal degrees, and may range from -180 to 180° (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 available through non-compulsory parameters).

    4.2.17 Emergence Angle

    Name in epn_core view: emergence_min, emergence_max
    Type : double
    unit: 'deg'
    emergence_min
    Utype : Epn.View_angle.Emergence_angle_min
    UCD pos.posAng;stat.min  
    emergence_max
    Utype : Epn.View_angle.Emergence_angle_max
    UCD pos.posAng;stat.max
      
    The emergence angle parameters define the upper and lower bounds of the emergence angle variation in the data (viewing angle). This is always indicated in decimal degrees, and may range from -180 to 180° (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 available through non-compulsory parameters).

    4.2.18 Phase Angle

    Name in epn_core view: phase_min, phase_max
    Type : double
    unit: 'deg'
    phase_min
    Utype : Epn.View_angle.Phase_angle_min
    UCD pos.phaseAng;stat.min
    phase_max
    Utype : Epn.View_angle.Phase_angle_max
    UCD pos.phaseAng;stat.max
      
    The phase angle parameters define the upper and lower bounds of the phase angle variation in the data (scattering angle - 180°, or angle light source-target-observer). This 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, incidence and emergence are partly related:
    abs(i - e) <  < i + e
    If the azimuth angle  is provided instead of the phase angle, the latter can be derived from knowledge of the three angles:
    cos  = cos i cos e + cos  sin i sin e

    4.2.19 Instrument Host Name

    Name in epn_core view: instrument_host_name
    Type : string
    unit: unitless
    Utype : Provenance.ObsConfig.Facility.name
    Utype : Epn.Instrument_host_name ???
    UCD : meta.id;instr.obsty

    This parameter provides the name of the observatory or spacecraft that performed the measurements. The best practice is to use names from the lists indicated below. A list of host names should be provided for integrated data sets.
    For ground-based observations, the reference is 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
    Other open Q:
  • are IAU ID eligible?
  • granularity is very heterogeneous (e.g. one single entry for Paranal or Mauna Kea, but many for siding spring).
  • Some entry related to obs programs (New Horizon KBO search from various sites)
    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:
    http://www-int.stsci.edu/~sontag/spicedocs/req/naif_ids.html
    (TBC – Spice is unambiguous but only uses IDs, PDS values are explicit but somewhat arbitrary)
    In the epn_core view, the acronym is preferred to the full name to avoid long strings and related errors. Both values can be provided (e.g., HST + Hubble Space Telescope).

    4.2.20 Instrument Name

    Name in epn_core view: instrument_name
    Type : string
    unit: unitless
    UTYPE : Provenance.ObsConfig.Instrument.name
    Utype : Epn.Instrument_name ???
    UCD meta.id;instr

    Identifies the instrument(s) that acquired the data. A list of instruments should be provided for integrated datasets.
    Service providers are invited to include multiple values for instrument name, e.g., complete name + usual acronym. This will allow queries on either "VISIBLE AND INFRARED THERMAL IMAGING SPECTROMETER" or VIRTIS to produce the same reply.
    Concerning space-borne data, the most complete 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/experimentSearch.do

    4.2.21 Measurement Type

    Name in epn_core view: measurement_type
    Type : string
    unit: unitless
    Utype : Char.ObservableAxis.ucd
    Utype : Epn.Measurement_type
    UCD : meta.ucd

    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 stellar_occultation is not.
    The provider should use the "UCD1+" list from IVOA as a reference, and should extend it only when necessary [RD8]:
    http://www.ivoa.net/Documents/REC/UCD/UCDlist-20070402.pdf
    The measurement_type parameter is used to search data relevant to a certain field. Whenever several quantities are comprised in the granule, the measurement_type parameter must therefore refer to all these quantities, including multiple UCDs if needed. Multiple values are separated by spaces.
    Datasets entries must sum up all measurement types included in the dataset. This is a handy way to identify the science content of a complete service.
    Extra UCDs will be proposed/requested to IVOA. In the meantime, an extended list of UCDs will be made available in the EPN-DM document (in progress).
    Examples:
    For images in general, the relevant UCD is obs.image, whatever the calibration level.
    Alt : phot.flux would also be OK?
    For spectra phot.flux.density describes a radiance vector - while the spectral vector is described by UCDs em.wvl, em.freq or em.energy, and the related error is described by stat.error;phot.flux.density.

    4.3 Optional parameters


    EPN-TAP can query parameters not included in the EPNCore. Some of these parameters are defined precisely but are relevant only to very specific data services. Those are not mandatory, but they must be implemented as defined in this section when present. Beside, the names of optional parameters are reserved for this particular usage and must not be used to introduce other quantities.
    Whenever constant throughout the service, some of these parameters can be defined at the table level, instead of the granule level (i. e., in the description of the epn_core view rather than as an column).

    4.3.1 Access Reference (access_url)

    Utype : Obs.Access.Reference
    Utype: EpnResponse.File_info.AccessURL
    UCD : meta.ref.url;meta.file
    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. All URLs in the epn_core view are case sensitive and must provide an actual link. However, the link may be the output of a script on the server, in which case this parameter provides a call to the script with adequate arguments (e.g. Titan atmospheric profiles service). In any case, this parameter must link to the actual data, not to a file of metadata nor to a document.
    Whenever the data consists in a few scalar fields, this parameter may be replaced by parameters providing the data itself (e.g. mass, in a table providing the masses of Solar System bodies).
    When the data is spread among several files, variations on this parameter may be used. The data provider must identify a "main data product" which is linked through this parameter (and the related ones below). This will allow the plotting tools to download some data in any case. E. g., a service may provide links to calibrated images, plus raw data and ancillary information for every granule; the main product will probably be the calibrated image, but other files can be described using non-standard parameters such as ancillarydata_access_url – beware that such fields may not be easily accessible by the client or tools.

    4.3.2 Access Format (access_format)

    Utype : Obs.Access.Format
    Utype: EpnResponse.File_info.Access_format
    UCD : meta.code.mime
    Access_format provides the format of the data file linked through the access_url parameter.
    The data may be stored in their native format, and no format conversion is required to set up an EPN-TAP service. This field can therefore include reference to unusual formats, although those may not be handled by plotting tools but only in a specific environment. Consistently with ObsCore, possible values are MIME-types written in lower cases and are listed in Appendix F.

    4.3.3 Estimated Size (access_estsize)

    Utype : Obs.Access.Size
    Type : integer
    unit: kbyte
    Utype : EpnResponse.File_info.Access_estsize
    UCD : phys.size;meta.file (TBC with CDS)
    The access_estsize field provides an order of magnitude (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.

    4.3.4 Preview Reference (preview_url)

    Name in epn_core view: preview_url
    Type : string – free format
    unit: unitless
    Utype : Obs.Access.Reference
    Utype : EpnResponse.??? Not in DM?
    UCD : meta.ref.url;meta.file
    The preview_url parameter contains the URL of a reduced version of the data product used for quick-look purpose (e.g. a small Jpeg image). This may be handy in the case of big data files or unusual data formats, to facilitate data selection by the user. Besides, the EPN-TAP client uses this preview for on-line quick-look, which therefore provides important added value to a service. The preferred formats include Jpeg and PNG (which should be handled easily by a basic viewer). If several previews are provided, variations on this name can be used. All URLs in the epn_core view are case sensitive and must provide an actual link.

    4.3.5 Native access Reference (native_access_url)

    Utype : Obs.Access.Reference
    Utype: EpnResponse.File_info.AccessURL
    UCD : meta.ref.url;meta.file
    The native_access_url parameter provides access to the original version of the data file, in addition to the formatted version provided by access_url. This is typically used by a service that reformats the data files on the fly. For instance, the Titan atmospheric profile service normally provides VOtable written by the server, but the original ascii files can still be retrieved though this keyword. If a script is used to provide the access_url link, the native_access_url link may be provided by the same script using a different output format.
    This parameter may also refer to original PDS3 files when the data have been converted to VOTables.

    4.3.6 Native access format (native_access_format)

    Utype : Obs.Access.Format
    Utype: EpnResponse.File_info.Access_format
    UCD : meta.code.mime
    The native_access_format parameter provides description of the files accessed through the native_access_url parameter.

    4.3.7 File Name (file_name)

    Name in epn_core view: file_name
    Type : string – free format
    unit: unitless
    Utype : ?
    UCD : meta.id;meta.file
    The file_name parameter introduces the name of the data file, with no path information. In many data services, the file name encodes the most relevant metadata and may be a very handy access mechanism at least for specialists. All filenames in the epn_core view are case sensitive and must reflect an actual filename.

    4.3.8 Species

    Name in epn_core view: species
    Type : string – standard formulas only
    unit: unitless
    Utype : ?
    Utype : Not in DM?
    UCD : meta.id;phys.atmol
    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 the only query parameter that is 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 the vertical abundances of many gaseous species with altitude. All columns are abundances and are described by the same measurement_type parameter. Only the use of the "species" parameter (together with the column name itself) allows identifying the various species and accessing the requested information.
    If the data contain one column per species, it is recommended to also include the species in the column name (e.g., H2O_abundance).
    If more elaborated compositional information must be included, the use of another parameter providing InChiKeys is recommended.

    4.3.9 Element Name

    Name in epn_core view: element_name
    Type : string – free format
    unit: unitless
    Utype : Not in DM?
    UCD : meta.id;pos
    The element_name parameter 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 name…) whereas target_name is reserved to describe the whole body (mars, moon, ceres…). The best practice is to use the official features name defined by IAU [RD20] when relevant.
    The target_region parameter (see below) also provides additional information on the target, but is aimed at indicating the global scope of a database (e.g., atmospheric layer, internal structure…).

    4.3.10 Reference

    Name in epn_core view: reference
    Type : string
    unit: unitless
    Utype : Not in DM?
    UCD : meta.bib
    The reference parameter introduces an individual bibliographic reference at granule level. This may be required, e. g., if the resource is a compilation of data from various origins.
    This is best provided as a Bibcode as used e. g. in ADS.

    4.3.11 Celestial coordinates (RA/Dec)

    Name in epn_core view: ra, dec
    Type : float
    unit: ? See Cone Search
    Utype : ?
    UCD ?
    If fixed sky coordinates of the target are provided in the view in addition to standard coordinates, they must be stored in parameters named ra and dec. This may document the location of a planet in a celestial image, while the main coordinates c1/c2 are used to describe the observed area.

    4.3.12 Solar longitude (Ls)

    Name in epn_core view: Ls
    Type: float
    unit: 'deg'
    Utype: ?
    UCD: pos.posAngle
    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.

    4.3.13 Local time

    Name in epn_core view: local_time_min, local_time_max
    Type : float
    unit: 'hours'
    local_time_min:
    Utype : ?
    UCD: time.phase;stat.min
    local_time_max:
    Utype : ?
    UCD: time.phase;stat.max
    Planetary observations may be documented using the local time at the surface, i. e. the location of the solar meridian normalized to 24. This parameter is provided in unit of target rotation divided by 24 and is measured from local midnight (ranges from 0 to 24, should increase with time at a given location). It is provided in decimal hours.

    4.3.14 Target Distance

    Name in epn_core view: target_distance
    Type: double
    unit: dimensionless
    Utype: ?
    UCD: pos.distance
    The target_distance parameter introduces the distance of the observer to the observed area, not to be confused with a vertical dimension provided by c3. For ground-based observations, this is the geocentric distance of the target. For space borne data, this is the spacecraft-target distance.

    4.3.15 Particle Spectral Type

    Name in epn_core view: particle_spectral_type
    Type: string
    unit: dimensionless
    Utype: ?
    UCD ?
    This parameter and the following ones are related to the spectral distribution of particles only (see the spectral_* parameters for electro-magnetic waves).
    The particle_spectral_type parameter introduces the type of axis in use: either energy (provided in eV), mass (in amu), or mass/charge ratio (in amu/qe).

    4.3.16 Particle Spectral Range

    Name in epn_core view: particle_spectral_range_min, particle_spectral_range_max
    Type : double
    unit: 'eV', 'amu', or 'amu/qe'
    particle_spectral_range_min
    Utype : ?
    UCD : phys.energy;phys.part;stat.min
    particle_spectral_range_max
    Utype : ?
    UCD : particle phys.energy;phys.part;stat.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.
    Conversions to the native unit are provided in Appendix A.

    4.3.17 Particle Spectral Sampling Step

    Name in epn_core view: particle_spectral_sampling_step_min, particle_spectral_sampling_step_max
    Type : double
    unit: 'eV', 'amu', or 'amu/qe'
    particle_spectral_sampling_step_min
    Utype: ?
    UCD: ?
    particle_spectral_sampling_step_max
    Utype: ?
    UCD: ?
    The particle_spectral_sampling_step parameters provide the spectral separation between measurements, in the same scale and unit as particle_spectral_range.
    Conversions to the native unit are provided in Appendix A. This parameter is mostly intended to provide an order of magnitude.

    4.3.18 Particle Spectral Resolution

    Name in epn_core view : particle_spectral_resolution_min, particle_spectral_resolution_max
    Type : double
    unit: 'eV', 'amu', or 'amu/qe'
    particle_spectral_resolution_min
    Utype : ?
    UCD : spect.resolution;stat.min
    particle_spectral_resolution_max
    Utype : ?
    UCD : spect.resolution;stat.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.

    4.4 Parameter attributes


    The columns of the epn_core view can be described more precisely using either optional parameters (in which case the value can change from granule to granule), or columns attributes (which value remains constant along the table).
    Only the parameters of the epn_core view can be used for data selection in a query, therefore important attributes must be stored as parameters even when they remain constant throughout the table (which is often the case, e. g., for spatial_frame_type). A convenient way to get the broad properties of a service is to send a query limited to datasets, with no further parameter.
    The client can also grab information from other sources. However, such attributes can only be included in the service response VOtable to document the output. VOSI supports only some attributes for each column: numerical type, unit, UCD, and description (free field); in DACHS, these are declared in the file "q.rd" defining the service. The registry can also include some properties or attributes of the overall service.
    We discussed the possibility to add a second table epn_desc containing parameter attributes in the q.rd file. Apparently DaCHS could handle this with no major problem, TBC (for version 2.0…)

    4.4.1 Processing level

    EPN expression: processing_level
    Type : integer
    Utype PSR:processingLevel
    Utype : EpnResponse.Complementary_return_info.Processing_level
    UCD : meta.code;obs.calib
    In the framework of EPN-TAP, this parameter is intended to provide the user with a quick evaluation of data "usability". Several classifications are in use in different contexts, as summarized in the table below. EPN-TAP uses the CODMAC levels (IDs coded as integers). "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, e. g., coordinates or geometry files. Although it may be more consistent to separate calibration levels in different data services, several levels can be included in the same service (in particular calibrated and ancillary data). Only one value can be accommodated in this field, so the most advanced level (1-5) should be used when several levels are available.

    (Compilation of information from PSA & ObsCore documents)

    CODMAC level / EPN-TAP

    PSA level

    NASA level

    PRODUCT_TYPE (PDS3/PSA)

    ObsTAP

    Description
    (from PSA, with comments)

    1
    (raw)

    1a

     

    UDR

    Level 0

    Unprocessed Data Record
    (low-level encoding, e.g. telemetry from a spacecraft instrument. Normally available only to the original team)

    2
    (edited)

    1b

    0

    EDR

    Level 1
    (std data format)

    Experiment Data Record
    (often referred to as "raw data": decommutated, but still affected by instrumental effects)

    3
    (calibrated)

    2

    1A

    RDR

    Level2

    Reduced Data Record
    ("calibrated" in physical units)

    4
    (resampled)

     

    1B

    REFDR

     

    Reformatted Data Record
    (mosaics or composite of several observing sessions, involving some level of data fusion)

    5
    (derived)

    3

    2-5

    DDR

    Level3

    Derived Data Record
    (result of data analysis, directly usable by other communities with no further processing)

    6
    (ancillary)

     

     

    ANCDR

     

    Ancillary Data Record
    (extra data specifically supporting a data set, such as coordinates, geometry…)



    This quantity may be provided as a column attribute when the data are imbedded in the epn_core view, or linked as external URL (it then applies to access_url and derived parameters).

    4.4.2 Data unit and dimension

    UCD: meta.unit ?
    Although the epn_core parameters are provided in standard scales/units, service output values will be provided in native form, and associated with physical units that need to be identified — in particular to send the data to VO plotting tools.
    Native units are provided in the file defining the service parameters (e.g., "q.rd" file under DaCHS), and are reported as field descriptors in the output VOtable.
    ??? Beware that this is not related to a parameter in general, but to a quantity available in a file, perhaps mixed with other ones
    We also need a sort of measurement_type (e.g., to send data to VOspec).
    This field is case sensitive (mixing lower/upper cases) and follows the International System of Units (SI) standard. For ease of notation, the caret "^" indicating powers of ten, and the multiplicative dot "." are both optional. 
    — are we sure of this ? This seems an unnecessary complication for the client.
    Example:
    "Jansky" or "W.m^-2.Hz^-1" or "Wm-2Hz-1 "
    are equivalent

    4.4.3 Description of coordinate frame

    Spatial_coordinate_description
    Spatial_origin
    These two parameters provide description of the spatial frame(s) in use, as introduced by the spatial_frame_type parameter. This is mostly relevant when this parameter is constant throughout the service.
    Possible values are detailed in [RD17], which is partly adapted from STC [RD13]
    Examples (TBC)
    BODY, Mars_IAU2000
    ICRS, Geocenter
    This appears in the "description" element of the spatial_frame_type parameter in the q.rd file ??? —TBC ; the name of the specific frame (first parameter) should appear there, but what of the second one? Then: what if spatial_frame_type is not constant?

    4.4.4 Time Origin

    This attribute states where the time is measured, and is expected to remain constant throughout the service. This knowledge is required to cross-correlate event-based observations, in particular to indicate light-path differences. It is expected to remain constant along the table, and applies to the time_min and time_max parameters.
    Possible values from time_origin are:
    Earth, (solar system bodies name), (spacecraft name)
    This may appear in the "description" element of the time_range parameter, e.g. in the q.rd file for a DaCHS server. (in practice, used as an optional parameter)

    4.5 Service properties


    Some properties are defined at the level of the entire service. A part of this information (in particular the one related to publisher and credits) is available only in the registry.
    Most of these fields must be included in the service response however, and therefore an EPN-TAP client must be able to grab this information from the registry.
    List of general properties of the service or table (all these TBC):
    + Can we use names already used as parameter/column names?

    4.5.1 Service_protocol

    Introduces a constant string = "EPN-TAP". The associated value provides the protocol version number.
    This is available in the registry — However it is also included in the current service response??

    4.5.2 Title / Name

    Provides the service/table title.
    This is available in the registry — However it is also included in the current service response??

    4.5.3 Creation_date

    Provide the date when the service was last updated.
    This is available in the registry — However it is also included in the current service response??

    4.5.4 Access_url (global)

    Provides network access to the EPN-TAP service.
    This is available in the registry — However it is also included in the current service response??

    4.5.5 ReferenceURL (global)

    Provides bibliographic references for the entire dataset or service.
    This is available in the registry — However it is also included in the current service response??
    This is best provided as a Bibcode as used e. g. in ADS.

    4.5.6 Curation

    Provides credits for the data service. This elements includes three fields:
  • "creator" introduces the responsible/coordinator of the science content (PI).
  • "contributors" introduces the contributors to the contents, including at technical level.
  • "publisher" introduces the ID of the publishing entity.
    Example:
    <curation>
    <publisher ivo-id="ivo://vopdc.obspm/lesia">VO-Paris Data Centre - LESIA</publisher>
    <creator>
    <name>L. Lamy (Observatoire de Paris - LESIA)</name>
    </creator>
    <contributor>F. Henry, VO-Paris Data Centre</contributor>
    <date>2012-06-06</date>
    <version>1</version>
    <contact>
    <name>L. Lamy</name>
    <address>Observatoire de Paris, 5 place Jules Jansen, 92195 Meudon, France</address>
    <email>laurent.lamy@obspm.fr</email>
    <telephone>+33145077661</telephone>
    </contact>
    </curation>

    4.5.7 Target_region

    Type : string
    unit: unitless
    ucd : meta.main => src.class ?
    This parameter optionally identifies the region of interest for the resource, in complement to target_name. This parameter only introduces generic regions, not specific local names, which must be handled using the element_name parameter (see examples above).
    The best practice is to take the values from standard sources:
  • IVOA thesaurus: http://www.ivoa.net/rdf/Vocabularies/vocabularies-20091007/IVOAT/
  • IAU thesaurus http://www.mso.anu.edu.au/library/thesaurus/
    + another version: http://www.vocabularyserver.com/trex/en/
    The latter seems more recent and more complete (although the interface is not practical)
  • Spase dictionary http://www.spase-group.org/
    Example:
    "atmosphere", "surface", "ionosphere"
    The same sources are used for the declaration file in the registry.

    4.5.8 Data_access_info

    Provides indications relative to data handling. May introduce mime type, data structure, data reader… (TBC). It is not mandatory.

    Should also tell:
  • File format and how to read it
    => access_format and readerURL in the DM would do
  • where to find physical quantities in the file (data of interest + axes) – this is not handled in VO plotting tools => the Virtis/Aladin demonstrator is a use case for this.
  • some parameters required to indicate the file area to be read (e.g. which data product in a PDS file, which extension/column in a FITS…)
  • What is/are the main axis?
    Hum… is this only related to workflows later in the process?

    4.6 Application to special services


    EPN-TAP, because it is directly derived from TAP, may not be optimal to query computational services. Simulated data are accessible the same way as observational data, but the simulation parameters may be difficult to access through this mechanism. Similarly, experimental data are accessible but experimental setup and sample descriptions may be hard to reach (VAMDC-TAP may be a better choice to handle this kind of data).
    Access to various data structures can be assessed through the Use Cases listed in Appendix B.
    Tabular data are by construction more easily handled with EPN-TAP.
    If the dataset mostly consists in files, EPN-TAP tells nothing about the file structure. As a consequence, the user cannot plot the files automatically if it is not a standard (e.g., image) format.

    Time Scale

    Name : time_scale
    Type : string
    unit: unitless
    Utype : stc.timeScaleType
    ucd : time.scale

    This parameter defines which time scale is to be used in the answer, for instance when querying an ephemeris server. The way this parameter is handled is left to the service provider, but the actual value must be included in the output VOTable.
    This parameter does not affect the time range included in the query, which must always be expressed using UTC – this is more a query option than a parameter.
    Other time scales defined in STC [RD13] can be used:
  • TT : Terrestrial Time: the basis for ephemeris
  • TDB : Barycentric Dynamic Time: the independent variable in planetary ephemeris; time at the Solar System barycenter, synchronous with TT on an annual basis; sometimes called TEB
  • TCG : Terrestrial Coordinate Time
  • TCB : Barycentric Coordinate Time; runs slower than TDB but is consistent with physical constants
  • TAI : International Atomic Time; runs 32.184 s behind TT
  • UTC : Coordinated Universal Time; currently (2006) runs 33 leap seconds behind TAI
  • GPS : Global Positioning System's time scale; runs 19 s behind TAI, 51.184 s behind TT

  • No labels
Write a comment…