The XAO Data Center's TAP end point. The Table Access
Protocol (TAP) lets you execute queries against our database tables,
inspect various metadata, and upload your own data. It is thus the
VO's premier way to access public data holdings.
Tables exposed through this endpoint include: fast_pul from the fast_pul schema, dr3lite, edr3lite from the gaia schema, notf from the gallery schema, columns, services, tables from the glots schema, liujun from the liujun schema, nsone from the nsone schema, data from the obscode schema, main from the ppmxl schema, pulsar from the pul schema, data from the pulsarcatalog schema, main from the spm4 schema, columns, groups, key_columns, keys, schemas, tables from the tap_schema schema, data from the ucd schema, wugang from the wugang schema.
The Astronomical Data Query Language is the standard IVOA dialect of SQL; it contains a very general SELECT statement as well as some extensions for spherical geometry and higher mathematics.
returns the authority part of an ivoid (or, more generally a URI).
So, ivo://org.gavo.dc/foo/bar#baz becomes org.gavo.dc.
The behaviour for anything that's not a full URI is undefined.
gavo_ipix returns the q3c ipix for a long/lat pair (it simply wraps
the 13c_ang2ipix function).
This is probably only relevant when you play tricks with indices or
PPMXL ids.
gavo_match returns 1 if the POSIX regular expression pattern
matches anything in string, 0 otherwise.
returns the intersection of two MOCs.
returns the union of two MOCs.
The function returns a random number drawn from a normal distribution
with mean mu and width sigma.
Implementation note: Right now, the Gaussian is approximated by
summing up and scaling ten calls to random. This, hence, is not
very precise or fast. It might work for some use cases, and we
will provide a better implementation if this proves inadequate.
gavo_simbadpoint queries simbad for an identifier and returns the
corresponding point. Note that identifier can only be a literal,
i.e., as simple string rather than a column name. This is because
our database cannot query simbad, and we probably wouldn't want
to fire off millions of simbad queries anyway; use simbad's own
TAP service for this kind of application.
returns the spectral value expr converted to dest_unit.
expr has to be in either energy, wavelength, or frequency, and dest_unit
must be a VOUnit giving another spectral unit (e.g., MHz, keV, nm, or
Angstrom). This is intended to let users express spectral constraints
in their preferred unit independently of the choice of unit in the
database. Examples::
gavo_specconv(obscore.em_min, "keV") > 300
gavo_specconv(obscore.em_max, "MHz") > 30
gavo_specconv(spectral_start, "Angstrom") > 4000
There is a variant of gavo_specconv accepting expr's unit in a third
argument.
returns expr assumed to be in expr_unit expressed in dest_unit.
This is a variant of the two-argument gavo_specconv for when
the unit of expr is not known to the ADQL translator, either because
it because it is a literal or because it does not look like
a spectral unit. Examples::
gavo_specconv(656, 'nm', 'J') BETWEEN spectral_start AND spectral_end
gavo_specconv(arccos(phi)*incidence, 'Hz', 'eV')
Clearly, overriding known units is likely to yield bad results;
the translator therefore warns if an existing unit is overridden
with a different unit.
The function converts a postgres timestamp to julian date.
This is naive; no corrections for timezones, let alone time
scales or the like are done; you can thus not expect this to be
good to second-precision unless you are careful in the construction
of the timestamp.
The function converts a postgres timestamp to modified julian date.
This is naive; no corrections for timezones, let alone time
scales or the like are done; you can thus not expect this to be
good to second-precision unless you are careful in the construction
of the timestamp.
The function transforms ADQL geometries between various reference systems.
geo can be a POINT, a CIRCLE, or a POLYGON, and the function will return a
geometry of the same type. In the current implementation, from_sys and
to_sys must be literal strings (i.e., they cannot be computed through
expressions or be taken from database columns).
All transforms are just simple rotations, which is only a rough
approximation to the actual relationships between reference systems
(in particular between FK4 and ICRS-based ones). Note that, in particular,
the epoch is not changed (i.e., no proper motions are applied).
We currently support the following reference frames: ICRS, FK5 (which
is treated as ICRS), FK4 (for B1950. without epoch-dependent corrections),
GALACTIC. Reference frame names are case-sensitive.
returns 1 if matchagainst is term or narrower in the IVOA vocabulary
vocname, 0 otherwise.
This is intended for semantic querying. For instance,
gavo_vocmatch('datalink/core', 'calibration', semantics) would be 1
if semantics is any of calibration, bias, dark, or flat.
For RDF-flavoured vocabularies (strict trees), term will expand to the
entire branch rooted in term. For SKOS-flavoured vocabularies (where
narrower is not transitive), only directly narrower terms will be included.
Both the term and the vocabulary name must be string literals (i.e.,
constants). matchagainst can be any string-valued expression.
The function takes two strings; the first is a list of words not
containing the hash sign (#), concatenated by hash signs, the second is
a word not containing the hash sign. It returns 1 if, compared
case-insensitively, the second argument is in the list of words coded in
the first argument. The behaviour in case the the second
argument contains a hash sign is unspecified.
gavo_hasword returns 1 if needle shows up in haystack, 0 otherwise. This
is for "google-like"-searches in text-like fields. In word, you can
actually employ a fairly complex query language; see
https://www.postgresql.org/docs/current/textsearch.html
for details.
returns a POINT corresponding to the center of the healpix with
the given index at the given order.
Returns the index of the (nest) healpix with order containing the
spherical point (ra, dec).
An alternative, 2-argument form
ivo_healpix_index(order INTEGER, p POINT) -> BIGINT
is also available.
The aggregate function returns a histogram of val with nbins+2 elements.
Assuming 0-based arrays, result[0] contains the number of underflows (i.e.,
val<lower), result[nbins+1] the number of overflows. Elements 1..nbins
are the counts in nbins bins of width (upper-lower)/nbins. Clients
will have to convert back to physical units using some external
communication, there currently is no (meta-) data as lower and upper in
the TAP response.
The function returns 1 if the interval iv contains val, 0 otherwise.
The lower limit is always included in iv, behaviour on the upper
limit is column-specific.
The function returns 1 if the interval [l1...h1] overlaps with
the interval [l2...h2]. For the purposes of this function,
the case l1=h2 or l2=h1 is treated as overlap. The function
returns 0 for non-overlapping intervals.
ivo_nocasematch returns 1 if pattern matches value, 0 otherwise.
pattern is defined as for the SQL LIKE operator, but the
match is performed case-insensitively. This function in effect
provides a surrogate for the ILIKE SQL operator that is missing from
ADQL.
On this site, this is actually implemented using python's and SQL's
LOWER, so for everything except ASCII, your mileage will vary.
An aggregate function returning all values of
expression within a GROUP contcatenated with delimiter
Written after a table reference, TABLESAMPLE(10) will make the database only use 10% of the rows; these are `somewhat random' in that the system will use random blocks. This should be good enough when just testing queries (and much better than using TOP n).
A geometry function creating MOCs. It either takes a string argument with an ASCII MOC ('4/13 17-18 8/3002'), or an order and another geometry.
This is the standard SQL COALESCE for providing defaults in case of NULL values.
You can compute with vectors here. See https://wiki.ivoa.net/twiki/bin/view/IVOA/ADQLVectorMath for an overview of the functions and operators available.
The SQL92 CASE expression