These are services and registry records for the registry interface of this service. Even if together with defaultmeta, this will just work, keep these elements in your etc/userconfig.rd. The metaString macros in here generally point into defaultmeta. Replace them with whatever actual text applies to your site; we will work to do away with defaultmeta.txt. resType: authority creationDate: \\metaString{authority.creationDate}{UNCONFIGURED} title: \\metaString{authority.title}{UNCONFIGURED} shortName: \\metaString{authority.shortName}{UNCONFIGURED} subject: virtual-observatories managingOrg: GAVO Heidelberg Data Center managingOrg.ivo-id: ivo://org.gavo.dc/org referenceURL: \\metaString{authority.referenceURL}{UNCONFIGURED} identifier: ivo://\getConfig{ivoa}{authority} sets: ivo_managed \\metaString{authority.description}{UNCONFIGURED} resType: organization creationDate: 2007-12-19T12:00:00 title: GAVO Heidelberg Data Center subject: virtual-observatories referenceURL: http://www.ari.uni-heidelberg.de identifier: ivo://org.gavo.dc/org sets: ivo_managed Operating at the Astronomisches Rechen-Institut (ARI) (part of Centre for Astronomy of Heidelberg University) on behalf of the German VO organisation GAVO, the GAVO Heidelberg Data Center is a one-stop shop for astronomical data publication projects of (almost) any description. We are also active within the IVOA in standards development and Registry operations. \getConfig{web}{serverURL}\getConfig{web}{nevowRoot}oai.xml registry \getConfig{web}{sitename} Registry 2008-05-07T11:33:00 The publishing registry for the GAVO Heidelberg Data Center. On request, we also host other registry records. Use the contact address for more information. virtual-observatories \\metaString{authority.shortName} Reg Archive public The harvesting interface for the publishing registry of the GAVO Heidelberg data center 10000 \getConfig{ivoa}{authority} edu.euro-vo.org edu.gavo.org x-unregistred tmap.iaat GAVO Heidelberg Data Center When querying against geometric columns, in particular coverage, use ADQL's contains or intersect functions, like this: .. tapquery:: SELECT accref, seeing FROM cars.images WHERE 1=INTERSECTS(coverage, circle('ICRS', 34, -4, 2)) ORDER BY seeing Of course, this concerns all SIAP and SSAP tables (:taptable:`cars.images` only standing as an example here) as well as :taptable:`ivoa.obscore`. `_. You see there's a column specifying whether these quasars are detected in radio; also, you want the thing to be far enough south, and you specify the redshift:: SELECT TOP 100 raj2000, dej2000, name, z FROM veronqsos.data WHERE notRadio!='*' AND z BETWEEN 0.5 AND 1 AND dej2000<-40 The ``TOP 100`` here says that we only want to see 100 items. Writing this is generally a good idea when you do not know how much to expect. Our service will happily serve you millions of rows, and your browser may not like that, and of course it's nice not to put unnecessary load on our servers. However, without any TOP, our server will insert a TOP 3000 for you. Our conditions are fairly straightforward. You can use the usual operators (where equality is "=" rather than C's "=="; SQL doesn't have any assignments in the C sense, so the equality sign isn't used otherwise). SQL has some nice additional operators like the "BETWEEN ... AND ..." shown above. Now, if you actually run this query, you will get 100 rows; there even is a warning that your query limit kicked it, but you will not usually see it in most VOTable clients. You thus typically need to be on your ward yourself. In this case, it would be safe to run without a ``TOP``, or even a TOP 1000000. The query above results in 422 rows, which is still convenient to display. Now, which of these objects have a "good" guide star? Say our device works best of guide stars in the magnitude range of 10 to 11 in V, and the guide star should be no farther away than 0.3 degrees. Consulting GloTS or the registry, you may come up with :taptable:`ppmx.data`. What you need is a crossmatch of PPMX with the little catalogue of QSOs relevant to you generated from the query above. In ADQL's lingo, a crossmatch could look like this:: SELECT q.name, q.raj2000, q.dej2000, p.alphaFloat, p.deltaFloat FROM ( SELECT TOP 100 raj2000, dej2000, name, z FROM veronqsos.data WHERE notRadio!='*' AND z BETWEEN 0.5 AND 1 AND dej2000<-40) AS q JOIN ppmx.data AS p ON (1=CONTAINS( POINT('', q.raj2000, q.dej2000), CIRCLE('', p.alphaFloat, p.deltaFloat, 0.3))) Note that most of the mess in here is the query for the QSOs we did above. Queries can usually stand in for wherever tables can stand in ADQL. You always need an ``AS`` clause to give the subquery a name, though. The main new point here is the *join*, which basically means "bring together two tables". Now, a table in SQL is a set of tuples. When you have two sets of tuples, there are various ways to bring them together -- you can build the (flattened) cartesian product of the two (usually resulting in a huge set), you can stick together randomly drawn tuples, etc. Most of these operations are supported by SQL's (and hence ADQL's) ``JOIN``. The pattern above, however, is what you want for crossmatches: You write down the two tables, giving the aliases (with AS) for convenience and then join them. This happens by writing JOIN between the two table specifications and then giving a condition in parentheses after an ``ON`` behind the last table. For crossmatching, this boils down to the ADQL ``CONTAINS`` function operating on an ADQL ``POINT`` and and ADQL ``CIRCLE``, made up from the coordinates relevant to you. The radius of the circle is given in degrees; most of ADQL is leaning towards degrees, but not the trigonometric functions, which work in radians. ``CONTAINS`` is a numeric function, returning 1 when the point in the first argument is within the circle in the second argument, 0 otherwise. Points and circles are constructed with a coordinate system specification in the first argument. The current ADQL implementation largely ignores this specification, so you could in principle put there whatever you like. In the example above, we used qualified names, i.e., names of the form .. If a column name is unique, you can leave the qualification out, i.e., you could have written:: SELECT name, raj200, dej2000, alphaFloat, deltaFloat... above. The result of the above query is a list of 3428 positions of quasars and possible guide stars of any magnitude. To select only guide stars with, you could filter the results after the selection by appending something like ``WHERE vmag BETWEEN 10 AND 11``. Equivalently, you could add the condition to the selection from PPMX, like this:: SELECT q.name, q.raj2000, q.dej2000, p.alphaFloat, p.deltaFloat FROM ( SELECT TOP 100 raj2000, dej2000, name, z FROM veronqsos.data WHERE notRadio!='*' AND z BETWEEN 0.5 AND 1 AND dej2000<-40) AS q JOIN ( SELECT * FROM ppmx.data WHERE vmag BETWEEN 10 AND 11) AS p ON (1=CONTAINS( POINT('', q.raj2000, q.dej2000), CIRCLE('', p.alphaFloat, p.deltaFloat, 0.3))) However, both of these queries will probably time out on you. Our system will kill queries coming from the web after 15 seconds and tell you that your query timed out. In that case, it may be worthwhile to try and reformulate it. Otherwise, just contact us and we will figure out some way to get your query to execute, possibly by adding more indices to our tables. In particular, any query on large-ish data sets (like the PPMX) not using at least one condition on a column with an index is bound to time out. Columns that are parts of indices are highlighted in the table descriptions. It may not be obvious why adding the WHERE clause above should hurt so badly here, since the database would only have to check a couple of thousand rows, and that's a breeze for a modern computer. However, database engines contain a component called a query planner that should reduce all equivalent queries to the same, optimal form. In reality, this doesn't always work very well, which isn't surprising when you think about the amount of information required to find the optimal sequence of operations to a given result. This means that the machine might completely mess up your query, and that is what happens in this case. There is a common workaround in SQL, known as the "OFFSET 0" trick; this is not possible in ADQL since its syntax doesn't allow this. As a workaround, you can say SELECT ALL, which internally does the same thing (of course, it's not nice to overload a no-op with an almost-no-op). The downside is that you need one more query level. The result then is: .. tapquery:: SELECT * FROM ( SELECT ALL q.name, q.raj2000, q.dej2000, p.alphaFloat, p.deltaFloat, p.vmag FROM ( SELECT TOP 100 raj2000, dej2000, name, z FROM veronqsos.data WHERE notRadio!='*' AND z BETWEEN 0.5 AND 1 AND dej2000<-40) AS q JOIN ppmx.data AS p ON (1=CONTAINS( POINT('', p.alphaFloat, p.deltaFloat), CIRCLE('', q.raj2000, q.dej2000, 0.3)))) AS f WHERE vmag BETWEEN 10 and 11 It may look a bit daunting, but it really built up from simple queries, and it can be taken apart to reveal the simple building blocks. ]]> As a DaCHS extension proposed for inclusion in ADQL 2.2, you can write units in curly braces on this service. Using the @ operator, this will convert an expression to a unit if we can figure out the original unit and it is commensurable with the new unit. As a simple application, you can force units to ensure they fit what your own scripts or what the physics require. For instance, .. tapquery:: select sqrt(power(pmra@{arcsec/yr}, 2) +power(pmdec@{arcsec/yr},2)) as totpm, 5+g_mag+5*log10(parallax@{arcsec}) as absmag from cns5.main will make sure that the parallax unit matches the conventional definition of the distance modulus, and there are no traps as you move to another table that perhaps has other units. Pulling this sort of data in these same units from arihip.main only requires a few edits because of differing column names (and negative parallaxes):: select sqrt(power(pmra@{arcsec/yr}, 2) +power(pmde@{arcsec/yr},2)) as totpm, 5+mv+5*log10(parallax@{arcsec}) as absmag from arihip.main where parallax>0 The conversion operator can also be applied to full expressions; for example, you can compute something like a “duty cycle” of an instrument from from the time limits and an exposure time like this:: select (t_max-t_min)@{s}/t_exptime@{s} from califadr3.cubes You can also adorn literals with units, which will generally improve metadata but may have other uses, too. For instance, you could compute the expansion size over a given time like this:: select veloc_shell@{AU/yr}*10{yr} from ohmaser.masers The unit of the resulting column will be the correct (if somewhat redundant) ``AU/yr.yr`` (rather than a “tainted” ``AU/yr`` otherwise). Units must be written according to the `VOUnits rules`_ .. _VOUnits rules: https://ivoa.net/documents/VOUnits/20231215/REC-VOUnits-1.1.html#tth_sEc1.5 This query demonstrates how to filter objects in one table using another one; in this case, we filter objects with variable proper motion (due to non-resolved duplicity) from a field of PPMXL. Cf. :taptable:`dmubin.main`, :taptable:`ppmxl.main`: .. tapquery:: select * from (select * from ppmxl.main where 1=contains(point('ICRS', raj2000, dej2000), circle('ICRS', 121, 12, 0.3))) as q where not exists ( select * from dmubin.main as d where 1=contains(point('ICRS', d.raj2000, d.dej2000), circle('ICRS',q.raj2000, q.dej2000, 0.001))) This example shows how to decode combined flags (i.e., flags-like numbers in which digits (or groups of digits) need to be extracted to allow interpretation. This is common practice in many historical tables; in the data center, it is rampart within :taptable:`arigfh.id` and the related tables. The principle here is to use the mod function (which, in a pinch, can also help with binary, rather than decimal, multiflags): .. tapquery:: SELECT decCat, raj2000, dej2000, epDec, eqDec FROM arigfh.id WHERE 4=MOD(decflags/10000, 10) Regrettably, ADQL has no notion of boolean values. Some tables this service exposes to TAP -- e.g., :taptable:`amanda.nucand`, have boolean columns natively, and we dare give boolean as a datatype for those in the table metadata. To query those, you cannot say ``WHERE boolCol`` or somesuch as in SQL dialects having native booleans. You must compare against something, and at least on this server, it has to be ``'True'`` or ``'False'`` as string literals, as in .. tapquery:: SELECT * FROM amanda.nucand WHERE atmonusubset='True' `_ that gives A/E(V-I) for some common filters: ========== ==== ======= ====== ======== ======== Filter name λ_eff A/A(V) A/E(B-V) A/E(V-I) ========== ==== ======= ====== ======== ======== Landolt U 3372 1.66 5.43 3.94 Landolt B 4404 1.32 4.32 3.13 Landolt V 5428 1.02 3.32 2.4 Landolt R 6509 0.82 2.67 1.94 Landolt I 8090 0.59 1.94 1.41 Gunn g 5244 1.07 3.48 2.52 Gunn r 6707 0.79 2.59 1.88 Gunn i 7985 0.61 1.99 1.44 Gunn z 9055 0.47 1.54 1.12 Stromgren u 3502 1.6 5.23 3.79 Stromgren b 4676 1.24 4.05 2.93 Stromgren v 4127 1.39 4.55 3.3 Stromgren beta 4861 1.18 3.86 2.8 Stromgren y 5479 1 3.28 2.37 Sloan u' 3546 1.58 5.16 3.74 Sloan g' 4925 1.16 3.79 2.75 Sloan r' 6335 0.84 2.75 1.99 Sloan i' 7799 0.64 2.09 1.51 Sloan z' 9294 0.45 1.48 1.07 ========== ==== ======= ====== ======== ======== ]]> Some tables, for instance :taptable:`antares10.data`, have columns containing geometries (circles, polygons, etc.); in this case, this is because the positional uncertainty for neutrino observatories is so large. Let's say you want to try some statistics with stars with "odd" spectra, perhaps those with RAVE (:taptable:`rave.main`) estimated RVs over 500 km/s. Here's how to do it: .. tapquery:: SELECT raveid, n_hits, rv FROM rave.main as r JOIN antares10.data ON (1=CONTAINS(POINT('', r.raj2000, r.dej2000), origin_est)) WHERE ABS(rv)>500 A similar, perhaps more sensible, but also longer-running query is given in in `the resource's documentation`_. .. _the resource's documentation: http://dc.g-vo.org/browse/antares10/q `_ in many situations. ]]> moreExamples: misc#dsexamples moreExamples.title: Data-specific Examples moreExamples: misc#udfexamples moreExamples.title: Local UDFs moreExamples: https://dc.g-vo.org/static/obscore-examples.shtml moreExamples.title: ObsCore Queries moreExamples: rr/q#ex moreExamples.title: RegTAP Queries moreExamples: life/q#ex moreExamples.title: LIFE Sample Queries The \\getConfig{web}{sitename}'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. In GAVO's data center, we in particular hold several large catalogs like PPMXL, 2MASS PSC, USNO-B2, UCAC4, WISE, SDSS DR16, HSOY, and several Gaia data releases and ancillary resources for you to use in crossmatches, possibly with uploaded tables. Tables exposed through this endpoint include: \\tablesForTAP. The \\getConfig{web}{sitename}'s sitewide SIAP version 2 service publishes all the images published through the site. For more advanced queries including uploads, all this data is also available through ObsTAP. 2016-08-16T12:40:00 virtual-observatories \\metaString{authority.shortName} SIA2 \getConfig{web}{sitename} SIAP Version 2 Service Pointed testQuery.pos.ra: 2.59617984448683 testQuery.pos.dec: -0.0261813842263008 testQuery.size.ra: 0.01 testQuery.size.dec: 0.01 WITH (fillfactor=100)