Queries¶
+1. Queries¶
+This is the first in a series of lessons about working with astronomical data.
+As a running example, we will replicate parts of the analysis in a recent paper, “Off the beaten path: Gaia reveals GD-1 stars outside of the main stream” by Adrian Price-Whelan and Ana Bonaca.
Outline¶
This lesson demonstrates the steps for selecting and downloading data from the Gaia Database:
@@ -378,19 +375,19 @@ But you might find it easier to learn fromNotebooks are made up of code cells and text cells (and a few other less common kinds). Code cells contain code; text cells, like this one, contain explanatory text written in Markdown.
To run a code cell, click the cell to select it and press Shift-Enter. The output of the code should appear below the cell.
In general, notebooks only run correctly if you run every code cell in order from top to bottom. If you run cells out of order, you are likely to get errors.
You can modify existing cells, but then you have to run them again to see the effect.
You can add new cells, but again, you might have to be careful about the order you run them in.
You can add new cells, but again, you have to be careful about the order you run them in.
If you have added or modified cells and the behavior of the notebook seems strange, you can restart the “kernel”, which clears all of the variables and functions you have defined, and run the cells again from the beginning.
-
-
If you are using Jupyter notebook, open the Kernel menu and select “Restart and Run All”.
-In Jupyter Lab…
-In Colab, open the Runtime menu and select “Restart and run all”
+If you are using Jupyter notebook, open the
Kernelmenu and select “Restart and Run All”.
+In Jupyter Lab, open the
Kernelmenu and select “Restart Kernel and Run All Cells”
+In Colab, open the
Runtimemenu and select “Restart and run all”
Before you go on, you might want to explore the other menus and the toolbar to see what else you can do.
Running this import statement has the effect of creating a TAP+ connection; TAP stands for “Table Access Protocol”, which is a network protocol for sending queries to the database and getting back the results.
+This import statement creates a TAP+ connection; TAP stands for “Table Access Protocol”, which is a network protocol for sending queries to the database and getting back the results.
Databases and Tables¶
@@ -444,6 +441,7 @@ INFO: Done. [astroquery.utils.tap.core]The following for loop prints the names of the tables.
for table in tables:
@@ -454,6 +452,7 @@ INFO: Done. [astroquery.utils.tap.core]
external.apassdr9
external.gaiadr2_geometric_distance
+external.gaiaedr3_distance
external.galex_ais
external.ravedr5_com
external.ravedr5_dr5
@@ -482,17 +481,31 @@ gaiaedr3.agn_cross_id
gaiaedr3.commanded_scan_law
gaiaedr3.dr2_neighbourhood
gaiaedr3.frame_rotator_source
+gaiaedr3.allwise_best_neighbour
+gaiaedr3.allwise_neighbourhood
+gaiaedr3.apassdr9_best_neighbour
+gaiaedr3.apassdr9_join
+gaiaedr3.apassdr9_neighbourhood
+gaiaedr3.gsc23_best_neighbour
+gaiaedr3.gsc23_join
+gaiaedr3.gsc23_neighbourhood
gaiaedr3.hipparcos2_best_neighbour
gaiaedr3.hipparcos2_neighbourhood
gaiaedr3.panstarrs1_best_neighbour
gaiaedr3.panstarrs1_join
gaiaedr3.panstarrs1_neighbourhood
+gaiaedr3.ravedr5_best_neighbour
+gaiaedr3.ravedr5_join
+gaiaedr3.ravedr5_neighbourhood
gaiaedr3.sdssdr13_best_neighbour
gaiaedr3.sdssdr13_join
gaiaedr3.sdssdr13_neighbourhood
gaiaedr3.skymapperdr2_best_neighbour
gaiaedr3.skymapperdr2_join
gaiaedr3.skymapperdr2_neighbourhood
+gaiaedr3.tmass_psc_xsc_best_neighbour
+gaiaedr3.tmass_psc_xsc_join
+gaiaedr3.tmass_psc_xsc_neighbourhood
gaiaedr3.tycho2tdsc_merge_best_neighbour
gaiaedr3.tycho2tdsc_merge_neighbourhood
gaiaedr3.urat1_best_neighbour
@@ -595,7 +608,7 @@ Parsing table 'gaiadr2.gaia_source'...
Done.
-<astroquery.utils.tap.model.taptable.TapTableMeta at 0x7f2e23f089d0>
+<astroquery.utils.tap.model.taptable.TapTableMeta at 0x7f50edd2aeb0>
@@ -732,7 +745,7 @@ epoch_photometry_url
You can probably guess what many of these columns are by looking at the names, but you should resist the temptation to guess. +
You can probably infer what many of these columns are by looking at the names, but you should resist the temptation to guess. To find out what the columns mean, read the documentation.
If you want to know what can go wrong when you don’t read the documentation, you might like this article.
Writing queries¶
-By now you might be wondering how we download the actual data. With tables this big, you generally don’t. Instead, you use queries to select only the data you want.
+By now you might be wondering how we download these tables. With tables this big, you generally don’t. Instead, you use queries to select only the data you want.
A query is a string written in a query language like SQL; for the Gaia database, the query language is a dialect of SQL called ADQL.
Here’s an example of an ADQL query.
query1 = """SELECT
TOP 10
-source_id, ref_epoch, ra, dec, parallax
-FROM gaiadr2.gaia_source"""
+source_id, ra, dec, parallax
+FROM gaiadr2.gaia_source
+"""
The third line is a list of column names, indicating which columns we want.
In this example, the keywords are capitalized and the column names are lowercase. This is a common style, but it is not required. ADQL and SQL are not case-sensitive.
+Also, the query is broken into multiple lines to make it more readable. This is a common style, but not required. Line breaks don’t affect the behavior of the query.
To run this query, we use the Gaia object, which represents our connection to the Gaia database, and invoke launch_job:
job1 = Gaia.launch_job(query1)
-job1
+job = Gaia.launch_job(query1)
+job
<astroquery.utils.tap.model.job.Job at 0x7f2e23f2afa0>
+<astroquery.utils.tap.model.job.Job at 0x7f50edd2adc0>
The result is an object that represents the job running on a Gaia server.
-If you print it, it displays metadata for the forthcoming table.
+If you print it, it displays metadata for the forthcoming results.
print(job1)
+print(job)
However, Phase: COMPLETED indicates that the job is complete, so we can get the results like this:
results1 = job1.get_results()
-type(results1)
+results = job.get_results()
+type(results)
The type function indicates that the result is an Astropy Table.
Optional detail: Why is table repeated three times? The first is the name of the module, the second is the name of the submodule, and the third is the name of the class. Most of the time we only care about the last one. It’s like the Linnean name for gorilla, which is Gorilla gorilla gorilla.
The result is an Astropy Table, which is similar to a table in an SQL database except:
+An Astropy Table is similar to a table in an SQL database except:
SQL databases are stored on disk drives, so they are persistent; that is, they “survive” even if you turn off the computer. An Astropy
Tableis stored in memory; it disappears when you turn off the computer (or shut down this Jupyter notebook).SQL databases are designed to process queries. An Astropy
Tablecan perform some query-like operations, like selecting columns and rows. But these operations use Python syntax, not SQL.
@@ -941,37 +956,53 @@ Results: None
It selects the first 3000 rows, so it is bigger than we should run synchronously.
+It selects two additional columns,
pmraandpmdec, which are proper motions along the axes ofraanddec.It uses a new keyword,
WHERE.Whenever possible, start with a working query, either an example you find online or a query you have used in the past.
@@ -1080,6 +1094,15 @@ Results: None
Read the metadata and the documentation to make sure you understand the tables, their columns, and what they mean.
Develop queries incrementally: start with something simple, test it, and add a little bit at a time.
Use ADQL features like
TOPandCOUNTto test before you run a query that might return a lot of data.
-If you know your query will return fewer than 3000 rows, you can run it synchronously, which might complete faster (but it doesn’t seem to make much difference). If it might return more than 3000 rows, you should run it asynchronously.
+If you know your query will return fewer than 2000 rows, you can run it synchronously, which might complete faster. If it might return more than 2000 rows, you should run it asynchronously.
ADQL and SQL are not case-sensitive, so you don’t have to capitalize the keywords, but you should.
ADQL and SQL don’t require you to break a query into multiple lines, but you should.
Make each section of the notebook self-contained. Try not to use the same variable name in more than one section.
Keep notebooks short. Look for places where you can break your analysis into phases with one notebook per phase.
Jupyter knows how to display the contents of a Table.
results1
+results
| source_id | ref_epoch | ra | dec | parallax | ||
|---|---|---|---|---|---|---|
| yr | deg | deg | mas | |||
| int64 | float64 | float64 | float64 | float64 | ||
| 6758509757594141440 | 2015.5 | 290.4899010727352 | -30.34317218420783 | 0.48023816159705535 | ||
| 6758508692437976960 | 2015.5 | 290.64176055082714 | -30.28972013142225 | 2.2625971293368154 | ||
| 6758527036250849280 | 2015.5 | 290.35703708993327 | -30.193657826181596 | -0.2763960334229464 | ||
| 6758564458298242944 | 2015.5 | 290.77376294142846 | -29.765368439225238 | 0.5907906528352993 | ||
| 6758558612842155776 | 2015.5 | 290.67550630386245 | -29.92113396078169 | 0.2858563565989917 | ||
| 6758556379459921920 | 2015.5 | 290.5454006212404 | -29.900709054816964 | -1.0012355835832834 | ||
| 6758537520260385152 | 2015.5 | 290.7341683169994 | -30.158181298418626 | -- | ||
| 6758506355980010624 | 2015.5 | 290.586950869878 | -30.37137642167569 | 0.3769870991981157 | ||
| 6758561606433968128 | 2015.5 | 290.82697136098506 | -29.75247697212053 | -- | ||
| 6758564183414408448 | 2015.5 | 290.7133096669958 | -29.781743673679607 | 0.9376387942856869 |
| source_id | ra | dec | parallax |
|---|---|---|---|
| deg | deg | mas | |
| int64 | float64 | float64 | float64 |
| 5887983246081387776 | 227.978818386372 | -53.64996962450103 | 1.0493172163332998 |
| 5887971250213117952 | 228.32280834041364 | -53.66270726203726 | 0.29455652682279093 |
| 5887991866047288704 | 228.1582047014091 | -53.454724911639794 | -0.5789179941669236 |
| 5887968673232040832 | 228.07420888099884 | -53.8064612895961 | 0.41030970779603076 |
| 5887979844465854720 | 228.42547805195946 | -53.48882284470035 | -0.23379683441525864 |
| 5887978607515442688 | 228.23831627636855 | -53.56328249482688 | -0.9252161956789068 |
| 5887978298278520704 | 228.26015640396173 | -53.607284412896476 | -- |
| 5887995581231772928 | 228.12871598211902 | -53.373625663608316 | -0.3325818206439385 |
| 5887982043490374016 | 227.985260087594 | -53.683444499055575 | 0.02878111976456593 |
| 5887982971205433856 | 227.89884570686218 | -53.67430215342567 | -- |
Each column has a name, units, and a data type.
-For example, the units of ra and dec are degrees, and their data type is float64, which is a 64-bit floating-point number, used to store measurements with a fraction part.
For example, the units of ra and dec are degrees, and their data type is float64, which is a 64-bit floating-point number, used to store measurements with a fraction part.
This information comes from the Gaia database, and has been stored in the Astropy Table by Astroquery.
Exercise¶
-Read the documentation of this table and choose a column that looks interesting to you. Add the column name to the query and run it again. What are the units of the column you selected? What is its data type?
+Read the documentation of this table and choose a column that looks interesting to you. Add the column name to the query and run it again. What are the units of the column you selected? What is its data type?
# Solution
+
+# Let's add
+#
+# radial_velocity : Radial velocity (double, Velocity[km/s] )
+#
+# Spectroscopic radial velocity in the solar barycentric
+# reference frame.
+#
+# The radial velocity provided is the median value of the
+# radial velocity measurements at all epochs.
+
+query = """SELECT
+TOP 10
+source_id, ra, dec, parallax, radial_velocity
+FROM gaiadr2.gaia_source
+"""
Asynchronous queries¶
launch_job asks the server to run the job “synchronously”, which normally means it runs immediately. But synchronous jobs are limited to 2000 rows. For queries that return more rows, you should run “asynchronously”, which mean they might take longer to get started.
If you are not sure how many rows a query will return, you can use the SQL command COUNT to find out how many rows are in the result without actually returning them. We’ll see an example of this later.
The results of an asynchronous query are stored in a file on the server, so you can start a query and come back later to get the results.
-For anonymous users, files are kept for three days.
-As an example, let’s try a query that’s similar to query1, with two changes:
If you are not sure how many rows a query will return, you can use the SQL command COUNT to find out how many rows are in the result without actually returning them. We’ll see an example in the next lesson.
The results of an asynchronous query are stored in a file on the server, so you can start a query and come back later to get the results. +For anonymous users, files are kept for three days.
+As an example, let’s try a query that’s similar to query1, with these changes:
query2 = """SELECT TOP 3000
-source_id, ref_epoch, ra, dec, parallax
+query2 = """SELECT
+TOP 3000
+source_id, ra, dec, pmra, pmdec, parallax
FROM gaiadr2.gaia_source
WHERE parallax < 1
"""
@@ -1000,31 +1033,22 @@ Results: None
A WHERE clause indicates which rows we want; in this case, the query selects only rows “where” parallax is less than 1. This has the effect of selecting stars with relatively low parallax, which are farther away. We’ll use this clause to exclude nearby stars that are unlikely to be part of GD-1.
WHERE is one of the most common clauses in ADQL/SQL, and one of the most useful, because it allows us to select only the rows we need from the database.
A WHERE clause indicates which rows we want; in this case, the query selects only rows “where” parallax is less than 1. This has the effect of selecting stars with relatively low parallax, which are farther away.
+We’ll use this clause to exclude nearby stars that are unlikely to be part of GD-1.
WHERE is one of the most common clauses in ADQL/SQL, and one of the most useful, because it allows us to download only the rows we need from the database.
We use launch_job_async to submit an asynchronous query.
job2 = Gaia.launch_job_async(query2)
-print(job2)
+job = Gaia.launch_job_async(query)
+job
INFO: Query finished. [astroquery.utils.tap.core]
-<Table length=3000>
- name dtype unit description
---------- ------- ---- ------------------------------------------------------------------
-source_id int64 Unique source identifier (unique within a particular Data Release)
-ref_epoch float64 yr Reference epoch
- ra float64 deg Right ascension
- dec float64 deg Declination
- parallax float64 mas Parallax
-Jobid: 1609260407863O
-Phase: COMPLETED
-Owner: None
-Output file: async_20201229114648.vot
-Results: None
+<astroquery.utils.tap.model.job.Job at 0x7f50edd40f40>
And here are the results.
results2 = job2.get_results()
-results2
+results = job.get_results()
+results
| source_id | ref_epoch | ra | dec | parallax | ||
|---|---|---|---|---|---|---|
| yr | deg | deg | mas |
| source_id | ra | dec | parallax | radial_velocity |
|---|---|---|---|---|
| deg | deg | mas | km / s | |
| int64 | float64 | float64 | float64 | float64 |
| 6758509757594141440 | 2015.5 | 290.4899010727352 | -30.34317218420783 | 0.48023816159705535 |
| 6758527036250849280 | 2015.5 | 290.35703708993327 | -30.193657826181596 | -0.2763960334229464 |
| 6758564458298242944 | 2015.5 | 290.77376294142846 | -29.765368439225238 | 0.5907906528352993 |
| 6758558612842155776 | 2015.5 | 290.67550630386245 | -29.92113396078169 | 0.2858563565989917 |
| 6758556379459921920 | 2015.5 | 290.5454006212404 | -29.900709054816964 | -1.0012355835832834 |
| 6758506355980010624 | 2015.5 | 290.586950869878 | -30.37137642167569 | 0.3769870991981157 |
| 6758564183414408448 | 2015.5 | 290.7133096669958 | -29.781743673679607 | 0.9376387942856869 |
| 6758529789322653184 | 2015.5 | 290.35449465190385 | -30.10231481465004 | -1.3305133038319952 |
| 6758507485555336064 | 2015.5 | 290.6745961953205 | -30.35965148061028 | 0.057302711920868686 |
| ... | ... | ... | ... | ... |
| 4660464894038295424 | 2015.5 | 79.74509945051724 | -66.49656012737759 | 0.1631257821260955 |
| 4660463519650480128 | 2015.5 | 80.06150680482719 | -66.42891601595986 | -0.5822669736733328 |
| 4660487674554071040 | 2015.5 | 80.03536662790846 | -66.33136792885134 | -1.4978065466579966 |
| 4660494718300886784 | 2015.5 | 79.6181997343967 | -66.17472335318212 | 0.1488652133861382 |
| 4660476473274159360 | 2015.5 | 79.12508291180023 | -66.35644844757275 | 0.10671540523101529 |
| 4660471010093940224 | 2015.5 | 79.1908378165463 | -66.48916840294096 | 0.8152150079365807 |
| 4660498394807167744 | 2015.5 | 80.23431532382547 | -66.08688681815092 | -0.14060596426163252 |
| 4660498738391722880 | 2015.5 | 80.20205898946918 | -66.04392313295126 | 0.1894642263668475 |
| 4660474068091096960 | 2015.5 | 78.93686107060341 | -66.45795576745896 | 0.4665513634059366 |
| 4660437303162697728 | 2015.5 | 80.63872120225027 | -66.46144560233674 | -1.1319163320535979 |
| 5895270396817359872 | 213.08433715252883 | -56.64104701005694 | 2.041947005434917 | -- |
| 5895272561481374080 | 213.2606587905109 | -56.55044401535715 | 0.15693467895110133 | -- |
| 5895247410183786368 | 213.38479712976664 | -56.97008551185148 | -0.19017525742552605 | -- |
| 5895249226912448000 | 213.41587389088238 | -56.849596577635786 | -- | -- |
| 5895261875598904576 | 213.5508930114549 | -56.61037780154348 | -0.29471722363529257 | -- |
| 5895258302187834624 | 213.87631129557286 | -56.678537259039906 | 0.6468437015289753 | -- |
| 5895247444506644992 | 213.33215109206796 | -56.975347759380995 | 0.390215490234287 | -- |
| 5895259470417635968 | 213.78815034206346 | -56.64585047451594 | 0.953377710788918 | -- |
| 5895264899260932352 | 213.21521027193236 | -56.78420864489118 | -- | -- |
| 5895265925746051584 | 213.17082359534547 | -56.74540885107754 | 0.2986918215101751 | -- |
You might notice that some values of parallax are negative. As this FAQ explains, “Negative parallaxes are caused by errors in the observations.” Negative parallaxes have “no physical meaning,” but they can be a “useful diagnostic on the quality of the astrometric solution.”
You might notice that some values of parallax are negative. As this FAQ explains, “Negative parallaxes are caused by errors in the observations.” They have “no physical meaning,” but they can be a “useful diagnostic on the quality of the astrometric solution.”
Exercise¶
-The clauses in a query have to be in the right order. Go back and change the order of the clauses in query2 and run it again.
The query should fail, but notice that you don’t get much useful debugging information.
+The clauses in a query have to be in the right order. Go back and change the order of the clauses in query2 and run it again.
+The modified query should fail, but notice that you don’t get much useful debugging information.
For this reason, developing and debugging ADQL queries can be really hard. A few suggestions that might help:
# Solution
+
+# In this example, the WHERE clause is in the wrong place
+
+query = """SELECT
+TOP 3000
+WHERE parallax < 1
+source_id, ref_epoch, ra, dec, parallax
+FROM gaiadr2.gaia_source
+"""
Exercise¶
Read about SQL operators here and then modify the previous query to select rows where bp_rp is between -0.75 and 2.
You can read about this variable here.
# Solution
# Here's a solution using > and < operators
-query = """SELECT TOP 10
+query = """SELECT
+TOP 10
source_id, ref_epoch, ra, dec, parallax
FROM gaiadr2.gaia_source
WHERE parallax < 1
@@ -1143,7 +1166,8 @@ Be careful to keep your Python out of your ADQL!
# And here's a solution using the BETWEEN operator
-query = """SELECT TOP 10
+query = """SELECT
+TOP 10
source_id, ref_epoch, ra, dec, parallax
FROM gaiadr2.gaia_source
WHERE parallax < 1
@@ -1153,51 +1177,23 @@ Be careful to keep your Python out of your ADQL!
bp_rp contains BP-RP color, which is the difference between two other columns, phot_bp_mean_mag and phot_rp_mean_mag.
+You can read about this variable here.
This Hertzsprung-Russell diagram shows the BP-RP color and luminosity of stars in the Gaia catalog (Copyright: ESA/Gaia/DPAC, CC BY-SA 3.0 IGO).
Selecting stars with bp-rp less than 2 excludes many class M dwarf stars, which are low temperature, low luminosity. A star like that at GD-1’s distance would be hard to detect, so if it is detected, it it more likely to be in the foreground.
Cleaning up¶
-Asynchronous jobs have a jobid.
job1.jobid, job2.jobid
-(None, '1609260407863O')
-Which you can use to remove the job from the server.
-Gaia.remove_jobs([job2.jobid])
-Removed jobs: '['1609260407863O']'.
-If you don’t remove it job from the server, it will be removed eventually, so don’t feel too bad if you don’t clean up after yourself.
-Formatting queries¶
-So far the queries have been string “literals”, meaning that the entire string is part of the program. +
The queries we have written so far are string “literals”, meaning that the entire string is part of the program. But writing queries yourself can be slow, repetitive, and error-prone.
-It is often a good idea to write Python code that assembles a query for you. One useful tool for that is the string format method.
It is often better to write Python code that assembles a query for you. One useful tool for that is the string format method.
As an example, we’ll divide the previous query into two parts; a list of column names and a “base” for the query that contains everything except the column names.
Here’s the list of columns we’ll select.
columns = 'source_id, ra, dec, pmra, pmdec, parallax, radial_velocity'
+columns = 'source_id, ra, dec, pmra, pmdec, parallax'
And here’s the base; it’s a string that contains at least one format specifier in curly brackets (braces).
query3_base = """SELECT TOP 10
+query3_base = """SELECT
+TOP 10
{columns}
FROM gaiadr2.gaia_source
WHERE parallax < 1
@@ -1224,6 +1221,8 @@ But writing queries yourself can be slow, repetitive, and error-prone.
In this example, the variable that contains the column names and the variable in the format specifier have the same name. +That’s not required, but it is a common style.
The result is a string with line breaks. If you display it, the line breaks appear as \n.
'SELECT TOP 10 \nsource_id, ra, dec, pmra, pmdec, parallax, radial_velocity\nFROM gaiadr2.gaia_source\nWHERE parallax < 1\n AND bp_rp BETWEEN -0.75 AND 2\n'
+'SELECT \nTOP 10 \nsource_id, ra, dec, pmra, pmdec\nFROM gaiadr2.gaia_source\nWHERE parallax < 1\n AND bp_rp BETWEEN -0.75 AND 2\n'
SELECT TOP 10
-source_id, ra, dec, pmra, pmdec, parallax, radial_velocity
+SELECT
+TOP 10
+source_id, ra, dec, pmra, pmdec
FROM gaiadr2.gaia_source
WHERE parallax < 1
AND bp_rp BETWEEN -0.75 AND 2
@@ -1258,26 +1258,24 @@ WHERE parallax < 1
Let’s run it and see if it works:
-job3 = Gaia.launch_job(query3)
-print(job3)
+job = Gaia.launch_job(query3)
+print(job)
<Table length=10>
- name dtype unit description n_bad
---------------- ------- -------- ------------------------------------------------------------------ -----
- source_id int64 Unique source identifier (unique within a particular Data Release) 0
- ra float64 deg Right ascension 0
- dec float64 deg Declination 0
- pmra float64 mas / yr Proper motion in right ascension direction 0
- pmdec float64 mas / yr Proper motion in declination direction 0
- parallax float64 mas Parallax 0
-radial_velocity float64 km / s Radial velocity 10
+ name dtype unit description
+--------- ------- -------- ------------------------------------------------------------------
+source_id int64 Unique source identifier (unique within a particular Data Release)
+ ra float64 deg Right ascension
+ dec float64 deg Declination
+ pmra float64 mas / yr Proper motion in right ascension direction
+ pmdec float64 mas / yr Proper motion in declination direction
Jobid: None
Phase: COMPLETED
Owner: None
-Output file: sync_20201229114653.xml.gz
+Output file: sync_20210315091929.xml.gz
Results: None
@@ -1285,27 +1283,27 @@ Results: None
-results3 = job3.get_results()
-results3
+results = job.get_results()
+results
Table length=10
-
-source_id ra dec pmra pmdec parallax radial_velocity deg deg mas / yr mas / yr mas km / s int64 float64 float64 float64 float64 float64 float64 4660466371507774848 79.49100199261952 -66.41411777672668 2.6073927760139983 -1.1968907801968522 -0.13534455558687877 -- 4660498704031984000 80.19346436358076 -66.04907675232856 1.644062563874402 -1.954975321006136 -0.1774586376397 -- 4660458949824817024 79.68666778641992 -66.52220959662557 1.4777697275880581 0.3328961930362448 -0.030149510331454386 -- 4660451974773926528 79.89972073493868 -66.75037858071191 2.4635048563021065 -0.7474574729840501 -0.005219591141134416 -- 4660474033731357056 78.93214036467484 -66.46483644591667 1.2369118132455594 -1.7187143034638677 0.6018032937392243 -- 4660454105077874688 79.91045649235578 -66.68106846135971 1.4747855407533677 0.022464361420165786 -0.19949109843083218 -- 4660494855753740544 79.63101881952036 -66.15063315813536 1.6227863263222113 0.20490893261905152 0.0013030724292998944 -- 4660439536571308160 80.24817961417894 -66.46303270664092 1.8652105429518493 -0.5618584442373111 -0.10578442360531497 -- 4660470185440466560 79.25942306061864 -66.51120777549605 3.373561172003989 0.25326243152876704 -0.6932631338638376 -- 4660441460690365568 80.38862155241748 -66.34404494135046 1.6588478675146066 -0.09646951910977163 -0.2100859303087445 --
+source_id ra dec pmra pmdec deg deg mas / yr mas / yr int64 float64 float64 float64 float64 5895272561481374080 213.2606587905109 -56.55044401535715 0.3894438898301715 1.2299266281737415 5895261875598904576 213.5508930114549 -56.61037780154348 0.16203641364393007 -4.672602679543312 5895247444506644992 213.33215109206796 -56.975347759380995 -7.474003156859284 -3.538080792097856 5895259470417635968 213.78815034206346 -56.64585047451594 -5.287202255231853 -0.8163762113468646 5895265925746051584 213.17082359534547 -56.74540885107754 -7.880749306158471 -4.8585444120179595 5895260913525974528 213.66936020541976 -56.66655190442016 -4.7820929042428215 -1.5566420086447643 5895264212062283008 213.7755742121852 -56.51570859067397 -6.657690998559842 -1.7616494482071872 5895253457497979136 213.30929960610283 -56.78849448744587 -5.242106718924749 -0.18655636353898095 4143614130253524096 269.1749117455479 -18.53415139972117 2.6164274510804826 1.3244248889980894 4065443904433108992 273.26868565443743 -24.421651815402857 -1.663096652191022 -2.6514745376067683
Good so far.
@@ -1317,25 +1315,27 @@ Results: None
# Solution
-query4_base = """SELECT TOP 10
+query_base = """SELECT
+TOP 10
{columns}
FROM gaiadr2.gaia_source
WHERE parallax < {max_parallax} AND
bp_rp BETWEEN -0.75 AND 2
"""
-query4 = query4_base.format(columns=columns,
- max_parallax=0.5)
+query = query_base.format(columns=columns,
+ max_parallax=0.5)
print(query)
-SELECT TOP 10
-source_id, ref_epoch, ra, dec, parallax
+SELECT
+TOP 10
+source_id, ra, dec, pmra, pmdec
FROM gaiadr2.gaia_source
-WHERE parallax < 1
- AND bp_rp BETWEEN -0.75 AND 2
+WHERE parallax < 0.5 AND
+bp_rp BETWEEN -0.75 AND 2
@@ -1360,22 +1360,16 @@ WHERE parallax < 1
Jupyter notebooks can be good for developing and testing code, but they have some drawbacks. In particular, if you run the cells out of order, you might find that variables don’t have the values you expect.
-There are a few things you can do to mitigate these problems:
+To mitigate these problems:
-
-One of the other tables we’ll use is
-gaiadr2.panstarrs1_original_valid. Use load_table to get the
-metadata for this table. How many columns are there and what are
-their names?
-
@@ -1408,7 +1402,7 @@ their names?